Java 2 Performance and Idiom Guide

Craig Larman and Rhett Guthrie

Prentice Hall

ISBN 0-13-014260-3


Reviewed Feb 1, 2000

As its title indicates, this book is split in two major parts : performance and idioms. The performance part spans over ninety-pages (one third of the book) and the idiom section covers the rest.

Performance recommendations can be either "major moderate", "moderate minor" or "minor". While the terminology is a little obscure, each chapter is introduced with a five line summary describing what is going to be discussed. This is a very good practice that I wish I could see in more books.

The performance section is pretty exhaustive. All the different methods are covered : more hardware, more memory, using external tools and, finally, modifying one's code. Of course, it is that last part that retained my interest. A lot of literature has been published on the topic, both on paper and electronically, and I think this book does a pretty good job at summarizing the most important ones. The rules are often simple and illustrated by meaningful code. The authors don't fail to mention that EJB containers are typically very good at taking care of those details for the developer.

I was relieved to find recommendations that I have myself learned the hard way over the past few years ("Use StringBuffer rather than String concatenation", "Use externalization instead of Serialization"). It validates both my impressions and the soundness of the advice given by the authors.

However small, the performance section still falls a little bit short to my taste. By the end of the three chapters, the recommendations become more and more obvious, and not very likely to cause even a minor improvement. I'm not sure if it comes from the fact that there is only so much you can do to improve performance in Java or if the authors were afraid to delve into more complex considerations that might deter the reader (for example, the part about Strings fail to mention that String.substring() will cause memory for the original string never to be released, which can become a problem when working with transient big strings).

The second part of the book is about idioms, and more specifically, library idioms (which occupies most of this section), language idioms, packaging idioms and test idioms. Some idioms such as using reflection to implement factories are interesting, even if I would probably not make this choice for the obvious costs that reflection imposes. Others are reasonable summaries (such as the concurrency section, but interested developers should pick Doug Lea's books for a more in-depth discussion of those issues).

The Collection idioms might have been richer, but then again, the authors decided to focus on the essential. A discussion of the Collection packages could fill a 300+ page book by itself.

This being said, I sometimes find myself in disagreement with the authors. Sometimes on minor points, such as the enum section (where they fail to notice that their implementation will not work with switch) or their recommendation for inner classes.

The weakest part of the book is about coding conventions. Several of their recommendations are at a radically opposite direction from the consensus that has emerged over the past few years in the Java community. I'll take two examples.

The authors promote the use of "import star" statements (import foo.*) instead of enumerating each imported class. From my experience, this practice makes it really hard to read code. Here is an example to illustrate my point.

Consider

 
import acme.core.*;
import acme.utils.*;
import acme.ui.*;

// ...

void foo(ISection section) {
  section.doSomething();
}
 

When you reach section.doSomething() in your reading, where is the code going ? You have no way to tell. The problem with "import star" statements is that they make it necessary to use a debugger in order to understand what the code does.

Consider the alternative :

 
import acme.core.ISection;
import acme.utils.SectionImpl;
import acme.ui.MyWindow;

// ...

void foo(ISection section) {
  section.doSomething();
}
 

I find this style much more readable. A few extra seconds spent adding the import manually will be much than made up for later.

Another justification the authors use is that enumerated import statements can span over several screens, forcing you to scroll down. I find this argument pretty weak for two reasons :

  1. We are not trying to limit the number of lines but improving readability of the code. The header of the class will not be read very often as opposed to the code in the methods.

  2. Hopefully, the javadoc describing what your class does will be as long as possible, so it seems like a Java source code header is bound to be long and verbose anyway.

Another recommendation I disagree with is in the "Idiom for field names" section, where the authors actually recommend *not* to use any convention. Then again, this is the source for quite a few nasty bugs that could be easily be caught at compile time. The irony is that the authors themselves cite the "killer" example :

 
public class Foo {
  String name;
  public Foo(String namee) { // bug here, but will compile fine
    this.name = name;
  }
} 
 

but dismiss this occurrence as rare. They do not give any justification for their recommendation.

However rare, bugs that go unnoticed at compile time when the compiler could find them for you are a sure symptom for a flawed coding style. There are additional benefits to using a distinct syntactic convention for fields. Readers interested in this topic can refer to a this more detailed discussion.

Another debatable convention is to prefix interfaces with a capital "I". While it is pleasant to be able to identify interfaces right away when you read code, doing so can also be seen as breaking the encapsulation (by revealing the underlying implementation). And if one day, you decide to replace the interface with an abstract class, you will be facing a very difficult dilemma...

CONCLUSION

Despite my clear disagreement with some of the advice given in that book, I still recommend it.

While regular readers of the advanced-java mailing-list will most likely not learn a lot from this book, I think the authors achieved their goal : gathering he quintessence of knowledge that every Java 2 programmer should possess in a comprehensive and reasonably sized book. For developers who are about to switch to Java 1.2, this book is a must-read as it emphasizes the crucial aspects of the new libraries, and most notably, how to choose and use the Collection packages.

Cedric Beust


Back to the menu