Book Review: Java: The Good Parts

I recently had the misfortune of waiting at the airport for roughly six hours as my flight was repeatedly delayed 30 minutes at a time until it was ultimately canceled. The one silver lining in this cloud was that I was able to read almost all of Jim Waldo's Java: The Good Parts while I waited (the book comes in at under 200 pages). In this post, I talk about what I like best about this book and who I believe its best audience is.

In Java: The Good Parts, Waldo writes about parts of Java that he has used and that he has found to be the best parts of Java. His specific focus is portions of Java make it most suitable for certain situations. These situations tend to be large and complex applications that need to run on multiple platforms and will be used and maintained for a long time. In short, Waldo states that "in this book, I talk about the good parts of Java" which he defines as parts of Java that he has used "that aid in writing programs (or parts of programs) in which Java itself is the appropriate choice of programming language and environment."

Looking at the table of contents for Java: The Good Parts not only provides a quick overview of the main topics of the book, but also provides a list of what Waldo considers the "good parts" of Java. There is essentially a chapter devoted to each of the "good parts" and the chapters are on the type system, exceptions, packages, garbage collection, the JVM, Javadoc, Collections, RMI and object serialization, concurrency, and the Java development tools.

For the most part, I agree with Waldo's assessment and generally agree that the items he covers as "good parts" of Java are indeed good parts. The fact that I already felt this way about these items and the fact that I already embrace many of Waldo's recommendations in my Java development may explain why I feel like I didn't learn much about Java or how to use Java. That being stated, I wasn't sorry for reading this book and explain that more in this post.

I think that Java: The Good Parts is probably best suited either for someone with basic familiarity with Java who wants to improve his or her ability to write maintainable Java code. It is probably best to have at least passing experience with Java because the author assumes that. For a developer who has worked on very large systems using Java, many of Waldo's observations are easy to agree with and articulate the experienced Java developers' own experiences. I have read (never all at once) Effective Java and other resources on writing better Java regularly and did not find many new observations in this book, but I think it could be highly valuable to a Java developer who has not invested as much time in reading about improving his or her Java skills.

Although I already was aware of most of what I read in Java: The Good Parts and, more importantly, already generally try to apply many of these principles in my own Java development, I still enjoyed reading this book while waiting at the airport. The main reasons I enjoyed it, which I will discuss a little further, are the historical context it provides and the opinionated writing style of the author.

One of my favorite aspects of Java: The Good Parts was the author's willingness to take a stand and unequivocally make his points. Although he did occasionally acknowledge that there are times when even his strongly held judgment had to bow to other practical concerns, Waldo generally made it clear what he believes are the correct and wrong things one can do with the portions of Java discussed in his book.

Here are some of the funniest of these quotations that did not mince words:

• Classloaders are the source of many of the most painful parts of using Java, so I like these Waldo quotes on classloaders:
• Classloaders Quote #1: "But God have mercy on your soul if you ever have a program or system where you cross classloader boundaries."
• Classloaders Quote #2: "But this book is supposed to be about the good parts of Java, so I'm going to avoid talking about classloaders whenever possible."
• Regarding people who complain about Java's exception handling: they "either don't understand it, don't realize what it can do, or are simply lazy twits who don't care about writing reliable code."
• Mixing error-handling code with main code is the "mistake of a puppy programmer."
• The developer who develops an API with runtime/unchecked exceptions only is a "corrupter of others."
• Regarding swallowing exceptions by not doing anything the the catch clause: "I’ve not seen this, because I work with adults."
• Unnamed packages are only used by "confused, obstinate, or lazy programmers."
• Regarding developers not documenting better: "All programmers also know that it is important to floss, to bathe regularly, to wear seatbelts and not talk on cellphones in the car, and to dress for success. And like all of these other things that we ought to do, when the pressure is on and deadlines loom, we tend to “forget” to do those things. After all, they don’t directly lead to getting the code working. And they can be added later."

Although I don't agree with some of the assertions (at least to the extreme degree), the descriptions are still humorous and make their point.

I think that my favorite aspect of Java: The Good Parts is the historical accounts that Waldo has woven into the text and into notes. These include references to some interesting online reads, but also include accounts of what went into decisions at Sun regarding the good, the bad, and the ugly of Java. Waldo was involved in many of these discussions firsthand and the insight he provides into what went into these decisions is fascinating. It's a reminder that even the developers of the Java programming language run into the same design decisions and their consequences, both good and bad, in the long-term. Software developer, whether of a language or of an application, seems to always involve this. More than once, I was almost relieved to read why some seemingly ridiculous Java things now are perfectly explainable in their origins based on the motivations of the time.

Although I already attempt to practice much of what Waldo preaches in Java: The Good Parts, I liked how he articulated some of the same observations I have made, but not articulated as well. For example, he states (in a parenthetical) about design: "most design dictates boil down to personal taste, which doesn’t make them any less correct, but that’s the subject of a different book."

Perhaps my least favorite aspect of Java: The Good Parts is the numerous typos and similar errors. That being stated, there is currently a dearth of confirmed errata on the book's web page, but there are entries on the unconfirmed errata page.

Most of Waldo's assertions and observations are highly similar to my own and, I think, to many Java developers. The one chapter that is likely to be controversial is the chapter on exceptions. I will likely devote a separate blog post to Waldo's coverage and opinions on exceptions, but the essence of it is that he presents exceptions in Java as of the checked exception variety with the unchecked exceptions being a necessary evil meant only for carefully controlled situations. The basis of this assertion is the idea that checked exceptions force the thrown exception to be part of a method's contract and this is supported by the assertion that a thrown exception is really an alternative form of a return from that method. Although I'm not ready to throw checked exceptions out completely like many are, I also do not feel that runtime exceptions are as evil as Waldo asserts. Indeed, my issue remains that it is often much easier to talk about, than to actually write, an effective and useful exception handling mechanism other than logging the state at the time.

Java: The Good Parts does not intend to be and is not advertised as an introduction to Java. These days, it's far too short to be that. I like to find Java books that are not introductory, but that are approachable and provide something more than "here's how to do so-and-so in Java." This books fits that bill. For an experienced Java developer who has observed his or her own lessons learned and learned from others, much of this book will provide a reaffirmation of what he or she already knows. For the newer Java developer who wants to become a better Java developer, this book will help see some important ways to do just that. Effective Java is still by far my favorite book on how to write better Java, but this book provides a different approach that may be useful to a newer Java developer. What Java: The Good Parts has to offer above just about any recent Java-oriented book I can think of is a historical perspective on why things are the way they are in the world of Java.

I almost never read a technical book cover-to-cover. Indeed, I read very few of my technical books all the way through at all. Thanks to the airport fiasco, I had the opportunity to read Java: The Good Parts from cover-to-cover and I was happy to have that opportunity. Many of the practices I embrace were reaffirmed, but I was even more interested in the historical perspective I gained about what has motivated Java to be what it is today.