by Andrew Haley
Contributing writer: Thomas Fitzsimmons
At the 2006 JavaOne conference, Sun announced plans to open source Java. This wasn’t exactly a surprise to those of us working on Java at Red Hat, given that there had been rumblings before. But this was a real announcement. We were immediately interested in learning exactly which license Sun would choose. Even if it was a legitimate open source license, it still might not allow us to combine our code with Sun’s.
We have been working on free Java for many years–most particularly through gcj, a project started at Cygnus in 1998 by a developer named Per Bothner. Gcj has been steadily improving over the years, but still wasn’t fully Java-compatible, partly because we couldn’t get permission to run the official Java compatibility test suite. We had also been working on GNU Classpath, which is GNU’s free replacement for the core Java class libraries from Sun. We were very curious to see the “official version.”
We were thrilled to hear Sun announce in November 2006 that it had selected the exact same license as GNU Classpath.
When the complete Java source code–now called OpenJDK–was released on May 9, 2007, there were a few challenges. Most notably, some of the code was missing. Over the years, Sun had licensed Java libraries from a variety of sources, some of which would not allow their code to be open sourced. In order to work with this encumbered code, Sun provided some “binary plugs” that were copied into the build. This presented a problem as Fedora’s rules don’t allow the inclusion of anything that isn’t open source. It’s hard for us to maintain confidence in code we can’t see.
We were 95 percent of the way to a truly free Java. The way to fill that last five percent became clear: use the code from GNU Classpath. We later discovered that one of the reasons Sun selected the Classpath license was so that they could work with the Classpath developers and the Linux distributions that already used GNU Classpath. This was a great vote of confidence.
We needed to start a project to combine OpenJDK with the GNU Classpath code. This project could have been hosted within Red Hat, but we didn’t want this to be seen as Red Hat only. Classpath came to the rescue and Mark Wielaard, GNU Classpath maintainer, set up the IcedTea project. This is the repository for the totally free version of OpenJDK.
Bootstrapping was another not-so-obvious problem. Much of OpenJDK is written in Java. Sun built the first release of OpenJDK with its unfree Java. Fedora, however, doesn’t allow packages to depend on any unfree software. This time, it was gcj that came to the rescue. Since gcj is completely free software, we could use it to build OpenJDK. This also ensured that unfree code couldn’t “leak” into our OpenJDK package during the build process.
Over the next few weeks, a team within Red Hat worked vigilantly to create the OpenJDK and GNU Classpath hybrid that was to become IcedTea. Less than a month after we received the OpenJDK source code, we were able to release IcedTea 1.0. In a few cases, we had to create non-functional stubs for code we didn’t have, but the result was good enough to run many of the Java applications in Fedora. Since then, Sun has created replacements for many of the binary plugs and we have gradually been able to remove much of the GNU Classpath code.
The OpenJDK that Sun released only ran on i386 and AMD-64 machines. Fedora runs on other systems, in particular those based on the PowerPC. To solve this problem, we started an IcedTea porting project. That project produced an interpreter-only OpenJDK port for the PowerPC, based on Sun’s C++ interpreter. This later became Zero, a truly portable “zero assembler” version. As you might expect, a pure interpreter is not as fast as the high-performance JIT (Just In Time) compilers often used in Java implementations, but we’re working on that.
The OpenJDK code that Sun released was a preview of Java SE Version 7 rather than an implementation of Version 6. Java SE Version 7 has not yet been released and neither has its specification, so IcedTea cannot officially be certified as compatible with anything. Despite this, it works so well that we shipped it with Fedora 8.
Though it is not officially part of the Java platform, for many Fedora users the Java web browser plugin is essential to a complete desktop experience. Sun did not open source its Java plugin with OpenJDK, presenting another opportunity to utilize IcedTea. GNU Classpath includes a Java plugin named, for historical reasons,
gcjwebplugin. By adapting Sun’s applet viewer code slightly, we were able to integrate
gcjwebplugin into IcedTea to provide a working Java plugin. This plugin was released as part of Fedora 8, and is installed by default on both x86 and x86-64. This was the first time a 64-bit Java plugin had been available to Fedora users; unfree Java plugins are 32-bit only.
The plugin is closely related to the other Java deployment technology, Java Web Start, which also currently lacks an open source replacement. We’re working on IcedTea to complete the support for both the plugin and Java Web Start. We’ve integrated and extended NetX, an open source web start implementation; it is now nearing release-readiness for Fedora. We’re making good progress on
After the release of Fedora 8, the lack of an open source version of Java SE Version 6 became more of a problem. Developers were using IcedTea on Fedora, but as it was a preview of Version 7, there was a risk that people might rely on libraries and interfaces that would change when Version 7 was released. Sun started an OpenJDK 6 project, which took the OpenJDK 7 code base and made the changes necessary for it to be compatible with Version 6. We immediately realized that this would be far more useful to Fedora users and developers.. After some discussion, we decided to base the next Fedora’s OpenJDK on the Java 6 code.
At the same time, Sun decided to allow Fedora to use its OpenJDK trademark for IcedTea. This makes perfect sense as there are now so few binary plugs needed to build OpenJDK that it’s a distinction without a real difference from a user’s point of view. Fedora 9’s package is now called OpenJDK, not IcedTea, and it is based on OpenJDK 6.
We have also been permitted to run the official Java SE Compatibility test suite on OpenJDK. This test suite has a crucial role in Java: to be called Java-compatible, an implementation must pass every one of tens of thousands of tests. Simply running this test suite is a huge effort. We still fail some tests, so our OpenJDK package cannot yet claim to be Java compatible, but we are working on it. Watch this space. When we pass the last few tests, we will finally be able to say “Java is free!”