October 30, 2005
I recently finished Bruce Tate's Beyond Java, a book every Java programmer should read. Especially those who havent worked much with other languages. I should say right now that I probably feel this way because it validates much of what I've been arguing from years, from the perspective of someone deep inside the Java world.
Recent comments here should make it clear that Java and I aren't exactly on speaking terms. It isn't so much the language as all the deadwood that's built up around it. A coworker and I recently spent a day reorganizing a legacy codebase so we could use Eclipse as an actual IDE instead of just a big, slow text editor. About half the day was spent figuring out the XDoclet used to build the app. And it dawned on me: we're using XDoclet to generate all this code that doesn't contribute meaningfully to the application, but rather is required scaffolding to maintain the EJB framework. Code generation has its point, but when you have to then maintain that code … ugh. I'm watching my team struggle to produce web apps in a timely fashion, held back not by the difficulty of business problems, but by the bulk and complexity of J2EE programming. We spend more time in care and feeding of the framework than we do writing application code. That just doesn't seem right.
Bruce Tate makes a convincing argument that Java is at a point where it can either rally its forces and continue on with renewed vigor, or be overtaken by a new contender(s) with programming models that support more rapid development and match business and programming needs more closely. He doesn't seem all that hopeful for Java.
Tate is almost reluctant in this. Java has been good to him. A best-selling author with a successful consultancy, he is very much at home in the Java world. So to give Java its fair due, he walks us through its history, identifying the roots of its early success: wooing C and C++ programmers to a better programming experience. But now, he argues, Java is moving away from its base, expanding in strange and poorly planned directions (e.g. generics -- perhaps useful, but poorly implemented), growing an ever-larger stack of technologies necessary to even function as a Java programmer. Java is effective for system or middleware programming, but failing as a language for writing applications. Other languages -- Python, Ruby -- are gaining popularity because they let programmers do their jobs faster, better, writing less code to do more.
He points out what still surprises many programmers: while we discover that dynamic typing is quite effective and not that dangerous, the changes made to Java only reinforce static typing (e.g. generics). I, for one, am tired of spending my time worrying about such details that do not demonstrably contribute to the effectiveness, correctness, or functionality of my apps. Static typing ain't it.
To supplement his own arguments, Tate includes interviews with Java luminaries who are moving away from the platform or who at least take serious issue with some of the sacred cows of the Java world. I was particularly tickled by the inclusion of James Duncan Davidson, who brought us both Tomcat and Ant — and no longer works with Java. Steve Yegge's explanation of how he took months off from development to figure out what was slowing him down, to discover that it was Java itself.
(Elsewhere, David Geary of JSF fame identifes several Java "connectors and mavens" who have adopted Rails. Worth noting by those who would dismiss the hype.)
The concluding chapters explore what Tate thinks might characterize languages that steal Java's thunder, paying close attention to Ruby, Ruby on Rails, and continuation servers like Seaside (which I'd never heard of but which intrigue me). He dismisses Perl and PHP for what I agree to be mostly valid reasons, though I think he's a bit harsh on PHP and has misconceptions about best practices in PHP programming models.
I devoured this book and immediately reread it. I am serious: if you are a Java programmer, you should read it. Obviously Java will not disappear from the landscape anytime soon, but I believe that it's important to understand its limitations and frustrations, and why other languages are starting to eat away at its foundation. Otherwise you're likely to end up like one of the cranky COBOL programmers, wondering what all the fuss is about this upstart 10-year-old. :)
