This week's book giveaway is in the Cloud forum.
We're giving away four copies of Terraform in Action and have Scott Winkler on-line!
See this thread for details.
Win a copy of Terraform in Action this week in the Cloud forum!

Brad Howerter

+ Follow
since Jan 06, 2006
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 Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brad Howerter

Where is this published list that Bert was going to do in December? Did he publish one?
I guess Bert still isn't getting younger...

I don't understand why, when I run 'javac -classpath MyJar.jar' from the test directory, it creates Foo.class in the test directory. Foo.class is already in MyJar.jar!
The book is wrong. You don't have to override hashCode or equals; the default implementations in Object work just fine, so long as you understand that it's the object reference that is being compared when you do a retrieval. The book's own example can be used to demonstrate this, with a slight change. Change Dog to not override hashCode and equals and rerun the code - it prints the output exactly the same way. Line #4, m.get(d1), works because d1 is the original reference.

The books also claims that if you don't override hashCode and equals, you won't be able to find your stuff. This is wrong. If you still have the original key stored somewhere (like the d1 Dog in the example above), you can use it to find your stuff. It is true that you can't create a new object and use it to find your stuff. That's probably what the authors meant.
Okay, D is wrong, but what's wrong with B (which uses jsp:forward)? I just tried it and it works fine.

I guess it's how you interpret 'include'. When you forward to something, you include it's response, I say.