Effective Java

Effective Java - Programming Language Guide by Joshua Bloch

ISBN 0201310058 57 items for improving Java code (available in Khori Garden)

You'll love this book or hate it.

As someone who doesn't love this book, I think its value may come from giving insights as to potential ways to tune your code in light of performance problems.
It's one of the few Java books I can recommend to people. My only complaint is that more of the book is devoted to defensive programming (i.e. how to protect your Java code against malicious attack) as opposed to writing cleaner code with lower maintenance costs. It's all very good material, but it might have come across better if the defensive coding techniques were presented separately. -- JeffLangr

I think it's helpful to keep in mind the perspective of the author. Joshua Bloch is a J2SE platform library engineer at JavaSoft?. He's in a different place in the value chain than those of us who use the platform to write software for users or other developers. I think his position influences his perspective quite a bit. He has to program defensively. He has no idea who will be (ab)using his code, or how. For me, I couldn't have a better idea - it's the people on my team. So there is some context dependency around "effectiveness". I'm somewhat ambivalent about the book. I find it useful as a reference when I want to refer people to arguments about why they might use static factory methods instead of constructors, how they might approach exception handling, etc. But for my place in the value chain, there is other knowledge I also need to make my Java software effective. --RandyStafford

It's a pretty good book even though his recommended implementation strategy for the equals() method doesn't work properly when you sub-class because he suggests using instanceof. In fact you should be using the getClass() method to preserve symettry. i.e anObject.equals(otherObject) == otherObject.equals(anObject) when anObject and otherObject are super-class and sub-class. Would that give the expected behavior according to the general contract of Object.equals()? Wouldn't it require the parent class to know about all its subclasses in order to implement this? For example, if FooClass has subclass BarClass and the same developer implements both of them, it's possible for Foo to know about Bar, but if someone else (who doesn't have access to the source for Foo) comes along and implements BazClass using this alternate suggested implementation of equals, Foo won't know anything about Baz, and thus while a Baz might be equal to a Foo, a Foo will never be equal to a Baz.

Oops. I meant anObject.equals(otherObject) == otherObject.equals(anObject) iff anObject and otherObject are of the same class. See: http://www.blizzy.de/blog/page/blizzy/20040509#howto_implement_equals_correctly for a more detailed walk-through of the issues.

EditText of this page (last edited June 23, 2004)
FindPage by browsing or searching

This page mirrored in JavaIdioms as of October 22, 2005