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:
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.
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?
Alas, nobody's perfect. Experienced object-oriented programmers will take issue with a few of Dr. Bloch's recommendations:
BigDecimal,
int, or
long, for monetary calculations."
(p. 150).
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.
hashCode
when you override equals." (p.36)
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 (p. 64-65).
PhoneNumber
and Complex, immutable
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 January 12, 2003