Greg Charles

+ Follow
since Oct 01, 2001
Greg likes ...
Mac IntelliJ IDE Python VI Editor Java
San Diego, California
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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.

2 years ago
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!
2 years ago
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: , among other places. What problem are you facing?
3 years ago
Use the rep function:

3 years ago
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 and repeated elsewhere at various sites has this setup code:

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?
4 years ago
John Godfrey has completed the Servlets assignments in the Cattle Drive. Congratulations, John!
5 years ago
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!
5 years ago
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:

That's probably what I'll submit with the bug report, once it's been vetted by the Ranchers.
5 years ago
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.

5 years ago
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.

5 years ago
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.

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

... 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:

... now it compiles and runs again, and I don't even need to change the instantiation part of it. What's going on here?
5 years ago
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.
5 years ago
Hi David, welcome to Java Ranch and the Cattle Drive!

To start, send your submission to That mailbox is monitored by Janeice, who will be your nitpicker for the first dozen or so assignments.
5 years ago
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 you should be using:

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.
5 years ago