Piecing together free java

The libre-java movement got a huge boost on November 13 2006, "Java Liberation Day". On that day, Sun announced its intent to distribute all the source code for their implementations of Java Standard Edition (SE, code name OpenJDK), Enterprise Edition (EE, code name Glassfish) and Micro Edition (ME, code name PhoneME) as free software. All are licensed under the GPL, using the classpath exception clause for selected libraries.

Sun went out of its way to make its commitment to the GPL, with everything it implies, very clear in an extensive FAQ. Two things, unrelated to source code, are reserved: the specification and certification of Java is reserved for the JCP (Java Community Process), while Sun controls the usage of the Java(TM) trademark. Everybody is free to run, copy, distribute, study, change, share and improve the source code for any purpose as long as they follow the tit-for-tat, share-alike, copyleft rules of the GPL for all the code they release.

Sun not only contacted big Free Software names, like Richard Stallman and Eben Moglen, before the event, the company also made sure that the existing libre-java communities knew about the plans before it all hit the press. Jonathan Schwartz, the Sun CEO, himself explicitly reached out to the existing GNU Classpath, GCJ and Kaffe communities with an offer to collaborate with the developers making libre-java on GNU/Linux a reality. The Sun OpenJDK engineers came to the Fosdem conference to have a DevJam and share their ideas with the existing libre-java communities.

Sun couldn't liberate all the code at once, but did so in stages for anything it could get all the rights to over the last year. At the same time, Sun has been slowly opening up the internal development process and switching to a public repository for all the code (Kelly O'Hair keeps a blog that is a great case study for moving a large project to Mercurial). Currently all code for Glassfish and phoneME have been released, while about 96% of the OpenJDK code base is available (almost all the parts not released yet are because Sun couldn't get the rights from some third party). Rich Sands gives a great overview of how all this looked from inside Sun in his one year retrospective on java liberation day.

Meanwhile, an effort called IcedTea was started to put OpenJDK into GNU/Linux distributions by moving it quickly towards that 100% free software line. As Andrew Haley explained during the official announcement, it is an experimental build tree that tries to stay close to the OpenJDK upstream but does not contain any non-free proprietary blobs. Those pieces are either stubbed out or replaced with code from GNU Classpath. IcedTea can be built using only free software. In particular, you can use GCJ for the first build phase to bootstrap those parts that depend on a working java compiler and runtime. It can be easily built on a modern GNU/Linux distribution with a simple ./configure && make; or at least that is the theory. It builds out of the box on Fedora 7 or 8. For Debian and Gentoo some additional steps are still needed.

Because OpenJDK didn't have a open bug database and (until recently) a source code repository, IcedTea has an open public bugtracker and a mercurial repository. All discussions about the code are done on the public OpenJDK distro-pkg-dev mailing list.

IcedTea is what most GNU/Linux distributions ship now for x86 and x86_64 in addition to GCJ for other architectures. IcedTea also adds some things that make things easier for distribution packagers. It adds patches so that the runtime and core libraries link to system shared libraries, like zlib and libjpeg, which should make security updates simpler. It adds support for using things like the system wide tzdata files for the TimeZone utility classes. It also supports using the system installed certificate authority files for security related checks as used in the ssl network classes. Thomas Fitzsimmons, who helped with the above items, keeps a Packager's Wishlist for OpenJDK.

IcedTea also contains some bug fixes from people who submitted patches to the OpenJDK upstream, which haven't been accepted yet, to give them a wider testing audience. Others have offered alternative backends for existing packages that make java applications integrate better in a GNU/Linux system. An example is the GConf backend for the java.util.prefs package by Mario Torre, which he ported from GNU Classpath.

Lastly, IcedTea is a testbed for porting OpenJDK to other architectures beyond the currently supported x86, x86_64 and sparc. There are two different approaches. The first is to start with the Hotspot C++ Interpreter. HotSpot is the runtime of OpenJDK and actually contains another byte code interpreter by default, the Template Interpreter which is a bit harder to port. After requests from the community, Sun also released its older C++ based interpreter to help the porting effort. Gary Benson recently made a breakthrough and got that working for PowerPC (both 32 and 64 bit). He wrote a guide to porting IcedTea that will hopefully help people porting to other architectures. Of course the interpreter alone is slow, but the benefit is that you get a full system up and running that is similar to the existing architectures with full support for all features. The next step is to add support for the HotSpot just-in-time (JIT) compilers, which will be a lot of work.

Another approach is taken by the Cacao team who are working on replacing the whole HotSpot runtime with a libjvm.so based on the Cacao JITs, but reusing all of the core libraries. This now works for s390 and powerpc. Cacao also supports alpha, arm and mips, so this is an interesting path for getting a faster port. You will have to replace all of the Hotspot runtime to get it. The Cacao VM is still missing some features, like annotations and full debugging support.

There are some other interesting developments around former GNU Classpath-based projects that are now experimenting with combining their code and the new OpenJDK and/or PhoneME projects. Dalibor Topic worked on a Google Summer of Code project to make the OpenJDK javac compiler a source-to-bytecode front end for the GCJ native compiler. The MIDPath project combines elements of SE and ME, plus different backends (SDL, FB, AWT, X11, Gtk+ and Qt) to provide access to MIDP2, a mobile devices standard used on many phones for various platforms. JaLiMo provides all of the above packaged for the Maemo and OpenMoko platforms. JNode is a full operating system written in java that is now built upon a hybrid of OpenJDK and GNU Classpath libraries. There is also the IKVM project that is providing a java implementation, translation and interoperability framework for .net implementations like Mono.

With all this one could safely say that The Java Trap has been dismantled. But even with some replacements from GNU Classpath, IcedTea/OpenJDK is still missing some small parts. The java.sound implementation isn't complete, but Sun released the parts so it could. The Java Management Extensions (JMX) implementation is missing SNMP support. Applets are currently supported through gcjwebplugin, which has the benefit that there is finally a 64-bit plugin, but it is still missing LiveConnect (Java/JavaScript integration). And finally there is no support yet for Java Network Launch Protocol (JNLP aka Java Web Start), although there is netx, which might be added to IcedTea soon.

So when you put all the above together, what Java version do we get? Officially what the GNU/Linux distributions ship now isn't Java(TM) since it isn't certified. And IcedTea comes with the following warning:

Red Hat has recently signed the OpenJDK Community TCK License Agreement. This gives them access to the test suite that determines whether an implementation that is derived from the OpenJDK project complies with the Java SE 6 specification. This will cover the binary releases that they ship (while the source code will of course still be available under the GPL). This agreement does, however, contain an NDA which prevents talking about how compatible the current code is. The test compatibility kit itself is still proprietary, so it will be hard to work together with the community at large on this.

One year after Java Liberation Day modern GNU/Linux distributions are starting to ship with a more complete free java-like stack than ever before, but there are still some small loose ends to tie up. It was a learning experience for all communities involved as suddenly the whole free java ecosystem changed. There was certainly a lot of frustration about the speed with which things opened up. On the other side, there was frustration with the fact that shipping something purely-free seemed more important than compatibility. But Sun consistently kept its promises about opening up. The existing libre-java communities learned to respect and take advantage of the now free reference implementation of the code that they worked so hard to replace over the last decade. Now the fruits of collaboration and reusing each others code is materializing. In less than another year, it will be common to have a full, free, java stack, either SE, ME or EE, wherever you find GNU/Linux running.

[ Mark Wielaard has been doing libre-java development since 1999. He is also the maintainer of GNU Classpath. He is currently employed as an engineer by Red Hat on non-java related projects. ]