Good style/technique standards vital for a complicated and error-prone language.

A must for the Java Programmer

reviewed by Conrad Weisert, December 2001
copyright 2002, Information Disciplines, Inc.


Joshua Bloch has given Java programmers an equivalent to Scott Meyers's now classic Effective C++, and it's a solid winner. The structure of the new work is very similar to the earlier one. It presents a series of 57 more-or-less independent articles on various non-obvious aspects of Java programming. Nearly all of them provide worthwhile, enlightened guidance aimed at:
  • Operational reliability and robustness
  • Future maintainability and flexibility

The style is friendly and easily readable, but for some of the more subtle examples you'll want to have pencil and paper handy to reinforce your understanding as you read.

Although I've been writing and teaching Java for a half-dozen years, I learned a lot from Bloch's advice, enough to send me scurrying to redo some old programs and course materials. Most of the techniques he recommends will henceforth be part of my own standard practice.

Some of the techniques are even transferable to C++. Item 21, for example, shows us how to mimic C's half-baked enum facility with a Java class, but you can do almost the same thing with a C++ class.

Important: second edition update

Often when an updated edition appears, one can still make do with the older version. That's not the case here. The language itself has been changed so much that the first edition is now more confusing than helpful. If you have one, throw it away and get this 2008 one:

ISBN 0-321-35668-0, 325 pages.

The number of items has grown from 57 to 78, and they've been renumbered and regrouped. Fortunately, references to specific item numbers in the first edition needn't be updated, since an appendix lists the correspondences. —CW

Reflections on Java

Besides making the reader a better Java programmer, Effective Java may have an impact the author's employer, Sun Microsystems, would prefer not to publicize. The perceptive reader, whether a practicing programmer or a knowledgeable manager, will surely question the wisdom of choosing such a monstrously complicated and subtly error-prone programming language. Effective Java may well end up aiding the cause of Java's competition.

This is most evident, not surprisingly, in the many items concerned with pitfalls of Java's reference semantics. Item 24, for example, advises us to "make defensive copies" of member data initialized by constructors from references or returned as references by accessors, so as to prevent a malicious or careless user from modifying member data directly. That's excellent advice (at the cost of a lot of extra object allocation and creation) in Java, but wouldn't we prefer to work in a language where references don't get passed around with such abandon?

A few mild dissents

Alas, nobody's perfect. Experienced object-oriented programmers will take issue with a few of Dr. Bloch's recommendations:

  1. "The right way to solve the problem [representing amounts of money] is to use BigDecimal, int, or long, for monetary calculations." (item 31).

    No, no, no! The object oriented way is to use a Money class. Among the great benefits of object-oriented programming are type safety and data validation. Otherwise what's the point in using a complex object-oriented language to write Fortran-like code? And, by the way, using BigDecimal for non-trivial monetary calculations can be catastrophically inefficient.

  2. "Always override hashCode when you override equals." (item 8)

    Hash tables provide an efficient way of retrieving a data item by a key value. The key field is usually a discrete data item or a text data item, but rarely if ever a numeric data item. It would be bizarre to use an amount of money, for example as a hash table key. An even sillier example is Bloch's own Complex class (in item 13).

  3. "You should always make small value objects, such as PhoneNumber and Complex, immutable" (item 13)

    PhoneNumber, yes, Complex or Money never! Creating new objects and reclaiming memory are far more expensive than doing ordinary arithmetic. Scott Meyers addressed that issue for C++ by recommending that we implement simple arithmetic operators in terms of the corresponding compound assignment operators, and encourage clients to use the latter. The Java Money class on this web site follows Meyers's advice.

Those oddities didn't originate with the author, but have become common practice among Java insider zealots who lack experience with real-world applications, especially with numeric computation. While serious, those flaws don't negate the usefulness of this excellent book.


Highly recommended

Return to book reviews.
Return to Java topics
Return to table of contents.

Last modified May 23, 2009