I have read last week end the second edition of one of the most famous Java books.
I loved the first edition, and I love even more this second shot. It have the same good layout of first edition, organizing arguments in chapters and items, with clear explaination of goals and pitfalls, very informative and stimulating. What is changed in this second editon? Not much and all at the same time, since Bloch have added items dedicated to Java 5 and 6 new features, and he reviewed about all contents updating it, giving even more ideas.
Yep, IDEAS. It’s the great plus of this (and few others books), it give you ideas and stimulate your own thought and investigation instead of just explain author’s point of view.
IMHO the first edition have been one of most important books in java initial success in fall 2001. I’m not sure this second edition would become so much important for this new Java developer generation as it was for my generation, but in my humble opinion they should read it. And not only them, but also for older boys like me.
In 2001 Java was different, java community was different, and I was different too. I was a young developer who had just moved to java (my first serious enterprise project had started in late 2000), java is a fair new language, with an enthusiast community. Today Java is much more consolidated, even if it’s starting to demonstrate some oldness symptom. Today Java community is much bigger, have provided great libraries and have guided some of best evolution of the language, maybe a little less enthusiast. The new edition of Effective Java reflect all this points, and it’s important to keep it’s value: helping reader to think and get ideas.
And how am I changed since 2001? Well I’m now a software architect (the right kind of architect 
) coaching about 20 developers and managing bigger developments and environments. I’m not changed too much: I still be enthusiast, I still be a developer and a technology passionate. What is changed is my point of view. As architect and (agile) coach I read this book thinking how great or bad code can influence my system, eventually enforcing or breaking my design. Reading this book I thought about how design is important at any level, but probably what really make a system successful is design at lower level, in other words fine design made by any single developer. It’s probably the main reason for which architect have to write code and coach have to consider its team as a chain: strong as its weakest link.
Groovy, Ruby and friends success would benefit a lot from a book like this one written for them. I don’t know nothing around similar, someone have suggestions about?
My favourite 3 items in new edition are (not easy to select just 3, but I’ll try):
- Item 2: “Consider a builder when faced with many constructor parameters”. why? Because in a lot of case it’s better to have readable code than performance or compact code. Frankly Java doesn’t help too much…so patterns and best practices are important.
- Both Item 15: “minimize mutability” and Item 40: “Design method signatures carefully”. No comments needed right?
- Item 26: “Favour generic types”. Generic types are very expressive, compact and flexible. Not so easy for all people, but too powerful…insist with developers to design generics type!
Well a special mention to chapter 10 “Concurrency” to few developer use concurrency effective…it’s the god and bad of J2EE…but real developers should design at least a serious concurrent application to perfect their skills.
Your preferred items?
