Greg Charles

Hi Nick,

The official policy of the Cattle Drive has been it never expires, and I think that's still the case. Practically speaking, it's somewhat languished over the years and as far as I know, there are no remaining active students. However, I think you should send a "Purple Mooseage" to Janeice DelVecchio, who nitpicked the first two modules, and she can probably get you re-established. Let me know how that goes!

Also, 51 isn't old.

Greg

Personally, I find Macs to be a much better development platform than Windows boxes are. I do recommend setting up Homebrew first though, which is kind of a hit, but then you can use it to install Tomcat, whatever database you want to use, and even Java. (Plus hundreds of other useful things.) It just takes looking up the "formula" and pasting it into the terminal.

In other words, go for the heat! If you're still cold, bring the Windows PC upstairs and light it on fire. You'll be glad you did!

I don't know what a Survival object is, but R has a survival package with a Surv class in it.  It's documented here: http://personal.psu.edu/drh20/R/html/survival/html/Surv.html , among other places. What problem are you facing?

Use the rep function:

rep(c(1,2,3), times=2) # 1 2 3 1 2 3 rep(c(1,2,3), each=2) # 1 1 2 2 3 3

I'm pretty new to Spring AWS integration. Right now I'm just trying to get a prototype working that will implement a message listener for an SQS  ... something like you'd handle in JEE with RabbitMQ and an MDB. The example I'm seeing at libraries.io and repeated elsewhere at various sites has this setup code:

@SpringBootApplication public static class MyConfiguration {    @Autowired    private AmazonSQSAsync amazonSqs;    @Bean    public PollableChannel inputChannel() {        return new QueueChannel();    }    @Bean    public MessageProducer sqsMessageDrivenChannelAdapter() {        SqsMessageDrivenChannelAdapter adapter = new SqsMessageDrivenChannelAdapter(this.amazonSqs, "myQueue");        adapter.setOutputChannel(inputChannel());        return adapter;    } }

First, it's annotated as SpringBootApplication not Configuration. That doesn't seem to be a typo, because they have many examples done the same way. Also, the class is declared static, so it can't be an outer class. Maybe the intention is that this should be an inner class within the Spring Boot class? There's nothing to suggest this interpretation though, and it would still need a Configuration annotation, wouldn't it?

John Godfrey has completed the Servlets assignments in the Cattle Drive. Congratulations, John!

That's difficult to answer in the abstract. Generally speaking, it's perfectly fine to have a decision (if-else) in a method, and part of the resulting branches may involve calling different methods. Something to consider is whether each of your methods performs exactly one task. If you can say that methodA() performs the same task when it calls B, D, and F, as it does when it calls C, just for different starting inputs, then your design is fine. I can't think of the Cattle Drive problem that would fit this analogy, but give it go, and your nitpicker will let you know if it makes sense. That's what we're for!

I also think Praveen's explanation was correct, though it didn't go far enough. My contention is this shows there is a bug in the Java compiler. At least, I don't see anything in the JLS (Justice League of Siberia) that says when type erasure is applied to a parametrized class, it must also be extended to unrelated generics used in instance methods. Moreover, I can't see any reason why this would be true. However, I'm actually hoping that someone will show me the error in my reasoning!

In any case, you are right that adding a type parameter on line 1 of your example also demonstrates this bug. The cleanest demonstration of it that I have come up with is:

public class GenTest<T> {     <S> S identity(S s) {         return s;     }    public static void main(String[] args) {        GenTest g = new GenTest();        String s = g.identity("Hello");    } }

That's probably what I'll submit with the bug report, once it's been vetted by the Ranchers.

Hey Praveen, sorry for all the confusion!

Knute was correct that I thought CCE would be clear from context, since I had written it out in my previous sentence. It's similar to your use of JLS, which is only written out in your quoted text, but it's still perfectly clear what you mean. BTW (hah!), both are abbreviations, but not acronyms. Yes, those terms are often confused, but it still bugs us poor pedants.

You were also unclear about my last question, but I'm not sure how I can clarify it beyond just reiterating. The casts and the compiler warnings are on lines 5 and 7, but the ClassCastException (aka CCE) happens on line 15, where there is no cast. It's not so much a question as it is an observation of an interesting anomaly -- one that I thought might shed light on my original question.

Now, back to the original question. I think you may have hit on something with that link to the Java Language Specification (JLS), and type erasure. The spec (specification) explains how type erasure is used when a parameterized class isn't bound to a specific type. In my example, that would lead to the erasure of type U throughout the class if it were used in fields, instance methods, and such (though it is not in my example). However, it does appear that the compiler is over-aggressively applying this type erasure to all types in instance-level contexts in the class. IOW (i.e, in other words), for my example, the compiler needs to use type erasure for U, but ends up using it for both U and T. Granted, the spec (specification) doesn't explicitly address what to do in this situation, but that behavior is sufficiently bizarre that I believe it could still be called a bug.

Yes, that's a good way of putting it. Why isn't the compiler more picky in the first example? What about the second example causes it to become more picky? And, what about the third example makes it not picky again?

Another interesting point: the unchecked cast warnings you note for the first example are on lines 5 and 7, the casts to T. However, the ClassCastException if it happens, happens on line 15. I can't think of a case where the CCE could actually occur where the warnings say it might.

While going through Jeanne and Scott's excellent book on Java 8 certification, I have been experimenting with different scenarios to test my understanding of generics. In one case at least, I've managed to baffle myself.

public class GenTest {    <T extends Number> T myMethod(String s) {        switch (s) {            case "N":                return (T)new Integer(2);            case "D":                return (T) new Double(5.0);            default:                return null;        }    }    public static void main(String[] args) {        GenTest g = new GenTest();        Integer j = g.myMethod("N");        System.out.println(j);    } }

This compiles fine, and prints 2 as I expected it would. However, if I parameterize the GenTest class itself:

public class GenTest<U> { [same as above] }

... now I get a compile error on line 15: Error: (15, 31) java: incompatible types: java.lang.Number cannot be converted to java.lang.Integer

If I add literally any concrete class to the declaration:

public class GenTest<U> {    [ ... same method as above ...]    public static void main(String[] args) {        GenTest<OutOfMemoryError> g = new GenTest();        Integer j = g.myMethod("N");        System.out.println(j);    } }

... now it compiles and runs again, and I don't even need to change the instantiation part of it. What's going on here?

Hi Gillian, thanks for reaching out. I haven't heard about Janeice being away, or otherwise out of action. Have you tried resubmitting the assignment? It's possible it just got lost in email somewhere.

Hi David, welcome to Java Ranch and the Cattle Drive!

To start, send your submission to nitpick@javaranch.com. That mailbox is monitored by Janeice, who will be your nitpicker for the first dozen or so assignments.

Hmm, sorry about that. The original assignments had inVHS() and inDVD(). I vaguely remember that wasn't simply a typo, but I don't really remember the details. In any case, EL works with classes that strictly follow the JavaBean specification -- and that means naming accessors with "get", except for booleans where "is" is preferred. I remember updating the sample files, but it looks like either I'm wrong or that update got reverted at some point. Here's the VideoData.java you should be using:

/** * VideoData is a JavaBean representing data about a single video. */ package com.javaranch.drive.videos; import java.io.Serializable; public class VideoData implements Serializable {    private static final long serialVersionUID = 1L;    private String title;    private String star;    private String type;    private boolean vhs = false;    private boolean dvd = false;    private String desc;    public VideoData()    {    }    public VideoData(String title, String star, String type, String desc)    {        this.title = title;        this.star = star;        this.type = type;        this.desc = desc;    }    public String getTitle()    {        return title;    }    public String getStar()    {        return star;    }    public String getType()    {        return type;    }    public boolean isVhs()    {        return vhs;    }    public void setVhs(boolean vhs)    {        this.vhs = vhs;    }    public boolean isDvd()    {        return dvd;    }    public void setDvd(boolean dvd)    {        this.dvd = dvd;    }    public String getDescription()    {        return desc;    }    public void setDescription(String desc)    {        this.desc = desc;    } }

Feel free to make other changes if the sample files aren't working right for you. Just give me a heads up, so I can correct them online if need be.