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 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.

This book delivers a great message in the worst possible way.

It is useful if you are trying to persuade a PHB (management) that going with a full-blown EJB solution doesn't make sense.

If you need to convince an architect about this, give them Rod Johnson's book "Expert one-on-one J2EE Design and Development without EJB".

If you want to actually learn anything about the approach and philosophy, don't use this book. For one thing, the authors are working on a broken definition of "coupling" and fail to address "cohesion" by its proper name. In short, there is a lack of depth and rigor in what they are presenting that, at times, leads them to recommend approaches that aren't necessarily valid. For example: Using a message passing API without a strict message format definition (such as a WSDL definition in the WS world) actually leads to tighter coupling because the author of a service client must inspect the code of the service in order to understand the rules of exchange (the API). By definition that is tight coupling. The omission is minor, but significant in understanding the pitfalls of message-oriented service integration.

In short, AOP and related ideas are all about cohesion. Not just on the function or method level, but on the interface and class level. "Separation of concerns" sounds a lot like "functional cohesion". Not addressing this well understood issue by its formal name denies the reader the opportunity to find the broader body of knowledge on the subject. Why reinvent the wheel?

I guess if I had to sum up why this book isn't worth your money is because it is dogmatic and not prescriptive. The great thing about Rod Johnson's book is that it tells you not only when it is appropriate to take this approach, but the different ways to do so. The examples presented here are straw-men and "hello world" (as described above). What would be nice is a full example that brings all the pieces together. An implementation of the Java Pet Store using this approach, fully described point-by-point would be a nice approach.

Bravo for a very timely book. One of the advantages of Enterprise JavaBeans and similar approaches to programming is it allows for faster development of code. However, there is a price to be paid for this programming convenience. The price is generally large bloated code. With each line of code the speed of the application slows down, the size of the program increases, and more opportunities for errors are introduced. Better, Faster, Lighter Java sounds the clarion call for better code writing, project management, and maintenance. The authors also include chapters on other open-source products, such as Hibernate and Spring, which can help keep the code clean and build projects using a container model like EJB without all the unnecessary overhead. Better, Faster, Lighter Java is a highly recommended book for Java programmers.

One may love 'Better, Faster, Lighter Java' or may hate it -- but it's a book that is difficult to ignore. Because, the authors had the courage to state their viewpoint against the growing trend of spiraling complexity of J2EE development. Because their book steps back from being a conventional tome on cranks-shafts-gears of a big J2EE engine and asks the important question of how to maintain the core design principle of KISS (Keep It Simple, Stupid) in the face of ever-growing complexity of frameworks. They rightly identify that bloat -- the growth of complexity of any successful infrastructure -- is inevitable. Any intermediate to advanced Java developer who had been confronted by emergence of mega-frameworks that promise to solve the problem but become a problem by their own volition will find this book useful to fight the bloat.
The authors presented their strategy to fight the bloat with suggestions, practical advises and associated tools such as JUnit, Ant, Hibernate, Kodo or Spring. This book is not a reference to these agile technologies but provides enough information on their design principles to justify how they can become the foundations to build reliable, extensible enterprise systems.
The suggestions such as 'Do one thing, and Do it Well', 'Strive for Transparency', 'Allow for Extension' are direct, full of experienced insight and supported by definite examples and best practices.
The beginning sentence of the book simply states: Java development is in crisis. Now that is a strong assertion. The J2EE evangelists and architects and big application server vendors will surely disagree. But the book is full of such opinions. One may agree or disagree with these assertions but their directness will make one think. That, in my opinion, is an important purpose of any book. In that sense, it is an important book for those who like to think what they are doing.

I've had this book for a few months now and I've read and re-read several sections. I also went back and forth as to whether or not I agreed with some of the information so many times I gave up counting. So, I guess if nothing else this book made me think - which is always the hallmark of a good book, in my opinion. The book is organized well and the authors present their case for "Better, Faster, Lighter Java" in a careful and concise manner.

This is not really a "here's how to implement technology X" book (i.e. if you want to learn about Hibernate, pick another book). It does more to promote concepts and ideas to avoid "bad programming". It provides a lot of opinion and argument for and against various frameworks, design patterns, programming methodologies, etc. It is quite obvious the authors are convinced and passionate about their view of software development. If you've ever asked yourself, "why do we have to use such complicated stuff to do even the simplest of things?", then this book will give you plenty of ammunition to backup your argument.

It's a rare software development book that I actually read (let alone re-read) almost cover to cover. While you may not agree with everything in the book, it will make you re-evaluate your development techniques.

Coming from several projects that used EJB successively, I almost wrote off the authors' first few chapters to be yet another polemic against EJB. While I agree EJB isn't without its problems, it certainly has found a niche with major J2EE server vendors, such as BEA and IBM. Therefore, like it or not I think EJB is here to stay in some form or another (don't forget EJB 3 is a work-in-progress addressing several issues), unless vendors become more amiable to introducing or promoting more "lightweight" frameworks into the fold. However, I see the following dilemma for them:

1. How do vendors make money with efficient lightweight frameworks? It seems like they are already making their mark off of improvements over the base EJB spec or building frameworks of their own, like BEA's Beehive Java open source (JOS) project.

2. Which one reigns supreme? With so many choices, it's enough to make a J2EE developer's head spin [off]. The J2EE community seriously lacks an "architect" (i.e., Bill Gates) to that end. All the in-fighting that goes on in our community makes me wonder if we stand a chance against a more organized .NET solution in the years to come.

However, despite my issues some of the predilections of the book, I found most of the book quite enlightening. Don't get me wrong, the authors expound on 5 very sound principles as their premise for fighting programming bloat. But as they state in the Preface, this book is neither for the faint-at-heart or the Java smarty-pants. It's for those who wish to get some exposure to common sense best practices using sound architectural and Java programming principles (layering and reflection, for instance). I was personally fond of the "Strive for Transparency" chapter and his segue later to the Spring framework. Good coverage of the Reflection API was a nice refresher and the discussion of the new bleeding-edge "dependency injection" idiom was quite useful in understanding the basis for such DI (or IoC) frameworks.

But the authors don't stop with simply a cerebral dissertation on the new world order of Java programming. He leaves the second half of the book for the pragmatist by explaining how the major JOS players put these principles to good use vis-à-vis the Hibernate and Spring Frameworks. The coverage is short but to the point, and great to get up and going fairly quickly with both frameworks (however, it's not a replacement for the reference docs). Both these chapters reaffirmed my understanding of these frameworks and as a user of both Hibernate and Spring, I thought that presenting two prominent frameworks that are open source, made these concepts very accessible for Java developers to further explore without making up some silly made up HelloWorld application.

The authors leave you with some things to ponder under "Where do we go from here?" They often mention Aspect oriented-programming (AOP) and quickly cover that here. Since these new frameworks leverage AOP (Spring even offers a skinny-down version of AOP or AspectJ integration), I think my next step is looking toward leveraging this further in future programming. This topic seems to be gaining some momentum in the Java community and extends the principles that the authors bring to bear in this book.

This is a very good book. A must for anyone willing to be a good programmer. It is a great feeling to find a book that has the guts to stand out and say: "EJB sucks real bad !!! Stay way from it as much as you can!"

If you write complicated code that only you can understand, if you are proud of your complicated solutions, then you need this book in order to succeed in your programming career.

However I found this book a little boring, as it has too much text and few code examples. Like Inversion of Control and Dependency Injection, two important topics, the author explain them with text instead of code. But like a CD, a book can be worth the money for just a few pages.

The author is very humble, but he probably belongs to the dream team of Java professionals. He just gets the work (efficiently) done, and that is what customers care about. To understand what I am trying to say, read the chapter about the Simple Spider. I didn't understand very well his code, but he solved a complex problem, actually a 18000 bucks problem, with simple solutions.

Better, Faster, Lighter Java is the best technical book I have read all year. I like Bruce's five core principles and how he applies it to the software you are building and the software/frameworks you are using. I also think the book should have been called Better, Faster, Simpler Java, since most of the goal of the book is to explain how developing enterprise Java applications can and should be simpler. But instead of taking the approach of creating tools to simplify Java like the vendors do, Bruce and Justin explain how to use existing open source frameworks and good development practices. Finally, at a mere 233 pages it is a quick read but full of valuable information. For example, I had been using hibernate for about three weeks when I started reading the book. I happened to be having a hibernate mapping problem while reading the hibernate chapter. Fortunately I found the answer I was looking for explained in a clear manner in this book. I wish I had read the chapter before I had spent several days searching online materials.

The content isn't very helpful at all (mabye if you are a beginner but i doubt). He always stays at the surface (what isn't necessary bad) but he doesn't explains the big picture as well. E.G. I learned on short article by Fowler more about IoC than in his whole book.
Complete waste of time and money.

"Better, Faster, Lighter Java" does a great job of walking the reader down a path to successful J2EE projects. In the vein of "Bitter Java" and "Bitter EJB", it exposes some of the myths -- both procedural and technical -- in today's J2EE world. Additionally, it goes a step further than the "Bitter" series by providing holistic solutions to managing and implementing successful projects, rather than localized solutions to specific anti-patterns.

The first few chapters provide excellent coverage of practical agile development, as is often seen in the real world. Bruce and Justin explain the motivations behind concepts like test-driven development, continuous integration, scope definition and creep, and the trade-offs of coupling. They then show examples of how to implement these concepts in an enterprise Java project. These concepts are absolutely critical to any non-trivial project, as they make or break the ongoing maintainability of a project. Anyone who has not used agile processes in the real world (i.e., anyone who thinks that tests belong in the QA department only) should read this book just for those chapters.

The book then continues to discuss common framework components and how they interact, including the pros and cons of different persistence and container strategies. In an interesting twist, the authors analyze the framework components discussed against the criteria for successful projects established earlier.

One of the points that the authors make is that a project should do one thing, and do it well. This book focuses on one thing -- a high-level analysis of how to execute on a successful development project. This is not a definitive reference guide on any of the technologies or processes discussed. Rather, it distills out the essence from the various types of components that you will encounter in your project, and puts them together in an easy-to-follow format.

One gripe that I had was that the Hibernate and Spring chapters delved a little too deep into their respective topics. I would have preferred to see more coverage of other aspects of the development cycle (preparation of content for hand-over to the UI design team, the role of Swing / SWT front-ends in enterprise development, etc.) rather than more depth on particular framework components.

When the bottom line is getting things done, Java developers are suckers for complexity. At least, that has been the history of the past few years. Those of us who have actually walked through this wall of fire become the new priests ( until the next complex API is released, anyway ). This book presents an alternative.

Bruce and Justin are creating a big problem for the priesthood, and this is long overdue. The book is straightforward and direct, and if you haven't used IOC or AOP yet, might be a refreshing eye opener. If you are looking for some kind of wacko Wrox-like book with millions of lines of quickly outdated sample code, this isn't what you are looking for. But that kind of stuff is best maintained online anyway, and kudos to the authors for not trashing up the book by including it here.

My only real complaint is personal, it presents Spring as the only IOC containter to consider. Perhaps it is because my favorite alternative - Keel - as of July '04 comes with it's own wall of fire. So maybe this oversight is justified. :)

As a professional Java developer and unless you've been living in a cave for the last several years, you certainly know about the concepts of agile/eXtreme programming such as using JUnit, refactoring, striving for simplicity etc. All that is wrapped up in the first part of this book (pp.1-128) and it is not done particularly well: The examples are kind of 'Hello World'-ish, so there's little to be learned even for beginners.

The two chapters about the Spring framework and Hibernate are also rather short (pp. 129-175) and merely scratch the surface of those solutions. The documentation available on the respective websites is far superior.

My conclusion: this book is largely superfluous and a waste of paper. If you really want to know about Spring, check out the website and read the superb, in-depth "Expert One-on-One J2EE Design and Development" by Rod Johnson.

I was a big fan of Bruce Tate's "Bitter Java", where he described some of the big bad problems of servlet/JSP development--the magic servlet, the monolithic JSP, etc. They were lessons I learned the hard way on the job, from having to maintain and extend code that fit right into those categories. Here, Bruce and his co-author Justit fight a different dragon--that of bloat and overcomplexity in Java application development environments. They explain why it happens, sort of acceding to its inevitability, but at the same time shows what we can do about it. Without advocating specific frameworks or techniques, they demonstrate how one can build solutions that don't depend on bloat and overcomplexity. In a world where everyone developing new APIs and frameworks is *claiming* that they don't want to become "the next EJB", unfortunately there are already too many "next EJBs" already out there and more seem to come every day. Bruce and Justin do justice to the notion that the best solution often is the simplest, and lead the pack in the movement to "take back Java" from the tendency towards "flexibility through complexity".

Well, here is something different. This book talks frankly and it explicitly contradicts scads of other books on Java. The authors' basic message is that Java and other constructs and standards like XML, J2EE, EJB and Web Services, have grown too bulky. That often, these, or affiliated design patterns, can lead you into a cul-de-sac of complicated and slow code.

I don't agree with everything they said, but much of their book may touch a chord in you. Most of their ire is devoted to EJB; especially entity beans, which they consider totally useless. For MDB and stateless session beans, they suggest these are best used when you typically have transactions across a distribute database. In general, the EJB code is too verbose. Conceptual clutter. And to avoid this, you may end up dependent on a developer framework that autogenerates some source code. Plus, most executables using EJBs end up being too slow. This complaint echoes what many others have noted for years.

On a related theme, the authors suggest Web Services are too heavy. Designed by committee and very complex. Before anyone has had extensive experience with a successful version. Not unlike how EJB and CORBA came about.

In general, they recommend that you choose the simplest tools and frameworks you can find. Stay with these as long as you can. And take with caution the siren songs of vendors claiming better tools.

I have spent most of the past 5 years traveling around the country talking to developers, and a constant question I hear is 'Why is Java programming so complex, especially when the Java langauge itself is clean and elegant?"

It doesn't have to be that way, and Bruce Tate and Justin Gehtland can show you how. Continuing the tradition that Bruce started with his "Bitter..." books, BFLJ skips right past the vendor hype to the techniques that are working for good Java developers around the country. I have read all of Tate and Gehtland's fine books, and for both of them this is the best to date.

Read this book now, and you'll be ahead of the curve in 2005 and 2006.

Better, Faster, Lighter starts by explaining the basic problem in J2EE, complexity and API bloat, and then builds around five principles that should guide Java application development. Each of these principles are enclosed in an individual chapter, and in the second half of the book, these principles are explained using open source frameworks and example code.

The most useful chapter for me was the chapter called "You Are What You Eat" as it explains alternatives to the standard J2EE architecture. It discusses all the major technologies that J2EE architects and developers care about - XML, Web Services, Session and Entity EJBs, Distribution etc, and gives scenarios under which it is suitable or unsuitable to choose each. This is the sort of information that is useful for persons who make architectural or design choices. The book also proposes two alternate deployments to the traditional 3-tiered architecture and gives reasons why these would lead to improved performance and lower complexity. This chapter explains how to make the technical decisions that will impact application development down the road.

This book gives an introduction to two of the most popular open source frameworks today - Spring and Hibernate, and argues that they have become successful as they focus on simplifying Java development. The chapters on Hibernate and Spring are relatively short at 22 and 25 pages respectively, and so should not be relied upon for a detailed exposition into these frameworks. Persons wanting to get up to speed with these technologies should buy Rod Johnson's Expert One on One J2EE Development without EJB, or Matt Raible's Spring Live, as well as the Hibernate in Action when these books are released. But the chapters fit nicely into the overall argument in favor of simple tools that help simplify development.

The Spring chapter explores the JPetstore sample application that uses IBatis as the persistence layer. Later on Bruce Tate discussed moving to Hibernate, and also supports the use of JDO.

Better, Faster, Lighter Java is a little different from the traditional Java/J2EE books, and is written in a conversational, rather than a technical style. Thus it's more useful for persons seeking the big picture surrounding Java development, rather for pure techies. Relatively few books focus on the why of application development, and I recommend this book as one of these. If you enjoy reading authors such as Rod Johnson, Martin Fowler, and Scott Ambler, then this book won't disappoint.

If I were looking for a Spring or Hibernate book, this one would let me down. But that's not what Gehtland and Tate are trying to do. They are showing why Spring and Hibernate are important, and how they have passed up enterprise java beans. They have shown basic rules for lightweight development, and they have done it effectively. The book is simple, well-written, and in conflict with established J2EE development. I get into the emphasis on JUnit.

I also like how Gehtland and Tate show me more than programming. They let me see how companies sell. They show me how a better process can work. I like extreme programming, but my manager doesn't. They give me some good ideas about how to use the best parts without doing all of XP.

I also like the idea of showing the principles, and then seeing how those principles apply to open source software, and then showing me how to put them into use. I don't think that the book would have been useful if they would have simply tried to invent some application that fit their model. Instead, they picked a couple of open source projects that seem to do what they are advocating.

Lighter Faster java is a home run. If you're looking for a Spring book, just go buy Expert J2EE One on One. If you want to understand why Spring, and other technologies like it, are important, get Lighter Faster Java. I can understand how to program Spring and Hibernate with tutorials on line. This book gives me something far more valuable. Insight.

I think I'm also going to pick up one for my boss.

Better, Faster, Lighter starts by explaining the basic problem in J2EE, complexity and API bloat, and then builds around five principles that should guide Java application development. Each of these principles are enclosed in an individual chapter, and in the second half of the book, these principles are explained using open source frameworks and example code.

The most useful chapter for me was the chapter called "You Are What You Eat" as it explains alternatives to the standard J2EE architecture. It discusses all the major technologies that J2EE architects and developers care about - XML, Web Services, Session and Entity EJBs, Distribution etc, and gives scenarios under which it is suitable or unsuitable to choose each. This is the sort of information that is useful for persons who make architectural or design choices. The book also proposes two alternate deployments to the traditional 3-tiered architecture and gives reasons why these would lead to improved performance and lower complexity. This chapter explains how to make the technical decisions that will impact application development down the road.

This book gives an introduction to two of the most popular open source frameworks today - Spring and Hibernate, and argues that they have become successful as they focus on simplifying Java development. The chapters on Hibernate and Spring are relatively short at 22 and 25 pages respectively, and so should not be relied upon for a detailed exposition into these frameworks. Persons wanting to get up to speed with these technologies should buy Rod Johnson's Expert One on One J2EE Development without EJB, or Matt Raible's Spring Live, as well as the Hibernate in Action when these books are released. But the chapters fit nicely into the overall argument in favor of simple tools that help simplify development.

The Spring chapter explores the JPetstore sample application that uses IBatis as the persistence layer. Later on Bruce Tate discussed moving to Hibernate, and also supports the use of JDO.

Better, Faster, Lighter Java is a little different from the traditional Java/J2EE books, and is written in a conversational, rather than a technical style. Thus it's more useful for persons seeking the big picture surrounding Java development, rather for pure techies. Relatively few books focus on the why of application development, and I recommend this book as one of these. If you enjoy reading authors such as Rod Johnson, Martin Fowler, and Scott Ambler, then this book won't disappoint.

Really disappointing.I read this book because of the fame of the author : Bruce A. Tate who is the author of Bitter Java & Bitter EJB,but I found nothing useful in this book. In Book Description
it says about hibernate and spring, but the chapter about hibernate is very short and provide nothing useful ,
and the chapter about spring is also disappointing,
it is not only short at information ,but the example showed
is using iBatis as persitence layer, which surprise me really
much, doesn't the book's interested in Hibernate? why do it
provide examples with iBatic.(besides, the example are really
useless).
So I found this book really disappointing, I don't recommend anybody to read it.