HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

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.

Author Bio
Joseph Ottinger is a consultant with Fusion Alliance (http://fusionalliance.com) in Indianapolis, and is one of the administrators of and contributors to the OpenSymphony project (www.opensymphony.com). [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.