Last month I took a trip down memory lane, revisiting the history of J2SE. Apart from trying to remember key events, squeezing 10 years of history into one page was a challenge. I had to relegate many significant technologies to a sentence or two and some I didn't cover at all. However, looking at the future of Java is like looking at NASA's Apollo plans after the first walk on the moon. Yes, there will be valuable missions or releases, but even NASA canceled the last three moon missions due to budget issues.

The good news is that mission control has already have scoped out the 6.0 and 7.0 releases that will extend the Java release roadmap to 2008. Beyond the planned features in 6.0 that I am covering here, Sun has already hinted at Java's future through some recent statements and comments - a renewed focus on scripting languages, and new, but still not open source, Java licensing. Although the rework of the licenses is a good step, the opportunity to make a real statement has been missed. Both the JVM specification and Java language specifications are now mature enough to be handed to an external standards body, something that was promised in the early days of Java and I feel that now would be a good time to make whole on that commitment to developers worldwide.

Back to J2SE 6.0, code named Mustang. Planning for this release started in the summer of 2004 and is due to be shipped in the middle of 2006. JDK releases normally stick to the end of a quarter if possible, so that would mean a release date of end of June 2006.

The proposed JSR list included with the umbrella Java Specification Request 270 contains many familiar specifications. Why? Because a good portion of them were also slated for the Tiger release but were dropped for one reason or another.

Before I mention the JSRs that are included, it's worth mentioning one that is not there - JSR 203, the enhancements to New IO. The Google EC member mentioned that JSR 203, which was slated for Tiger, has now missed 6.0, which could mean it would be 2008 before this JSR is ever released. Realistically, those users who needed functionality like asynchronous IO have probably made alternate plans by now; waiting four more years is too long for even the most patient developer.

J2SE 6.0 and Web Services
The lion's share of the functional updates to J2SE 6.0 are in Web services. The plan is that J2SE will be the delivery platform for JSR 105, the XML digital signature API; JSR 222, the XML data binding JAXB 2.0 API; JSR 224, the JAX-RPC 2.0 API; and a penciled update to the core XML platform. By default J2EE will also inherit these specifications in its next release.

J2SE 6.0 and the Java Compiler
J2SE 5.0 contained many changes to the language and compiler so it wasn't too surprising that two JSRs that missed the J2SE 5.0 train are now slated for J2SE 6.0. The first was an interface to the Java compiler, JSR 199, and the second was a part of JSR 202 that included changes to the Java verifier. The compiler API was originally thought to be necessary for JSP pages and Ant, however, those technologies now use a well-known interface into the compiler. The updated specification contains an API that exports dependency information that would be useful with many build tools. The split verifier as described in JSR 202 is already used in J2ME land; it improves verification by generating verification tables at compile time and then using this information at runtime. The runtime verification is therefore faster, however, the tradeoff is a larger class file. How this impacts large applications is still to be seen as is the question about whether the JDK should verify its own class files.

One new JSR for J2SE 6.0 is JSR 269, the Annotation Processing API. This builds on the addition of annotations into J2SE 5.0. Its use is primarily for tools, but developers will get to see the high-level benefits of it.

Is This Your Card?
I guess I'm as surprised as some others that a smart card API is really needed in the J2SE platform as proposed in JSR 268. Sun employee badges have embedded smart cards but the leap toward making every JVM in the world require additional code seems grandiose. My own desktop at Sun didn't support smart cards so testing this even at Sun is going to cause many headaches.

JSR 223, Scripting for the Java platform, is designed to expose Java objects to scripting languages like PHP. PHP 5.0 is already object oriented; whether those users will make the effort to learn Java is anyone's guess.

Wrapping Up
The last two proposed JSRs are JDBC 4.0 (JSR 221) and Javadoc changes (JSR 260). JDBC 4.0 builds on J2SE 5.0 metadata and generics to improve data access and management. JSR 260, Javadoc tag improvements, is primarily driven to improve the documentation of J2SE and the tools that generate Javadoc.

In closing, the future of J2SE, like those Apollo missions after the first moon landing, may not make history but will no doubt be of value. However, those trips to the moon will eventually move to the back burner so it's doubtful that any future improvements will be like rocket science.