I've been actively involved with Java development in one way or another since 1996, including working with some of the original issues of the servlet specification, the early adaptation of the EJB spec, and migration to JSP not long after it became an official part of the J2EE spec. I remember when Rick Ross first sent his e-mails for Javalobby on Usenet; I remember playing with the specs to discover if the grail was to be found in them as promised.

It hasn't come through for me. That's okay, because technology is and will always be a moving target; I've refined what the grail is as I've come near it many times, and I will continue to do so as long as my career is not completely stagnant. What worries me, though, is the thought that the grail is actually moving further away as time goes by, instead of staying just out of reach, like a carrot for a hungry dray horse.

The Java Community Process was supposed to give relevant people in the Java Community a chance to influence the specifications in positive ways. It's guaranteed to be an arduous process, and it has lived up to its billing. What Sun needed to do was guide the expert groups down a path laden with thorns to determine not only what was best, but how to get what was best implemented. What it did was let the expert groups descend into a morass where those who shouted most were heard.

The Enterprise JavaBean specification is a good example of this. EJB 1.0 fell critically short of being easily deployable; EJB 1.1 added some great features, and 2.0, while fulfilling some of the void left by the 1.1 specification, has sadly started to invalidate EJB's promise. The best things about EJB remain the same; the new additions, such as local interfaces, simply add complexity where it's not needed. And that's where Sun's community process has failed. Nearly every container already had an implementation of local interfaces before they were added to the spec; they were added as a sop to a few major players who simply hadn't kept up with the "smaller" containers. Obviously, it was possible to do without a lot of overhead, yet Sun felt it was all right to make not only every container but every EJB coder work with extra interfaces as well as a separate use model. This is the JCP breaking down; instead of making life simpler, it made it harder and didn't actually finalize the most crucial areas left in the entity bean section of the specification, such as finalizing the managed relationships.

The 1.4 API's logging model is another example of this: taken nearly verbatim from Log4J, it's a floodgate-based model, where each category can be set up individually, and as messages rise above a deployer-specified "message level," they become visible in the output stream. This is nice, certainly nicer than System.out.println() strewn throughout code, but the introduction into the 1.4 API would have been the perfect time to present something more powerful by default, such as a bitmasked logger, where you would be able to say you wanted to see all "startup," "info," and "fatal" events in a given category, and in another you wanted to see only "startup" and "shutdown" events. Instead, Sun continued to take the easy way out, repackaging Log4J according to various contributors in the expert group and letting it go.

I would have liked to see Sun actually leverage the expertise of the Java community ­ it could spend time developing the language and application interfaces while accepting the contributions of programmers who could improve the core implementations. That would yield massive benefits: a best-of-breed would appear in the language API and application developers would feel empowered and more invested in Java. A best-of-breed would probably have prevented things such as local interfaces (which actually do have a beneficial performance impact, just not enough of one to justify their cost), and allowed a more open discussion of other relevant APIs.

As Sun continues to allow the JCP to run wild, contributing APIs that don't actually improve the usage patterns of the language, Java will grow more and more irrelevant, until the weight of the poor APIs drags it into oblivion. Sun needs to listen to its own best practices groups, and eliminate the cruft introduced by users who very competently implement things that run counter to the mindset that made Java the useful tool it is today.