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.

Rating:

Rating:

Rating:

Review of "Better, Faster, Lighter Java",  March 20 2006
Submitted by Val   [Respond | View]

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.

More reviews on Val's blog (http://radio.javaranch.com/val)


almost,  February 09 2005
Submitted by Anonymous Reader   [Respond | View]

that discourse, and this, alas, attempt to explain why the quote should be "are" not "want to be". and what the bedrock problem is. the book tip-toes around the problem, but doesn't quite explain why the emporer is naked.

so: in addition to the book, read a solid RDBMS theory book, Date comes to mind; and a solid applied RDBMS book, Elmasri/Navathe does come to mind. remember, when you're doing something that hasn't been done before, experience is a poor guide. you'll need theory to tell you what to do.

as i said: the problem with Enterprise java development is that it has been a regression in data thinking. there is *no* Object Model in the way that there is a Relational Model. the latter *guarantees* data integrity/concurrency independent of any code. the so-called Object Model does little more than what COBOL/VSAM did in 1975: define and manage data *only* by specific application code.

the corporate java systems i've seen (more than 1, less 1,000) are just re-writes of COBOL procs with java syntax. this is not progress.

Bob


almost,  October 29 2004
Submitted by Anonymous Reader   [Respond | View]

It's interesting to read your prolonged discourse but as a piece unto itself but how does all of this relate to the book at hand?


An important book,  October 05 2004
Submitted by Pinaki Poddar   [Respond | View]

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.



An important book,  October 05 2004
Submitted by Anonymous Reader   [Respond | View]

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,  September 06 2004
Submitted by simple coder   [Respond | View]

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.





almost,  June 29 2004
Submitted by Anonymous Reader   [Respond | View]

"Do you want to be the COBOL developer of the 21^st century?" page 9.

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.

See larger cover