Beyond Java

Preface

In March of 2005, I was shocked and honored to get the word that one of my books, Better, Faster, Lighter Java (O’Reilly), won a Jolt award for technical excellence. I talked about how Java? developers could buck standing conventions to build better applications, faster than before. That book will always have a special place in my heart. Yet, throughout the process, something was in the way, and I couldn’t quite put my finger on it.

Around this time, one of my customers was building an application consisting of a complex database schema with a web-based user interface. We’d been using Spring and Hibernate with Web Work, a common stack for lightweight Java development, and we’d been generally pleased. Some things bugged us, though: the amount of repetition, the proliferation of XML configuration, and the pace of our changes. On a whim, we tried Ruby on Rails, a surprisingly productive and innovative framework that’s sweeping quickly through non-Java communities, and is making some noise among Java architects, too. We were shocked with our productivity, and we moved the project to the new foundation.

Something clicked into place for me. For this kind of application, Java itself was in the way. Remove it from the equation, and I could reduce the amount of code by a factor of four, drive the XML down to one-tenth of what it was, and achieve stunning productivity, with good performance. Better still, the concepts in Better, Faster, Lighter Java still applied. For other projects, if I needed the community and tools that Java offered, I could use it instead. If I didn’t need Java, I could take the principles in BFLJ to the extreme. A dam inside me broke, and this new book started pouring out. I had a message.

Months later, I found an audience, thousands of miles and 19 hours from home. I fidgeted nervously before the Java User’s Group. I’d certainly addressed larger groups, but this trip was different. In this case, the Norwegian Java User’s Group had paid my travel expenses to Oslo, not to sing the praises of Spring, or Hibernate, or agile development, but to call their baby ugly. It was hard for me. After writing the bestsellers, getting the Jolt, and building a thriving consulting practice in a down economy, I wanted the Java train to roll on, unstoppable, always building on an ever-strengthening foundation. I wanted Java to send my productivity through the roof, and for the impressive community and brain power to solve all the tough problems that Java faces today, but nothing lasts forever.

In the talk, I didn’t pick an eventual winner. I laid out the reasons for Java’s success, and then talked through its most serious problems. I showed some alternative languages and frameworks, as I saw them. Throughout the talk, I pointed out that conditions are ripe for an alternative to emerge. As I addressed the hospitable group, I answered questions and read faces. A few looked hostile, or hurt. Most others showed understanding, and a little fear. They understood my central thrust. For many of the most common problems that we solve with Java, some other frameworks in other languages can already do a better job. In some cases, the productivity discrepancy is wide enough to merit a serious look.

The talk, and the questions, went on way too long, but nobody left. They were surprisingly receptive. After the presentation, we went out to see some of Oslo. One of the hostile attendees cornered me for most of the night. The hard questions just wouldn’t quit coming:

• Why can’t we improve Java to cover the shortcomings?

• Do the other frameworks and languages that you presented have enough commercial backing?

• What about distributed transactions, or web services, or XML support?

• How can you find programmers, or train the ones you find?

These questions are real, and they show the tremendous barriers of entry against emerging languages. My questioner was a gentleman, but he could not completely hide his agitation or his deep-seated belief that the hurdles for the next successful language are incredibly high, and that we’ll still be coding in Java for the foreseeable future. He could well be right. But I’ve come to recognize some real limitations in the Java language, and many of the frameworks that power it. For certain problems, Java just isn’t productive enough for me anymore. I’ve experienced success with some alternatives. Though a language can last half a century to support legacy applications, I know no language can keep its leadership and its luster forever. Java’s reign will end. It’s not a question of if, but when.

Who Should Read This Book?

When C++ faded into relative obscurity, many of my best friends got burned, badly. They didn’t recognize that change was in the air, or how violently change could come. Though I have a whole lot to lose, I’m writing this book because I don’t want to see it happen again. If you don’t want to be caught by surprise, you need to read this book.

If you think I’m right, you can start to build your skills accordingly. You might download some of the frameworks I discuss, and learn a few new languages. This book will teach you what a new language needs to succeed. If I’ve gotten lucky and found one of the likely winners, you’ll be just a little bit more prepared when things do change.

If you think I am wrong, you can use the best techniques from the best frameworks written in any language to improve what you’re doing in Java today. New frameworks like PHP, C Omega for .NET, and Ruby on Rails will come occasionally. You need to know about them, and understand how to evaluate them.

Either way, you win. It’s time to start paying attention again. It’s time to look to the horizon, beyond Java.

Conventions

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.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact O’Reilly for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Beyond Java by Bruce A. Tate. Copyright 2005 O’Reilly Media, Inc., 0-596-10094-9.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

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/beyondjava

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

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 Bookshelf.

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.