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.

Bruce Tate

Bruce Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin,Texas. In 2001, he founded J2Life, LLC, a consulting firm that specializes in Java persistence frameworks and lightweight development methods. His customers have included FedEx, Great West Life, TheServerSide, and BEA. He speaks at conferences and Java user's groups around the nation. Before striking out on his own, Bruce spent thirteen years at IBM working on database technologies, object-oriented infrastructure and Java. He was recruited away from IBM to help start the client services practice in an Austin start up called Pervado Systems. He later served a brief stent as CTO of IronGrid, which built nimble Java performance tools. Bruce is the author of four books, including best-selling Bitter Java.First rule of kayak: When in doubt, paddle like Hell

Justin Gehtland

Working as a professional programmer, instructor, speaker and pundit since 1992, Justin Gehtland has developed real-world applications using VB, COM, .NET, Java, Perl and a slew of obscure technologies since relegated to the trashheap of technical history. His focus has historically been on "connected" applications, which of course has led him down the COM+, ASP/ASP.NET and JSP roads.Justin is the co-author of Effective Visual Basic (Addison Wesley, 2001) and Windows Forms Programming in Visual Basic .NET (Addison Wesley, 2003). He is currently the regular Agility columnist on The Server Side .NET, and worksas a consultant through his company Relevance, LLC in addition to teaching for DevelopMentor.

Our look is the result of reader comments, our own experimentation, and feedback from distribution channels. Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects. The animal on the cover of Better, Faster, Lighter Java is a hummingbird. There are over 300 hummingbird species, all found only in the New World. All these species are easily identifiable by their long, tubular bills and iridescent feathers. The iridescence is a refraction effect that can be seen only when light is shining on the feathers at certain angles. Hummingbirds range in size from the bee hummingbird, which, measuring 2 inches long and weighing less than an ounce, is the smallest of all birds, to the great hummingbird, which measures about 8.5 inches long.Hummingbirds are so named because of the humming noise made by their rapidly moving wings. On average, hummingbirds flap their wings 50 times a second; some species can flap as many as 200 times per second. The wings are flexible at the shoulder and, unlike most birds, they are propelled on the upstroke as well as the downstroke. Because of this flexibility, hummingbirds can hover, fly right or left, backward, and upside down. Most hummingbirds have tiny feet that are used only for perching, never for walking. Hummingbirds will fly to travel even a few inches.Hummingbirds expend a great deal of energy, and they need to feed every 10 minutes or so. They feed on nectar, for sugar, and small insects, for protein. Their long, tapered bills enable them to retrieve nectar from even the deepest flower. Pollen accumulates on the head and neck of hummingbirds while they gather nectar. They then transfer this pollen to other flowers and thus play an important role in plant reproduction.Hummingbirds appear frequently in Native American legends and mythology, often as representatives of the sun. According to some folk beliefs, they can bring love. Since Europeans first spotted these beautiful, colorful little birds, they have often appeared in the art and literature of the Old World, as well. Colleen Gorman was the production editor and the copyeditor for Better, Faster, Lighter Java. Jane Ellin was the proofreader. Matt Hutchinson and Mary Anne Weeks Mayo provided quality control. Johnna VanHoose Dinse wrote the index.Ellie Volckhausen designed the cover of this book, based on a series design by Edie Freedman. The cover image is a 19th-century engraving from the Dover Pictorial Archive. Emma Colby produced the cover layout with QuarkXPress 4.1 using Adobe's ITC Garamond font.Melanie Wang designed the interior layout, based on a series design by David Futato. This book was converted by Julie Hawks to FrameMaker 5.5.6 with a format conversion tool created by Erik Ray, Jason McIntosh, Neil Walls, and Mike Sierra that uses Perl and XML technologies. The text font is Linotype Birka; the heading font is Adobe Myriad Condensed; and the code font is LucasFont's TheSans Mono Condensed. The illustrations that appear in the book were produced by Robert Romano and Jessamyn Read using Macromedia FreeHand 9 and Adobe Photoshop 6. The tip and warning icons were drawn by Christopher Bing. This colophon was written by Clairemarie Fisher O'Leary.

Next year, Java will finally get a second digit in its age. Over the past 10 years, Java has become one of the most popular language on earth. Popularity is usually a positive sign but it often hides a double-edged sword as an ever increasing indigestible amalgam of (*cough* reusable *cough*) Java libraries/frameworks flood developers everyday. No one will argue that it becomes more and more difficult to make the right decisions when it comes to choosing existing libraries/frameworks for developing new products and/or refactoring older ones.

Don't worry, you are not alone. Bruce Tate and Justin Gehtland have made a tremendous effort of vulgarizing some fundamental principles that, when applied consistently, can considerably ease your life. They introduce the following basic principles: "Keep it simple", "Do one thing and do it well", "Strive for transparency", "You are what you eat" and "Allow for extension". They also show how two famous open-source frameworks, Spring and Hibernate, elegantly apply these five principles. Finally, they take their own "better-faster-lighter-java" medication by applying it on the Simple Spider project and show how the latter can easily be integrated into the infamous jPetStore application.

I definitely enjoyed reading this book even though it is not necessarily about pure coding. However, I would like to warn entry-level programmers as they might not enjoy the occasional philosophical tone. As well, they might not have had the chance to be frustrated yet which is THE assumption the authors make.

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.

Coding simple is a joke. Lack of standards brings lots of ways of doing the same thing. For example, database persistence. We have JDBC, JDO, Sql Maps, Hibernate, J2EE CMP and what not. Every solution is depend on the manpower, cost and time it requires to do it. We do not have to be acrid about one way or another. A good architect will select what is cost affective and right at that time.

Data centric application may not use JDO or hibernate but simple RAD applications will benefit from JDO/hibernate.

It is sad that after RDBMS there has been no advances in persistence. OODBMS came up but was not well-received by users for obvious reasons. For now a symbiotic relationship between database and application code is a must.

well you are, and it happened rather a while ago. the book goes about, oh, 2/3 of the way toward showing a fix for the problem. but msrs. Tate & Gehtland are not true database wonks (you can see it in how they talk about databases), and that remains the problem with java; especially the Enterprise variety. enterprise development without a deep understanding of data modeling is a travesty. java started as a client (applet) approach to language; we're still paying dearly for this 'small' view. as the authors point out, EJB isn't the answer. some of the answer is in the text; much of it lies in the world of relational database modeling.

put simply, java folk view data the way COBOL did before Dr. Codd and his 12 kids showed them the way to Application Independent Data Storage (tm). java folk think that their application is the only way into the data. the relational database is designed to support arbitrary access; treating it like a bunch of VSAM files (which is what 99.44% of java developers do; 'we don't need no stinkin foreign keys') is tres retrograde. this is why java will lose. it's data model is 35 years old.

even, perish the thought, should the java twinks get their way, users lose; their data is no longer open, but tied up in 0 NF databases and (God punish them severely) XML. tagged text files aren't 35 years old; their 40 years old.

the relational database is really what OO claims: data and its control in one place. java folk go around writing pages of stuff, when the proper solution is a 3 NF database with check constraints (and possibly other stuff, but still in the database WITH THE DATA).

remember the mantra: the DATA is the application, not the code. the best we can hope is that the coders don't screw up the data beyond repair.