Better, Faster, Lighter Java (Paperback)

~ (Author), Justin Gehtland (Author)
Key Phrases: adding persistence, byte code enhancement, business domain model, Simple Spider, Pet Store, Inventor's Paradox (more...)

Editorial Reviews

Product Description

Sometimes the simplest answer is the best. Many Enterprise Java developers, accustomed to dealing with Java's spiraling complexity, have fallen into the habit of choosing overly complicated solutions to problems when simpler options are available. Building server applications with "heavyweight" Java-based architectures, such as WebLogic, JBoss, and WebSphere, can be costly and cumbersome. When you've reached the point where you spend more time writing code to support your chosen framework than to solve your actual problems, it's time to think in terms of simplicity.

In Better, Faster, Lighter Java authors Bruce Tate and Justin Gehtland argue that the old heavyweight architectures are unwieldy, complicated, and contribute to slow and buggy application code. As an alternative means for building better applications, the authors present two "lightweight" open source architectures: Hibernate--a persistence framework that does its job with a minimal API and gets out of the way, and Spring--a container that's not invasive, heavy or complicated.

Hibernate and Spring are designed to be fairly simple to learn and use, and place reasonable demands on system resources. Better, Faster, Lighter Java shows you how they can help you create enterprise applications that are easier to maintain, write, and debug, and are ultimately much faster.

Written for intermediate to advanced Java developers, Better, Faster, Lighter Java, offers fresh ideas--often unorthodox--to help you rethink the way you work, and techniques and principles you'll use to build simpler applications. You'll learn to spend more time on what's important. When you're finished with this book, you'll find that your Java is better, faster, and lighter than ever before.

About the Author

Bruce Tate is an Internet architect who developed the bitter Java concept after seeing a set of customer problems repeated, collecting their stories, and publishing the solutions. He is the author of "Bitter Java," He lives in Austin, Texas. Mike Clark is president of Clarkware Consulting, Inc. He first encountered EJB pitfalls in 1998 while developing a custom EJB container, prior to the emergence of commercial J2EE servers. He has significantly contributed to the successful delivery of a popular J2EE performance management product and has also created several open source tools including JUnitPerf for automated performance testing. He lives in Parker, Colorado. Bob Lee is an OCI consultant with expertise in AOP, Jini, and web security. He developed an open source AOP framework that utilizes runtime bytecode engineering to intercept method invocations on POJOs and forms the foundation of JBoss AOP. He lives in St. Louis, Missouri. Patrick Linskey is the vice president of engineering for SolarMetric, a company that offers Java persistence alternatives to the Java community. His experience spans EJB application development and product development, and he is a teacher and speaker on the Java conference circuit. He lives in Washington, D.C.

Product Details

• Paperback: 243 pages
• Publisher: O'Reilly Media; 1 edition (May 28, 2004)
• Language: English
• ISBN-10: 0596006764
• ISBN-13: 978-0596006761
• Product Dimensions: 9.2 x 7.1 x 0.8 inches
• Shipping Weight: 15.8 ounces (View shipping rates and policies)
• Average Customer Review: 3.9 out of 5 stars  See all reviews (31 customer reviews)
• Amazon.com Sales Rank: #552,250 in Books (See Bestsellers in Books)

  Popular in these categories: (What's this?)

  #22 in	Books > Computers & Internet > Databases > Java & Databases
  #25 in	Books > Computers & Internet > Programming > Languages & Tools > Cobol

Customer Reviews

Most Helpful Customer Reviews

20 of 21 people found the following review helpful:

5.0 out of 5 stars Simple, and elegant, June 13, 2004

By A Customer

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.

30 of 35 people found the following review helpful:

1.0 out of 5 stars Not worth buying. Simple manifesto., October 15, 2004

By	Sam Wilson (Philadelphia, PA USA) - See all my reviews (REAL NAME)

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.

14 of 16 people found the following review helpful:

4.0 out of 5 stars Mixed Feelings, June 2, 2005

By	Larry (Somerville, MA) - See all my reviews

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.