Java News from Thursday, February 5, 2004

Sun has posted the first official public beta of Java 1.5. a.k.a. Tiger. As usual, it's available for Windows, Linux, and Solaris. There are numerous language level changes in Java 1.5, more than in any previous release, including:

According to Sun's web site, "The most important Java technology release in years includes new Java language updates, monitoring and management support, and a focus on rich clients for the desktop." According to me, the whole Java edifice is getting increasingly creaky, and preparing to collapse under its own weight. The new generics syntax a perfect example. While I think generics in general are a very good idea, the Java 1.5 implementation makes far too many compromises with backwards compatibility. For instance, potentially very inefficient boxing and unboxing is require to support primitive data types. Furthermore, the generic collections aren't actually statically typed. It is possible to store a Frame in a List<>String without the compiler objecting. Most of the time, everything works, but it's very kludgy and not at all clean. And this is just one of many examples.

It is increasingly obvious that Java is heading down the same road C++ travelled. Unless Sun is willing to throw off the chains of backwards compatibility, someone else will. I don;t know who that someone else is, but they will replace Java just as effectively as Java replaced C++. It might be just possible to maintain binary compatibility with most existing Java code, but source compatibility should be abandoned.

Java 1.5 also makes numerous changes to the virtual machine including:

Of course, there are also numerous changes to and additions in the class library. GUI wise, there are numerous enhancements:

In java.lang, we find System.out.printf(), which does pretty much what all the reeducated C programmers will expect it to do. There's also a new console input API, though fortunately it doesn't look a lot like scanf. In 2004, I hope we've all stopped using the console as a user interface, but I still expect to see a few dinosaur professors using this to finally translate their C notes into Java.

For multithreaded applications, the java.util.concurrent package provides real semaphores. (Think of them as wait()on steroids.)

New networking features include:

XML wise not a lot has changed. The bundled parser is now Xerces 2.6.0. The XSLT engine is XSLTC (from Xalan) 2.5.2. DOM Level 3 and XML 1.1 are now supported. Most significantly, the JAR archives are separated out from the main runtime into five separate files: sax.jar, dom.jar, jaxp-api.jar, xercesImpl.jar, and xalan.jar. This should make it much easier to replace outdated versions of XML tools, a perennial problem in Java 1.4.

Other enhancements scattered throughout the class library include:

Toolwise, I note that Sun has backed off on using breakiterator for JavaDoc, something that had been driving me nuts in XOM because it didn't work with my well-formed XHTML doc comments. That's good. The compiler has a -Xlint option to turn on extra checks. That's going to be essential with the increasing complexity of the language, especially generics. Jar files can be "hyper-compressed" in a new Pack200 format. I just wish they'd make it possible to store resources in a JAR archive in a way that doesn't break in every other server-side container.

Quick summary: there's a lot of good new stuff here that will be useful to many users. However, much of it has been bolted on to a framework that was never designed to support anything like it. The result is a confusing mess, with lots of rough edges where the pieces don't join up precisely right, just waiting to trip up the unwary programmer. Often when a physician is treating an injury vitim, they have to break a few bones first. Java's bones are looking pretty disjointed these days, and if Java is going to move forward, it may be time to break a few bones and reset them.