Better, Faster, Lighter Java

Preface

In 2001, I was with Steve Daniel, a respected kayaker. We were at Bull Creek after torrential rains, staring at the rapid that we later named Bores. The left side of the rapid had water, but we wanted no part of it. We were here to run the V, a violent six-foot drop with undercut ledges on the right, a potential keeper hydraulic on the left, and a boiling tower of foam seven feet high in the middle. I didn’t see a clean route. Steve favored staying right and cranking hard to the left after the drop to avoid the undercut ledge. I was leaning left, where I’d have a tricky setup, and where it would be tough to identify my line, but I felt that I could find it and jump over the hydraulic after making a dicey move at the top. We both dismissed the line in the middle. Neither of us thought we could keep our boats upright after running the drop and hitting the tower, which we called a haystack because of its shape. Neither of us was happy with our intended line, so we stood there and stared.

Then a funny thing happened. A little boy, maybe 11 years old, came over with a $10 inflatable raft. He shoved it into the main current, and without paddle, life jacket, helmet, or any skill whatsoever, he jumped right in. He showed absolutely no fear. The stream predictably took him where most of the water was going, right into the “tower of power.” The horizontal force of the water shot him through before the tower could budge him an inch. We both laughed hysterically. He should have been dead, but he made it—using an approach that more experienced kayakers would never have considered. We had our line.

In 2004, I went with 60 kids to Mexico to build houses for the poor. I’d done light construction of this kind before, and we’d always used portable cement mixers to do the foundation work. This group preferred another method. They’d pour all of the ingredients on the ground—cement, gravel, and sand. We’d mix up the piles with shovels, shape it like a volcano, and then pour water in the middle. The water would soak in, and we’d stir it up some more, and then shovel the fresh cement where we wanted it. The work was utterly exhausting. I later told the project director that he needed cement mixers; they would have saved a lot of backbreaking effort.

He asked me how to maintain the mixers. I didn’t know. He asked where he might store them. I couldn’t tell him. He then asked how he might transport them to the sites, because most groups tended to bring vans and not pickup trucks. I finally got the picture. He didn’t use cement mixers because they were not the right tool for the job for remote sites in Mexico. They might save a half a day of construction effort, but they added just as much or more work to spare us that effort. The tradeoff, once fully understood, not only failed on a pure cost basis, but wouldn’t work at all given the available resources.

In 2003, I worked with an IT department to simplify their design. They used a multilayered EJB architecture because they believed that it would give them better scalability and protect their database integrity through sophisticated transactions. After much deliberation, we went from five logical tiers to two, completely removed the EJB session and entity beans, and deployed on Tomcat rather than Web Logic or JBoss. The new architecture was simpler, faster, and much more reliable.

It never ceases to amaze me how often the simplest answer turns out to be the best one. If you’re like the average J2EE developer, you probably think you could use a little dose of simplicity about now. Java complexity is growing far beyond our capability to comprehend. XML is becoming much more sophisticated, and being pressed into service where simple parsed text would easily suffice. The EJB architecture is everywhere, whether it’s warranted or not. Web services have grown from a simple idea and three major APIs to a mass of complex, overdone standards. I fear that they may also be forced into the mainstream. I call this tendency “the bloat.”

Further, so many of us are trained to look for solutions that match our predetermined complicated notions that we don’t recognize simple solutions unless they hit us in the face. As we stare down into the creek at the simple database problem, it becomes a blob of EJB. The interfaces become web services. This transformation happens to different developers at different times, but most enterprise developers eventually succumb. The solutions you see match the techniques you’ve learned, even if they’re inappropriate; you’ve been trained to look beyond the simple solutions that are staring you in the face.

Java is in a dangerous place right now, because the real drivers, big vendors like Sun, BEA, Oracle, and IBM, are all motivated to build layer upon layer of sophisticated abstractions, to keep raising the bar and stay one step ahead of the competition. It’s not enough to sell a plain servlet container anymore. Tomcat is already filling that niche. Many fear that JBoss will fill a similar role as a J2EE application server killer. So, the big boys innovate and build more complex, feature-rich servers. That’s good—if the servers also deliver value that we, the customers, can leverage.

More and more, though, customers can’t keep up. The new stuff is too hard. It forces us to know too much. A typical J2EE developer has to understand relational databases, the Java programming languages, EJB abstractions, JNDI for services, JTA for transactions, JCA and data sources for connection management, XML for data representation, Struts for abstracting user interface MVC designs, and so on. Then, she’s got to learn a whole set of design patterns to work around holes in the J2EE specification. To make things worse, she needs to keep an eye on the future and at least keep tabs on emerging technologies like Java Server Faces and web services that could explode at any moment.

To top it off, it appears that we are approaching an event horizon of sorts, where programmers are going to spend more time writing code to support their chosen frameworks than to solve their actual problems. It’s just like with the cement mixers in Mexico: is it worth it to save yourself from spending time writing database transactions if you have to spend 50% of your time writing code supporting CMP?

Development processes as we know them are also growing out of control. No human with a traditional application budget can concentrate on delivering beautiful object interaction diagrams, class diagrams, and sophisticated use cases and still have enough time to create working code. We spend as much or more time on a project on artifacts that will never affect the program’s performance, reliability, or stability. As requirements inevitably change due to increasing competitive pressures, these artifacts must also change, and we find that rather than aiding us, these artifacts turn into a ball, tied to a rope, with the other end forming an ever-tightening noose around our necks. There’s a better way.

A few independent developers are trying to rethink enterprise development, and building tools that are more appropriate for the job. Gavin King, creator of Hibernate, is building a persistence framework that does its job with a minimal API and gets out of the way. Rod Johnson, creator of Spring, is building a container that’s not invasive or heavy or complicated. They are not attempting to build on the increasingly precarious J2EE stack. They’re digging through the muck to find a more solid foundation. In short, I’m not trying to start a revolution. It’s already started.

That’s the subject of this book. I recommend that we re-imagine what J2EE could and should be, and move back down to a base where we can apply real understanding and basic principles to build simpler applications. If you’re staring at the rapids, looking at solutions you’ve been taught will work—but you still don’t quite see how to get from point A to point B without real pain—it’s time to rethink what you’re doing. It’s time to get beyond the orthodox approaches to software development and focus on making complex tasks simple. If you embrace the fundamental philosophies in this book, you’ll spend more time on what’s important. You’ll build simpler solutions. When you’re done, you’ll find that your Java is better, faster, and lighter.

Who Should Read This Book?

This book isn’t for uber-programmers who already have all the answers. If you think that J2EE does everything that you need it to do and you can make it sing, this book is not for you. Believe me, there are already enough books out there for you.

If you’ve already cracked the code for simplicity and flexibility, I’m probably not going to teach you too much that’s new. The frameworks I hold up as examples have been around for years—although incredibly, people are only now starting to write about them. The techniques I show will probably seem like common sense to you. I’ll take your money, but you’ll probably be left wanting when you’re done.

This book is for the frustrated masses. It’s intended for those intermediate-to-advanced developers with some real experience with Java who are looking for answers to the spiraling complexity. I’ll introduce you to some ideas with power and bite. I know that you won’t read a phone book. You haven’t got time, so I’ll keep it short. I’ll try to show you techniques with real examples that will help you do things better than you did before.

Organization of This Book

This book consists of 11 chapters and a Bibliography:

Chapter 1, The Inevitable Bloat

This chapter highlights the problems inherent in the large-scale enterprise Java frameworks that most programmers work with today. I will cover not only what’s wrong with these bloated frameworks, but how they got that way. Finally, I will lay out the core principles we’ll cover in the rest of the book.

Chapter 2, Keep It Simple

Many programmers fall into the same trap, believing that the more complicated their code, the better it must be. In fact, simplicity is the hallmark of a well-written application. This chapter defines the principle of simplicity, while drawing a distinction between simple and simplistic. I will also examine the tools and processes that help you achieve simplicity, like JUnit, Ant, and Agile development.

Chapter 3, Do One Thing, and Do It Well

Programmers need to resist the urge to solve huge problems all at once. Code that tries to do too much is often too entangled to be readable, much less maintainable. This chapter traces the path from being presented with a problem, to truly understanding the problem and its requirements, to finally solving the problem through multiple, simple, and targeted layers. It finally describes how to design your layers to avoid unnecessary coupling.

Chapter 4, Strive for Transparency

The programming community has tried for years to solve the problem of cross-cutting concerns. Generic services, like logging or database persistence, are necessary for most applications but have little to do with the actual problem domain. This chapter examines the methods for providing these kinds of services without unnecessarily affecting the code that solves your business problem—that is, how to solve them transparently. The two main methods we examine are reflection and code generation.

Chapter 5, You Are What You Eat

Every choice of technology or vendor you make is an embodiment of risk. When you choose to use Java, or log4j, or JBoss, or Struts, you are hitching yourself to their wagon. This chapter examines some of the reasons we choose certain technologies for our projects, some traditional choices that the marketplace has made (and why they may have been poor choices), and some strategies for making the right decisions for your project.

Chapter 6, Allow for Extension

You simply can not know every use to which your application will be put when you write it. Any application that is worth the effort put into it will have a life outside the imagination of its authors. Your application needs to allow for extension after its release to the world. This chapter examines the techniques for providing extension points, from interfaces and inheritance to configuration and the plug-in model.

Chapter 7, Hibernate

Hibernate is an open source persistence framework that provides transparent object-to-relational mapping. It is a straightforward and simple implementation that focuses on the job of persisting your domain objects so that they can in turn focus on solving the business problems at hand.

Chapter 8, Spring

Spring is an open source application service provider framework on which to deploy enterprise applications. It has a simple, lightweight container for your objects, and provides access to a variety of core J2EE services. However, it does so without all the heavy requirements of standard J2EE frameworks, and with no intrusion into the design of your domain objects.

Chapter 9, Simple Spider

Building on the principles this book espouses, this chapter examines the construction of a sample application, the Simple Spider. This application provides indexing and search capabilities for a web site by crawling its pages, indexing them with Lucene, and providing multiple interfaces for searching the results.

Chapter 10, Extending jPetStore

Having built the Simple Spider, we now examine how easy it is to extend an application (the jPetstore sample from Chapter 8) if you follow the principles in this book. We replace the existing jPetstore search feature with the Simple Spider, then replace the persistence layer with Hibernate.

Chapter 11, Where Do We Go from Here?

Finally, this chapter looks ahead to what is coming on the horizon, new trends and technologies that are here or just around the corner, and how the ideas in this book are part of a changing landscape in enterprise Java development.

Bibliography

Contains a listing of resources and references.

Conventions Used in This Book

This book is by two authors, but with one voice. The stories come from the real-life experiences of Bruce and Justin. In everywhere but this paragraph, we’ve combined our voices, so that we don’t confuse you. Don’t worry. We both agree about everything that you see here.

The following typographical conventions are used in this book:

Italic

Used for filenames, directories, emphasis, and first use of a technical term.

Constant width

Used in code examples and for class names, method names, and objects.

Constant width italic

Indicates an item that should be replaced with an actual value in your program.

Constant width bold

Used for user input in text and in examples showing both input and output. Also used for emphasis in code, and in order to indicate a block of text included in an annotated call-out.

Comments and Questions

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

[phone] (in the United States or Canada)

[phone] (international/local)

[phone] (fax)

There is a web page for this book, which lists errata, examples, or any additional information. You can access this page at:

http://www.oreilly.com/catalog/bfljava/

To comment or ask technical questions about this book, send email to:

[e-mail]

For information about books, conferences, Resource Centers, and the O’Reilly Network, see the O’Reilly web site at:

http://www.oreilly.com

Acknowledgments

This book has been a real pleasure to write and I hope that translates to something that’s a joy for you to read. The names on the cover are necessarily only a small part of the total team effort that it took to produce this book. It would be impossible to thank every person that contributed, but I feel the obligation to try.

Both Bruce and Justin would like to thank Michael Loukides for his gentle encouragement, expert touch, and steady hand. At times, it may have seemed like this book would write itself, but don’t underestimate your impact on it. Thanks for giving us the freedom to do something unique, and the gentle guidance and leadership when the book required it. We also greatly appreciate our outstanding technical reviewers, including Stuart Holloway, Andy Hunt, Dave Thomas, and Glenn Vanderburg. We respect each of you deeply. It’s truly an honor to have such a combined brain-trust review our book. Special thanks go to Rod Johnson for his quick response and thorough attention while editing the Spring chapter. I’m astounded by what he’s accomplished.

Many heartfelt thanks also go to the production and marketing teams at O’Reilly, including David Chu for doing whatever it takes to speed the project along, Robert Romano for his work on the graphics, Daniel H. Steinberg for keeping us in front of his community, Colleen Gorman for her experienced, delicate editing, and Kyle Hart for her tireless promotion.

This book is about lighter, faster technologies and it relies heavily on the opinions and work of some pioneers. Thanks to the folks at IntelliJ, for use of a fantastic IDE. We used it to create many of the examples in this book. Thanks to Ted Neward, for his help in understanding JSR 175, and for his unique perspective. Ted, you scare me, only in a good way (sometimes). For his work on Spring, we thank again Rod Johnson. Thanks also to those who contributed to the open source JPetstore examples, including Clinton Began for his original JPetstore, which formed the foundation for Spring’s version, and Juergen Hoeller’s work to port that example to Spring. Gavin King and crew we thank for a fantastic persistence framework. Your remarkable accomplishments are rewriting Java history in the area of transparent persistence. We also would like to thank Doug Cutting and the entire Lucene maintenance team for their work on that excellent product. Dave Thomas and Mike Clark are Java leaders in the areas of test-driven development and decoupled designs. Thanks to both for providing credible examples for this book.

Bruce A. Tate

I would like to personally thank Jay Zimmerman for giving me a soap box for this critical message. As a mentor, you’ve taught me how to run a small business, you’ve trusted me with your customers, and you’ve been a jovial friend on the road. Thanks go to Maciej for helping to get the ball rolling and for help outlining this book. Thanks also go to Mike Clark for your ideas on unit testing, and your friendship. Most importantly, I thank my family. You are all the reason that I write. Thanks to Kayla and Julia for your smiles, kisses, and hugs when I am down; to my greatest love Maggie, for your inspiration and understanding; and most of all Connie, for 32 years of loving those who have been the closest to me. Connie, this book is for you.

Justin Gehtland

I would like to personally thank Stuart Halloway for being preternaturally busy all the time. I’d also like to say thanks to Ted Neward, Kevin Jones, and Erik Hatcher for forming a gravitational well pulling me towards Java. Mostly, I’d like to thank my wife Lisa and daughter Zoe, who prove to me constantly that work isn’t everything. Someday, perhaps, I’ll write a book you’d both like to read.