Customer Reviews

Better, Faster, Lighter Java

5 star:		(17)
4 star:		(6)
3 star:		(1)
2 star:		(1)
1 star:		(6)

 

 

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.

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.

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.

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.

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

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

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.

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.

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

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.