Win a copy of Java by Comparison (eBook) this week in the Java in General forum!

Greg Charles

+ Follow
since Oct 01, 2001
Greg likes ...
Firefox Browser IntelliJ IDE Java Mac Ruby
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

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?
6 months ago
John Godfrey has completed the Servlets assignments in the Cattle Drive. Congratulations, John!
1 year 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!
1 year 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.
1 year 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.

1 year 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.

1 year 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?
1 year 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.
1 year 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.
1 year 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.
1 year ago
Hi John,

You're right that the Bee MVC example in the instructions uses embedded Java, but only because it comes right before the introduction of EL. Once you know EL, you should never use embedded Java ever again.

Currently it's:

With EL, it would be:

It's easier to write and it's easier to read. Win-win! Anyway, see if that works for you. If not, maybe we'll have to look at versions of things that you're using. EL has been around for quite a long time now though, so I'd be surprised if that's it.
1 year ago
What little screen scraping I've done in Ruby, I've done with the Nokogiri gem. You might want to check out the RailsCast on the topic:

I haven't used roo, but I don't see why you would store the data into Excel at all. Why not just use a database?
1 year ago
Hi Sijesh, can you be clearer about what "not working" means? Does it not appear on the page? Do you get any errors on the JavaScript console? If the button appears, and you click it, do you see a request sent to the server?
1 year ago