A couple of days ago, MIT's Philip Greenspun stirred up a lot of sediment with his weblog post, Java is the SUV of programming tools. I waited for the slashdot effect to die down before talking about this particular piece of programming politics, because Greenspun got walloped (at last count, there were 136 comments on the posting).

I am, as a non-professional who writes code when God sees fit to allow time for it, a programming pragmatist. While I like Java for some tasks, I do most of my web programming in PHP, thank you–at least partially because I don't host my own site, and very few hosting companies are comfortable with running a Java ServerPages-enabled site. But even when I do home portal stuff, servlets and JSPs are doable–but why would I waste my time when I can do it with a little server side script?

Java 2 Enterprise Edition is not a hobbyist's toolset. I don't sit down and say, “Hey, I should write that [insert trivial application here] in Java.” Hell, it's not even appropriate for enterprise software projects with a lifecycle of less than six months. And, no matter what Sun tells you, Java is not exactly knocking anybody dead on the desktop; moving the focus of Java to the app and web server was the smartest thing the Java community ever did, because it widened the potential client system audience exponentially.

But that's not to say that Java couldn't move down into the world of trivial applications. You have to start off a little higher up the dev tool food chain than notepad.exe to make that happen, and you have to make the “include” process more transparent to developers. In fact, that should be determined at build time, not by the poor sap writing the code.

There are already some very good Java IDEs out there. But it's not just a cooler, flashier IDE that Java needs–it needs a tool that's got better property-driven components that can be rapidly assembled into applications. The key to the success of VB was the ease with which you could wire it to an external data source. ODBC and data-aware controls together, not just ODBC, made Visual Basic what it is today. Any moron with VB could create a client application that accesses a relational database.

Unfortunately, the Java IDE ecosystem has withered quite a bit over the last two years; now Borland is pretty much the only show in town outside Sun and IBM (and a personal bitch here: Borland's JBuilder for Mac is still back in version 6, while the rest of its tools have gone through 3 more generations).

The bottom line, it seems, is that Java's corporate custodians want it to be hard to use. They want it to be an enterprise tool that acts as a vehicle for consulting services; and with the increasing amount of open source Java tools available out there, they're depending on services to be what makes them money on Java. Look at IBM's WebSphere suite–it's a suite only in name, with no really clean integration of components. Some assembly required, your consultants put it together.

Greenspun's got it wrong. Java could be a sports car, or a skateboard. But the way Java is delivered to most developers right now, it's a 747, not an SUV. Companies end up with full blown J2EE servers when all they ever really run are JSPs and servlets. One corporate development manager told me that “what I need is a ball-peen hammer, but IBM insists on selling me jackhammers.”