This month I wanted to review some of the latest happenings in the JDK 6.0 (Mustang) release. Although we have to wait to see the initial JSR draft, you can download the binaries the engineers are actually working on. Some of the newest features to be added include JSR 223 scripting support and JAX-WS 2.0.

JAX-WS 2.0, if you weren't already aware, is what would have been JAX-RPC 2.0. Apparently the name JAX-RPC was just too confusing for developers to work out what it did according to one source. While I don't share that belief and I'm sure not everyone at Sun does, the combination of JAXB and JAX-RPC together is worthy of a rename especially since there could be potential incompatibilities with earlier JAX-RPC releases on the client side.

Getting the JDK 6.0 Download
Getting the prerelease of JDK 6.0 is actually nicer than getting the final release. As the binaries are hosted on http://java.net, there are no annoying additional click-through licenses. However, producing weekly drops is still a relatively new exercise; although there are references to AMD64, those downloads should work fine on the Intel x86-64 equivalent. As for the reference to the "Solaris SPARC AMD64 self-extracting file" on build 40, I trust that is a typo and not an impending new hybrid chip. The downloads reuse the Java Pack API, which reduces the download size and adds a small step to the installation.

First impressions with the Linux release are good. Startup performance seems to be in the same ballpark and the demos I tried worked. Although it's getting harder to find Web sites that use Java applets, there are some still to be found on http://java.com.

What Is in the Release So Far?
The introduction of JAX-WS brings a few more scripts to the platform. xjc is the binding compiler wrapper to map XML to Java types. There is also a new command wsimport that when running gives clues that it used to be the better-known wscompile. wscompile is used to generate the Java helper files from a WSDL or service definition.

I mentioned the addition of JSR 223 earlier. At the moment the changes are at the API level only; there are no examples or shell interface. The scripting API is exposed as javax.script and a Rhino script implementation (Rhino is an open source JavaScript written in Java) as com.sun.script.javascript and sun.org.mozilla.

The quickest way to get started with what the technology has to offer is to head over to www.mozilla.org/rhino/doc.html. The example RunScript launcher script can be easily modified to import the sun.org.mozilla classes instead of org.mozilla. In addition, you need to catch a sun JavaScript exception. The RunScript launcher allows you to supply JavaScript as a command-line option to the JVM. Once the API has been made official, the normal method would be to use the new javax script engine hooks.

An example of using RunScript with JDK 6.0:

java RunScript 'java.lang.System.getProperty("java.version")' 1.6.0-ea

Another neat feature is an incremental improvement to the Java IO API. I mentioned in an earlier article that the NIO JSR changes have slipped the release. However, you can now see how much disk space is available without having to resort to a JNI call.

The following code snippet reports 1K blocks of space on directory /export.

File f =new File("/export");
System.out.println(f.getFreeSpace()/1024);
System.out.println(f.getTotalSpace()/1024);

Client Java Changes
Although many of the server changes are bounded by API approval, the majority of the client changes are implementation-dependent only. So as long as the API remains the same, the engineering team can continue with development. This means that a good portion of the client-side functionality has been done.

One very simple feature I was able to test out was the splash screen API and splash screen launcher. You can try it out too. The following example was run from the demo/jfc/Stylepad directory:

java -splash:src/resources/rabbit.gif -jar Stylepad.jar

You'll then see the rabbit image appear as a splash screen. Many of the other client features are purely API driven, including the desktop integration. This is probably sufficient for ISV/tools developers; however, it may take a while to see serious adoption by the majority of developers.

Vote Away
One request from the JDK 6.0 team I wholeheartedly agree with is logging or voting on bugs you discover. I found a couple when writing this editorial, both of which were already identified by the QA teams. I was able to vote on them though.

The Sun JDK product has a long integration cycle, meaning that getting approval to integrate bugs even up to a year before the release gets increasingly difficult. Unless a bug is a true showstopper, don't expect a fix if the release date is within three months (a cycle of testing takes over a month).

In conclusion, the JDK 6.0 release can certainly be taken out for a test download today. Hopefully the line on startup time and quality can be maintained until we see the final release.