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.

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.

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.

If you are interested in code, you will find very little in this book. If you are interested in the believes of the authors you get more than your share. The believes are not bad. In fact it is easy to agree with the authors at an 80% level. Also one finds some new thoughts. Still reading this book gives oneself a bad feeling.

Part of the reasons is easy to grasp. Writing three times how bad EJB is, is ok. But this opinion drops out of the entire book. It is much better to spend more of the audiences time with the good solutions and treat them real thoroughly.

A signpost does not have to go the way it is indicating. Still for a book on good Java/Software qualities, it is necessary that the authors also do deliver on true quality. Better Java reads like a layman speaking about Zen Buddhism. You might not have to be a Zen master but without an experience of enlightment/satori it is difficult to meaningfully speak about Zen.

This book seems to be an equal mix of pragmatic preaching and technical examples. The book makes sense, and if you're a person who thinks that J2EE applications are bloated, slow, and hard to maintain, then you'll love this book. Keep an open mind and take in what the authors are presenting.

This book seems to be an equal mix of pragmatic preaching and technical examples. The book makes sense, and if you're a person who thinks that J2EE applications are bloated, slow, and hard to maintain, then you'll love this book. Keep an open mind and take in what the authors are presenting.

This is a refreshing piece of work for the J2EE world that is rife with over-engineered non-performant complex applications. Many Java books try to teach you the details of the J2EE specs, but provide you very little PRACTICAL guidance on how to use the technologies to write flexible, well-organized, and performant systems. As an indepenent consultant/technical architect I have seen many different ways that clients have used the available J2EE specs to architect a Java application and so many times they get themselves into problems because they misused the technologies. This book really caught my attention when I first picked it up because it cuts through a lot of the hype and provides a good framework on how to look at designing a good, practical application with Java. Don't buy this book if you want to learn the details on how to use Spring or Hibernate, that's not what its for. It provides strong guidance on how to use Java and then illustrates those ideas by providing an overview of Spring and Hibernate while applying these principles. I think this is even more valuable because you walk away with the understanding of the principles and their application, which positions you to write your own framework that apply the philosophies or use these existing frameworks that follow this philosophy. I also think that the book is very well written, well organized and, therefore, easy to follow.

This book with its talk of the business "sponser" was not even spell checked. The code will not compile because in Java declarations are case sensitive. Whole paragraphs are repeated. The content is vague and seems to be more of a rant than an attempt to teach.

Horrible. One star is generous.

It is a very nice book. It is something that you would like to give to people who are into EJB most of their lives telling them its time to change. It's time to go to the gym and lose gallons of fat.

But if you are someone who really wants to know how things are done and how things work, I would not recommend this book. If you are into Hibernate, Spring, or other simpler frameworks or just want to learn these stuff, you don't need this book. Simply because you don't need a book that will only tell you what you already know; and that is, in java simple things are definitely not mediocre.

In my humble opinion this book gives you an insight to the future of java development. This book prepares you on what is coming. But unfortunately it is not enough, far not enough, to gear you up for it.

But in fairness this is not really an "in-depth" kind of book so may I rate it the way it is.

This book is really divided into two virtual sections: one outlining the principles of coding excellence, and the second section deals with technology choices that align with those principles. The first half explains the common wisdom of the day, which is to stay focused on the problem, keep the components decoupled and transparent, and to use unit tests and refactoring to keep the code slim (to "Sharpen the Saw" to borrow a term from Covey). There are other points that he makes but I found it to be mostly common sense if you've spent anytime developing Java in recent times.

The second half of the book provides a survey of technologies that help you apply these principles: such as Hibernate and Spring. However, it is a survey, and to use any of these technologies you have to get a more in-depth book.

I did find the section on the class loader to be good. I saw Justin Gehtland at the "No Fluff Just Stuff" Java conference and he gave a really in-depth presentation on this topic.

One more thing, the book is written by Bruce Tate and Justin Gehtland, however, almost the entire book is written in the first-person singular. Weird.

As the title implies this book is a scattershot of topics for improving your Java architecture and implementation patterns. Bruce is always practical and pragmatic in his approach and it's no different here. He covers test first development very well. There is also an excellent section on transparency. But much like a theme album this short book is supposed to be ingested whole. Definitely a must have for professional Java developers.

I am an experienced programmer, having used Java and many other languages on a variety of projects. In the last 2-3 years Java, and especially server-side Java has become increasingly important to me at work and I now spend a great deal of my time trying to understand the roles and relationships of the various J2EE technologies and their alternatives. For the most part I find these kinds of discussions worthwhile and very interesting.

'Better, Faster, Lighter Java' is very useful to me because: a) Its main contention that programmers need to be aware of and avoid Java "bloatware" agrees with my experience; b) Its authors provide some criteria to use to decide whether a Java technology is well designed; and c) It provides some alternative Java technologies to use as comparisons with ones that are too "heavy" and not as flexible or extensible. All this was done in a relatively brief book (itself rather "light").

Hence I appreciate this book for the synthesis of ideas it provides, the questions it raises and for its introducing me to alternative Java technologies that I'll now seek more in-depth treatments of.