kuarepoti-dju - the josef multilingual blogosphere


Sorting out the Java mess

Categories: — josef @ 18:15

Java can be considered the lingua franca in the area I’m working in. I’m always positively surprised when a student or two come up with ideas in other languages, but for the most part, there doesn’t seem to be a way around Java, since this is the only halfway-quality language most students can handle.

With Java becoming GPL, ideological problems should vanish. Or so one thinks. Of course, the idea is nice, and I whole-heartedly support it, but a lot of work will be needed to turn it into a reality. During this year’s upcoming FOSDEM event, OpenJDK/Sun people and Classpath people want to meet. This isn’t the first such meeting, but AFAIK the first big one since the GPL announcement which coincided with the last Ubuntu meeting which already had some Sun and Classpath (or Java-Debian, for that matter) people on board.

The issues I see are manyfold. Java has gained a lot of capabilities in terms of implementations of existing JSR specifications. Before JDK 1.6, one has needed a few additional libraries of what is now available for Java proper. Especially for Apache libraries, which are ASL 2.0-licenced for most parts, this means a GPLd Java runtime will be preferred by GPL application authors. However, the build system must still support the Apache libraries just in case the JDK is not at 1.6 yet. Furthermore, the GPLv3 seems to clear up the (already highly theoretic) incompatibility between ASL 2.0 and GPLv2.

Such additions to the Java core are not new. Already in the past, a lot of XML capabilities were added and therefore fallbacks must be available in case the JDK or at least the JRE at the deployment site is too old.

For one of my upcoming releases next Monday, I finally had to look a bit more into this and see which Sun Java and GNU Classpath implementations would fit my bill.
Interestingly, this flashed my mind on many fronts, since quite a few weird runtime errors I’ve seen can be attributed to version incompatibilities.
The outcome is that JDK 1.5 wins, while JDK 1.6 is not ripe yet and JDK 1.4 is way too old and requires too many additional libraries. Classpath 0.93 is nearly there, but I added some bug reports to their tracker.

We’re incrementally getting there. Of course, the flashy parts such as mobile phone emulators are still proprietary software, and time will tell if they will ever get opened up. They’re not available for Mac users, but they’re available for Linux, so the majority of complaints of them being non-free should interestingly enough come from the Mac crowd :)

As soon as everything is free, distros might offer Java installed by default and therefore turn into a rocking development platform for this language. However, since Java has been kind of isolated for so long, it comes with its own build infrastructure (ant, maven) and its own repository, which doesn’t really handle versioning well. Proper packaging will help in identifying compatibility issues.

It remains to be seen how third-party Java developers, especially IBM, will react to these developments. Some certainly nice IBM Java tools are still proprietary software, which makes them unsuitable for students to explore and to improve. Anyway, after nearly 2 years of working with Java software extensively, the overall opinion is that it has improved to the better, and cheers go out to those who made it happen.

Powered by WordPress