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 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international/local) (707) 829-0104 (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/beyondjava To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For information about books, conferences, Resource Centers, and the O'Reilly Network, see the O'Reilly web site at: http://www.oreilly.com Safari® Enabled When you see a Safari® Enabled icon on the cover of your favorite technology book, it means the book is available online through the O'Reilly Network Safari Bookshel f. Safari offers a solution that's better than e-books. It's a virtual library that lets you easily search thousands of top technology books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com. Acknowledgments This book challenged me more than any other book I've written. I felt that I needed to bolster my opinions with those of other respected programmers and consultants. I asked for many opinions, and published some of the responses. Thanks to Mike Clark, Matt Raible, Andrew Hunt, Ramnivas Laddad, Brett McLaughlin, and Eitan Suez for answering my questions. Thanks especially to Glenn Vanderburg, Ted Neward, Erik Hatcher, Justin Gehtland, James Duncan Davidson, Jim Weirich, Jamis Buck, David Heinemeier Hansson, Dion Almaer, Jason Hunter, Richard Monson-Haefel, Stuart Halloway, and Dennis Sosnoski for agreeing to let me post your interviews in the book. Thanks again to Justin Gehtland for use of your metrics, and being a partner through two writing projects. Special thanks go to David Heinemeier Hansson for access to your framework and community from the inside. When I needed reviewers, you used your influence to find them for me. When I had hard questions, you answered them. You also provide the irresistible force that is Ruby on Rails. I'm grateful. I hope this book marks only the beginning of a partnership, and a possible friendship. Dave Thomas, you have given me the courage and faith to explore things beyond Java. You've been a role model for me. Your consistent honor and class teach me; your skill with your keyboard and your voice inspire me; your business sense instructs me. Avi Bryant, thanks for your tireless work and promotion on the Seaside framework. Special thanks also go out to Michael Loukides. Supporting me is your job, but I also feel a special kinship. We've been through a lot together, and I aim for that relationship to continue. You've been very good for me and my writing career. I hope you've benefited in some small way, too. After letting my readers down by publishing Spring, A Developer's Notebook before it was ready, I feel the need to offer some thanks for helping me through the negative press. O'Reilly, you were great to stand behind me. I felt that I needed to have this book reviewed exhaustively, to prevent the same mistake from happening twice. Many answered the call. Ted Neward, Venkat Subramaniam, Michael Koziarski, Jeremy Kemper, Michael Loukides (who gave me advice and ideas far beyond the usual editorial support), and many others too numerous to list here provided good reviews. Invariably, some reviewers take on a book as a personal mission. Usually, a book is lucky to have one such reviewer. This time, I had four. Steve Yegge, Jason Hunter, David Rupp, and Curt Hibbs all went far beyond the call of duty. They provided help that was stylistic, philosophical, technical, and even structural. This book is radically different from my initial vision. Thanks to all who contributed. To Jay Zimmerman and all of those I've met at NoFluffJustStuff, this book is as much yours as it is mine. You've helped me shape and sharpen these ideas, and you've given me a platform to present them. Most of all, I've got to recognize the contributions of one special lady in my life. She propped me up when I was too low to write, she talked through many of the ideas, she sat through many boring dinners as I talked through this stuff with anyone who would listen. Her smile fills my soul with the passion that I need for writing, and gives me a reason to be. We share a common purpose in raising our daughters, Kayla and Julia, a common foundation of faith in Jesus Christ, an unending hospitality for weary colleagues on the road, and a sense of adventure in life. Without you, I'm nothing. With you, I feel like I matter, and my ideas matter. You're a bigger part of this book than you'll ever know. I love you always. 1.1. Ignorance as a Virtue In many ways, k ayaking is like programming. I've learned an incredible trick. I can be surprisingly productive by simply ignoring most problems. With a little luck, the problems often just go away. Such an attitude can work for you or against you. Many post office clerks and minimum-wage fast food employees have learned that the same technique actually works for their problems, also known as customers. These are ostriches. If you look closely, you can find some selective, wise application of ignorancethe owl's trademark. I actually find that most "problems" in programming are merely potential problems. If you've read any of my books, you know that I preach against the dangers of premature optimization, and echo the popular agile principle of YAGNI : "You ain't gonna need it." I usually ignore bloated frameworks that promise to save me time, trusting my instincts to simpler solutions. More to the point, I've found that Java does everything that I need, so I haven't looked beyond these borders for a very long time. Ignorance is bliss. I know some languages are more dynamic, and possibly more productive in spurts, but in the end, it seems like Java will always win. It's got tens of thousands of frameworks to do anything from running systems for nuclear reactors to programming an embedded controller on a power toenail clipper. Many of the best frameworks are even free. I can always find a Java developer to do what I need. I know that people have made it work to solve massive problems. And I know that my customers will feel safe and secure. In short, the community and breadth of Java have always trumped anything that the alternatives have to offer. So I quit looking. And I'm glad that I did, because it allowed me to focus on building a consulting business and satisfying my customers instead of doing exhausting research for every new problem. When a dominant language or technology is in its prime, there's a blissful ignorance stage, when ignoring alternatives works in your favor. Figure 1-1 shows what I mean. When a new language arrives with the power and dominance of a Java or C++, you can afford to ignore alternatives for a while. But if you don't accurately identify the end of the cycle, you can get steamrolled. Suddenly, your competition has the jump on you, with much better productivity leading to better quality, improved productivity, and more customers. When you enter the transition time, you'd better start paying attention. I admit unashamedly that I liked having my head in the sand. It was easy, and productive, and politically safe. I bet that many of you Java developers act like me. You may have your own reasons. Living in this shelter is certainly easierdoing nothing trumps extra work. You might feel saferno one ever got fired for choosing IBM. (OK, so maybe Component Broker on Figure 1-1. For a period of time, ignorance is productive, but the ending of that period can be unpredictable OS/2 was not such a good idea ) You may have an incredible investment in skills that you believe will not commute, and if you've invested poorly in your skill set, you may be right. You may be bound like a Siamese twin to Java by a long-term project or a group based on the language. Like my reasons, many of these are sound. 1.1.1. Shaken to the Core After living in blissful ignorance for five years or more, I had an experience that shook me to the core. I led a new start-up down a path that required what I'd consider three of the most productive lightweight frameworks out there for web development of persistence applications: Hibernate, Spring, and Web Work. I knew there were slightly more productive environments for this kind of thing, but they either would not scale (in terms of complexity or performance), or were not popular enough to justify the risk. My partner and I decided to implement a small part of the application in Ruby on Rails, a highly productive web-based programming framework. We did this not to satisfy our customer, but to satisfy a little intellectual curiosity. The results astounded us: For the rewrite, we programmed faster. Much faster. It took Justin, my lead programmer, four nights to build what it had taken four months to build in Java. We estimated that we were between 5 and 10 times more productive. We generated one-fourth the lines of code; one-fifth if you consider configuration files. The productivity gains held up after we moved beyond the rewrite. The Ruby on Rails version of the application performed faster. This is probably not true of all possible use cases, but for our application, the RoR active record persistence strategy trumped Hibernate's Object Relational Mapping (ORM) , at least with minimal tuning. The customer cared much more about productivity than being on a safe Java foundation. As you can well imagine, this shook my world view down to the foundation. I'm now frantically trying to catch up. It seems that conditions on the river changed without my noticing. I've got to start scouting again. . O'Reilly Media, Inc. 10 05 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0 515 (international/local) (707) 829- 010 4 (fax) There is. like I matter, and my ideas matter. You're a bigger part of this book than you'll ever know. I love you always. 1. 1. Ignorance as a Virtue In many ways, k ayaking is like. long-term project or a group based on the language. Like my reasons, many of these are sound. 1. 1 .1. Shaken to the Core After living in blissful ignorance for five years or more, I had an experience