Preface

In 2004, Erik Hatcher traveled from a very wet Virginia to a usually dry Austin and got lucky. Barton Creek was up. Together, we braved the cold and windy conditions, and had one of the best kayaking days of our lives. In 2000, three friends and I drove east in March to run the Little River through the Great Smokey Mountains. As we put in, two inches of snow frosted the landscape, and flakes lightly dusted our boats on another memorable, incredible day, ripping through rapids like the Sinks (I walked around it) and the Elbow (I ran it, and didn't sleep for a week afterwards). The cold weather that starts a new paddling season adds an indescribable kind of energy to a run. There's just something magical about the thawthe springtime.

In the Java community, we're encountering a Spring of a different kind. This one follows the great freeze of Enterprise JavaBeans 2.x (EJB). Tens of thousands of applications lay in frigid, near-death conditions in this well-intentioned, massive block of ice. EJB can suck the life right out of a developer if you're not careful, and sometimes, even if you are:

• Though developers use automated testing as a cornerstone practice, you can't test EJB applications well at all. The container is too big to start in a test case, and objects can't live outside of the container.

• EJB is incredibly intrusive. True, it's designed to shield your business objects from the details of transactions, persistence, security, remoting and messaging. It just does a terrible job. Your application becomes a slave to the EJB way.

• EJB forces unnatural design decisions. EJB applications must use dumbed-down value objects instead of rich domain objects. Like the Pied Piper, EJB capabilities like remoting entice developers to distribute applications in unsound ways. Limitations of EJB persistence force suboptimal designs, because they don't support critical concepts like inheritance.

And so, after years of plodding through monolithic EJB architectures and design patterns that are nothing more than workarounds for obvious problems, the whole enterprise Java community is ready for the Spring thaw. Rather than the large dominant vendors, a new breed of lightweight development processes and open source frameworks is supplying the heat.

Still, many developers resist change. To them, EJB is worth the pain, because of the value of declarative services like transactions and remoting. Breaking these ideas out of mainline business logic makes applications simpler, cleaner, and easier to maintain. But if declarative services are so important, why stop with just the declarative services provided by the container? Why not make a general model that makes it easy to attach services to any POJO?

In the end, I don't kayak and code for the same reasons. I kayak to have fun. I code to make money, and to get stuff done. If there's a good way to provide persistence (such as Hibernate or JDO) or transactions (such as JTA or JDBC), I should be able to tell the computer to make some thing transactional, or persistent, or remote, or secure.

In Spring, you can make an object secure, remote, or transactional with a couple of lines of XML. The resulting application is simple and clean. In Spring, you can work less and go home, because you can strip away a whole lot of the redundant code that you tend to see in most J2EE applications. You won't be nearly as burdened with meaningless detail. In Spring, you can often change your mind without the consequences bleeding through your entire application. You'll adapt much more quickly than you ever could before.

That's why I'm ready for the thaw.