The book starts off well and the author makes several good points about having lighter objects and not being tied to a particular framework, but then it digresses into refactoring evangelism. Despite what this apologist believes, design cannot be neglected altogether as refactoring becomes more and more expensive as a system grows larger and parts get more complex. Just look at all the items still left over from Java 1.0 or 1.1. How many methods has Sun deprecated that are still around? Take many of the concepts to heart up to about page 50, then just chuck the rest.

Design well, but have allowance for refactoring. Build smaller pieces and not monolithic objects.

I recommend the first set of chapters in this book for EVERYONE. While it helps to know J2EE/EJB to step through the examples, the author provides a wonderful, thought-provoking and inspiring coverage of software design in general.

The first pieces of the book (actually, up to Chapter 7: Hibernate) discuss the joys and perils of simplistic approaches, over-architecting, under-architecting, evaluating available libraries/APIs, etc.

This is a great coverage of the software engineering process from gathering requirements to coding and from choosing a programming language to dealing with management. A simple, easy read.

The downfall of the book is that it doesn't promise what it advertises: Better, Faster, Lighter Java. The primary focus is on the underlying, architectural choices, not on the Java language itself. However, my downfall was purchasing based on title (as a dual-Amazon suggestion) instead of reading the description.

This is a great book. It compares different tools, and shows how to keep things simple and maintainable. Whether it's common sense, like other reviewers wrote, depends on your experiences.

It's easy to get overwhelmed by all the different Java tool acronymns- this is a sane response to all the marketing based feature creep.

If you are a beginning/intermediate programmer, I think this is a worthwhile read.

They work on five basic principles which, as another reviewer hints, makes it read a little like Covey and that is bad. Covey is a snakeoil salesman who reinvents his time management systems every three years to sell a new book. This book with its daddy Walton house building and kayaking action man morality tales is all quite patronizing.

The home spun tales seem to be Tate's, so I assume Gehtland does the coding. Unfortunately I don't think he read the book since he does not follow the principles that the book espouses: way too much duplication, not very OO (too many if/else; poor exception handling), unthinking dependencies on implementation (e.g Axis, Lucene).

Hibernate and Spring are powerful tools that help in the real world and there are better places to go and find out about them without all the whining.

I loved the premise of this book, because I, too, believe that Java - and programming in general - is getting out of control. Languages, frameworks, and products are adding so many features that it is now literally impossible to have a handle on the language - or even the subset - that you are using. Gone are the days where you can sit and try to figure something out; now programming seems to have boiled down to finding code you can cut and paste (Can you really figure out how to implement, say, an SSL client on your own?), then wrestling with the overwhelming complexity of the APIs, configuration, deployment, framework(s), your IDE, you-name-it.
Anyway, enough ranting. That's what the book does. And I agree with it. I also agree with all of the good programming principles that the book espouses. The problem I have with it is that it seemed to be a hodgepodge of ideas, practices, and solutions that did not always seem to relate to the title of the book. Don't get me wrong - they're good, but I... well, I guess I was just hoping for more. Like I said at the outset, I think this is a SERIOUS problem that needs to be addressed, and I'm not sure the book did it. ("Not sure" being the operative phrase there. Maybe I just missed the overall picture.)
Then I started thinking, well, how does one address/attack this problem? Truth is, I don't know. Maybe you can't. Can any one of us, or any one organization or any one book, change the direction of Java programming, which is being chartered by a small group of large companines? Heck, look at the Java Lobby (www.javalobby.org) It's a great website that has been around since Java's beginning, but have they really effected any change? They try, but mostly it boils down to the same cast of characters sharing their ideas (and flames) with one another.
Bottom Line: I don't know what one can do to change the state of Java programming. These guys try - they certainly did a lot more than I'll ever do - but I'm not sure if this book will do anything except encourage certain good, common-sense programming habits. And some of its advice - like "Life is too short to be stuck with a bad manager. If you don't like your job, find a new one" makes sense on the surface, but have they looked around the real world lately?
In closing I want to firmly agree with what one reviewer said: The fact that this book has two authors, but is written in a *strong* first person sense, is definitely, definitely weird.