Effective Java
Effective Java
Patterns, LanguageGotchas and general advice for JavaLanguage, organised into 78 dos and don'ts (57 in the first edition from 2001), each followed by an explanation and discussion. Modeled after ScottMeyers' EffectiveCeePlusPlus series. It's had some of the same success as Meyers' series, too: it's widely accepted as a fairly authoritative source of JavaIdioms and BestPractices. (Though while EffectiveCeePlusPlus seems to have gained its position of esteem fairly exclusively on its merits, EffectiveJava had the early advantage of being an offical Sun book whose author was already an important Java insider.) There is an emphasis on advice for creating good public (or "public-strength") APIs, which reflects both the author's experience as a major contributor to the J2SE libraries and Java's strengths in this area. (And one of its weaknesses: the poor library versioning that magnifies the importance of getting your API right the first time.) But in fact the book is a pretty wide-ranging selection of advice on general Java programming.
http://www.informit.com/store/product.aspx?isbn=0321356683#info8 lists all of the book's 78 commandments (you may have to click on the "Sample Content" tab).
Bloch's 2005 JavaPuzzlers book covers some of the same ground and uses a fairly similar format, but has a purer focus on LanguageGotchas.
The enumerations introduced as a primitive language feature in Java 1.5 are based on the TypesafeEnumPattern? described in the first edition of EffectiveJava.
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 symmetry. 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.
See also http://www.javapractices.com
EditText of this page
(last edited December 29, 2010)
or FindPage with title or text search