Or the blog that wanted to be a talk… ;-)

Disclaimer: as usual for this blog, these are my personal thoughts, and not necessarily those of Red Hat.

The History

IcedTea started at Red Hat in the summer of 2007 as a means to deal with the requirements of building the new OpenJDK source code base on GNU/Linux platforms using only Free Software build tools. The OpenJDK source code was (and still is, to a large extent) built on a completely different set of inherent assumptions to those held by a GNU/Linux distribution packager; it was designed to produce a set of binaries which Sun could ship and which would run on as many platforms as possible with as few dependencies as possible. In contrast, a packager wants to make use of existing packages as much as possible, because this reduces the support footprint of the package. In fact, not bundling libraries is a requirement on some distributions, such as Fedora, one of Red Hat’s primary targets. It also didn’t matter too much to Sun what tools were used to build the JDK, as long as they were available and didn’t impact on the end result; the binaries. In contrast, distribution builds need to work with tools available within the distro and often without network access.

When OpenJDK first shipped, a proprietary JDK was required to build and some parts were still in process of being opened up, and so were provided by proprietary binary blobs. Red Hat did an admirable job of fixing things, within the auspices of IcedTea, within a month of the first OpenJDK source code drop, so that OpenJDK could be built and run with Free Software tools, using parts of GNU Classpath to replace some of the plugs. This was packaged in Fedora and provided an early version of what would become OpenJDK 7 to its users.

The Progress of Time

The situation has changed in the four and a half years since IcedTea first appeared, both in terms of OpenJDK and IcedTea itself. When OpenJDK started, code was provided simply as tarballs. There were no source code repositories and no bug tracker. The first of those changed by December 2007 when the Mercurial repositories were first populated. We’re still waiting on the latter, though there has been a Bugzilla experiment in the interim. Thus, IcedTea was setup as a place to do work on OpenJDK because there was no other place. Now, that there is, with its own groups, projects, repositories and bylaws, and with the proprietary plugs long a thing of the past, we have to question whether IcedTea is still required.

A number of issues arise when we start to consider dropping IcedTea and moving work upstream:

  • IcedTea still contains a lot of local patches. Progress is being made on getting these into OpenJDK, but it’s still a very slow process. A patch that is ok for the users of IcedTea needs to be reconsidered and often even rewritten for adoption in OpenJDK. A large amount of work was done in that area prior to the first release of IcedTea 2.x (the OpenJDK 7 series); notably, the system library patches were written to become build options rather than a one-way transition to using the system versions. However, the origin and need for some patches is hard to trace, and of course, work continues so new patches are needed all the time.
  • IcedTea is now home to a number of other sub-projects;

    • it has support for replacing HotSpot with CACAO or JamVM
    • it has its own fork of the jtreg testsuite so it can be built easily and used to test the build
    • it has a PulseAudio sound driver
    • it includes a plugin and web start implementation which aren’t present in OpenJDK; this started in IcedTea itself, but was split off into its own repositories and development cycle (IcedTea-Web), so it wasn’t tied to IcedTea releases.
    • It includes an ARM32 port which, for licensing reasons, can probably never go upstream.
  • Working in OpenJDK requires signing a contributor agreement with Oracle and working with a team overwhelmingly dominated by Oracle employees, where occasional things happen behind closed doors (though the new governing bylaws and IBM’s involvement seem to have reduced this a little). Some people just feel a lot more comfortable putting their patch in IcedTea instead, which is much more akin to a traditional FOSS development project.

The Future

With the advent of OpenJDK 8 later this year, it comes time again, as with 7, to consider whether and how IcedTea should continue. In that respect,I’d like to use this blog to ask people for their thoughts on the matter, in particular how they see their ability to work with IcedTea as opposed to OpenJDK.

From my perspective, I think we could move to a situation, on a technical basis, where we work primarily with OpenJDK itself, with the odd patch that needs to be applied locally. My main concerns are with release management. IcedTea has followed a traditional path of updating existing releases with security updates and providing new releases with feature improvements. In the case of the work on 7, these have mirrored the upstream 7u project as close as possible. However, the situation upstream leaves a lot to be desired. Security updates are not applied to the last 7u release tree, instead being applied to the next in-development version. This leaves open the question of how do we get these security fixes out to users if we don’t have IcedTea? Moreover, the release process lacks transparency, and releases such as u10 have just been withdrawn with little explanation. If, for 8, we were to work closer to upstream, this would need to change.

I do see IcedTea continuing in some form, at the very least for things like CACAO & JamVM. If it continues as a patch provider, then I strongly suggest we start afresh from OpenJDK and only apply what patches are needed, with solid written reasoning for each one, rather than dragging along the baggage from 6 and 7.


Update: It appears a question mark is too subtle for most people… :) So I changed the title.