Bruce A. Tate and Justin Gehtland: Better, Faster, Lighter Java. O'Reilly & Associates, 2004, 0596006764, 243 pages.
I sometimes think that Ecclesiastes must have been a programmer. "The
thing that hath been, it is that which shall be...and there is no new
thing under the sun." I don't know about you, but it sure reminds me
of the never-ending debate between people who want comprehensive
frameworks so that they can assemble applications out of tried and
tested components, and those who want to keep their libraries light,
agile, and (most importantly) comprehensible, even if it means
building more of each application by hand.
This new book from O'Reilly is the latest salvo in this war's Java
front. By now, most developers would agree that Enterprise JavaBeans
(EJB) is a mess. As Tate and Gehtland point out, any system which
requires you write half a dozen classes and XML deployment descriptors
in order to implement a simple integer counter must have taken a wrong
turn somewhere. The alternative they propose is certainly attractive:
Hibernate (www.hibernate.org) to persist POJOs (Plain Old Java
Objects), and Spring (www.springframework.org) as a container, are a
fraction of the size of full-blown EJB, but can do most of the things
that most programmers want most of the time.
But a book isn't just a point of view; it's a presentation of a
point of view, and that's where this one left me unsatisfied. First,
there were more paragraphs than I wanted on the future of the industry
(they seem to feel that any company with more than a dozen employees
is a swamp of self-serving hypocrisy), and too many
motherhood-and-apple-pie statements about the virtues of simplicity
and transparency. Simple in whose eyes? Transparent by what measure?
I'm pretty sure the programmer they mock on pg. 17 thought his code
The authors do much better when they get into the specific technical
problems of EJB, and the ways in which lighter frameworks are better.
However, once they start doing this, they aren't as critical of their
favored alternative as they are of EJB. For example, five of my
students at the University of Toronto have been working with Hibernate
for the last four months. We definitely prefer it to JDO, or to
rolling our own persistence layer, but we have still had to bend some
of our data model out of shape to fit Hibernate's needs, and debugging
mapping files is about as much fun as, well, debugging EJB deployment
I came away from this book feeling that the authors never made up
their minds whether they were writing a polemic, or a technical
how-to. A little of one mixed into the other would have been fine,
but the balancing act they seemed to be striving for just didn't work
for me. Everything they discuss is worth knowing, but this book may
not be the best way to pick it up.
comments powered by Disqus