Effective Java: An Interview with Joshua Bloch
Effective Java: An Interview with Joshua Bloch
Joshua Bloch talks Java development, industry evolutions, and Effective Java.
Join the DZone community and get the full member experience.Join For Free
Delivering modern software? Atomist automates your software delivery experience.
[img_assist|nid=3054|title=|desc=|link=none|align=right|width=100|height=133]The most anticipated book among Java developers over the past few years has been the second edition of Effective Java by Joshua Bloch. The book was finally launched during JavaONE this year. I caught up with Josh and discussed the book, the changes in industry since the last edition and his thoughts on closures.
Want a signed copy of Effective Java? Subscribe to DZone Refcardz and be automatically entered into our competition to win one of three copies exclusively for DZone members.
James Sugrue: The book was made available at JavaONE. Did you do any technical sessions to coincide with the release?
Joshua Bloch: I did two sessions. On was directly related to the book. It was called "More Effective Java." It was largely devoted to enum types (Items 30-34, 77), but also included a mnemonic for the use of bounded wildcard types (Item 28) and a guide to lazy initialization (Item 71).
Sugrue: What changes have been added to bring to book up to date?
Bloch: I added two chapters, one on Generics, and another on Enums and Annotations. Also I added items describing best practices for each of the new language features in Java 5 (for-each loop, autoboxing, varargs, static import). I changed the title of the Threads chapter to Concurrency and rewrote it to reflect programming in the java.util.concurrent era (where the basic abstractions are tasks and executors, rather than threads, wait and notify). There's a table on page 1 that points you to all of this material.
In addition to adding material on features that were added to the platform since the first edition of the book, I added items or modified existing ones to reflect the evolution of best practices. For example, I added an item describing the Builder pattern (Item 2), and one describing the Serialization Proxy pattern (Item 78). I went over every line of every item, and did my best to make sure they were up to date.
Sugrue: Is it fair to consider this as a whole new book?
Bloch: No! I did my best not to change the character of the work. I hope it feels like an old friend to readers of the first edition.
Sugrue: Since the first book in 2001, what key changes have you observed in Java development?
Bloch: The biggest changes are the rise of modern IDEs, such as Eclipse, IntelliJ, and NetBeans, and static analysis tools, such as FindBugs. Agile techniques, which were just making inroads in 2001, have become mainstream.
Sugrue: Effective Java is seen as one of the most important books for Java. Considering it's popularity, were you wary of making any changes to such a well established book?
Bloch: Very much so. That's why I tried so hard not to change the character of the book. Of course I had to cover all of the new material, and I had to critically examine everything I said in the first edition. But I did everything in my power to make sure that nothing got hurt in the process. I hope I succeeded, but I won't know for sure until I've heard from readers of the second edition.
Sugrue: Every developer should read this book - but some might not be able to make time. For those, if you were to promote just one message from the book what would it be?
Bloch: I was asked the same question the very first time I was interviewed about Effective Java, back in June 2001. This is what I replied: Always strive to write simple, clear, and correct programs. It is penny wise and pound foolish to do otherwise. Style does matter. It pays real dividends in terms of correctness, usability, robustness, and maintainability. Also, it's way more fun to write good programs than bad ones.
I still believe every word.
Sugrue: What is the most common fault in Java developers in your opinion?
Bloch: Like most programmers, we have a natural tendency to optimize our code even when we should know better. Our attempted optimizations don't always make the code run faster. Sometimes they just make it more complicated.
Sugrue: The book includes hints for class and interface design. In one paragraph, can you describe a guideline for a good design?
Bloch: I apologize if this sounds trite, but each class should do one thing, and do it well. There's a great litmus test: can you, in one short, clear noun phrase, describe what an instance of the class represents? If not, you should probably spend more time thinking about the design.
Sugrue: Scripting on top of the JVM has become very popular over the past year or so. What do you think of it?
Bloch: I'm a pragmatist. Often it's the easy way to get things done, and that makes it good. Of course you should write your scripts with all the care that you write your programs, because they'll have to be maintained in parallel with the programs.
Sugrue: What is your opinion on the inclusion Closures in Java 7?
Bloch: As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.
Sugrue: To Java developers your book is seen as a bible. Can you recommend any other books to sit alongside yours on the developer's bookshelf?
Bloch: Sure. For concurrency, I recommend Java Concurrency in Practice by Goetz, Peierls, et al. For bit twiddling, go with Hacker's Delight, by Henry S. Warren. A couple of classics that only improve with age are Frederic P. Brooks's The Mythical Man Month, and Jon Bentley's Programming Pearls. And every programmer should read Strunk and White's The Elements of Style. Not only will it make you a better writer (which is an important part of being a software engineer) but it will make you a better programmer. Programming and writing have a lot in common: both are about expressing yourself clearly and concisely.
Opinions expressed by DZone contributors are their own.