[gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

It seems there has been some confusion over the naming of the ebuilds
for OpenJDK/IcedTea
support within Gentoo, so, at Petteri's request, this e-mail aims to
clear things up and hopefully
alleviate some of these issues.

Understanding the naming really involves understanding the development
of OpenJDK so far.
The release of Sun's reference implementation of the Java SE platform
was completed in May 2007,
and this codebase was known as OpenJDK.  This basically represents the
current state of what
will eventually become Java 1.7 or JDK7, the contents of which are
still unknown as there is no
JSR for this platform as yet.  The platform specification does not
include the plugin or webstart support,
so, given the state of this code, it was not included.  On initial
release, about 4% of the code base
was also missing, having to be replaced by proprietary binary plugs
from one of the proprietary Sun JDKs.
Thus, although we were much closer to a complete Free JDK, there were
three major issues remaining:

* The released code was for 1.7, not the 1.6 release actually in use,
and it couldn't be certified as Java(TM).
* The code couldn't be built Freely, preventing its use in Fedora,
Debian and Ubuntu.
* The plugin and webstart support which users would expect from a JDK
were missing.

Two of these issues were quickly solved by hackers at Red Hat who
started the IcedTea project.  This provided
a way of building OpenJDK using existing Free Java runtimes such as
GCJ and provided replacements for the
encumbrances using code from GNU Classpath.  gcjwebplugin was also
modified to provide plugin support
against Sun's applet code rather than GNU Classpath's, and the
existing NetX project continued its development
as part of IcedTea, providing webstart support.  Resulting binaries
shipped as a package named 'icedtea' in
Fedora Core 8.

Over time, OpenJDK and IcedTea continued to develop.  Sun provided
replacements for some of the encumbrances,
mainly in the area of Java2D such as font and renderer support, and
cryptography.  IcedTea was kept up to date with
each new OpenJDK cooked build, by modification of the existing
patches.  This continues today, with the latest
IcedTea release being 1.7.  Ebuilds for both 1.7 and the live
Mercurial repository are held in java-experimental, as
they provide a snapshot of 1.7 development rather than a completed JDK
aimed at the user.

In early 2008, Sun began the OpenJDK6 project to provide a Free 1.6
implementation, and allowed external developers
(notably Red Hat) access to the Java Compatibility Kit (JCK) so that
the resulting builds could be demonstrated to be
compatible with the existing proprietary JDK6 builds provided by Sun.
OpenJDK6 was created, not from the proprietary
JDK6 tree (which would require another legal review on the epic scale
already undertaken for the JDK7 code), but by
taking the OpenJDK tree and removing new features added by Sun developers.

The issues with building the code and the encumbrances remained with
OpenJDK6 so a matching IcedTea6 tree was launched
to provide the same level of support to the new code base.  It is a
build of IcedTea6 from Fedora that recently passed the JCK,
finally proving that a certifiable Free JDK implementation can exist.
Getting to this point was non-trivial, as the base of OpenJDK
and then additional patching by IcedTea meant that the codebase was
quite distinct from the proprietary JDK6 being shipped by
Sun, notably with some of the Free replacements for the encumbrances
being completely different code from the proprietary version
in JDK6.

In the java overlay, we currently have an ebuild for IcedTea6 1.2.
This matches the name of the upstream project and version.  There
is also a live build in experimental, and 1.3 is likely to become
available in the next few weeks.  On IRC, some have expressed dislike
for this naming, preferring including terms like 'OpenJDK' and the
cooked build on which it is based.  This is further confused by the
binary builds in Fedora, Debian and Ubuntu now being called 'OpenJDK'.
 This isn't because they just felt like changing the name.
Use of the 'OpenJDK' name is subject to the OpenJDK trademark license
and requires fulfilling certain conditions, including the codebase
being almost completely based on the tree from Sun.

In Gentoo, we work at the source level in general, whereas the
approach of Fedora, Debian and Ubuntu is from one of a binary package.
With OpenJDK and IcedTea, this presents some differences.  The most
prominent is the use of the trademark license.  With a binary
build, the distro developer knows what is in the binary and whether it
qualifies to be called OpenJDK.  The source from which these binaries
are built is still IcedTea6, as may be demonstrated via executing
'java -version'.  With Gentoo, the presence of USE flags and local
settings
mean that we don't know what will result from the ebuild in binary
form. Some builds will be roughly equivalent to the builds in Fedora,
Debian
and Ubuntu, but some may not.  There is functionality in IcedTea, such
as the ability to use CACAO instead of HotSpot, that would mean
the resulting binary does not qualify to be called OpenJDK (such
packages are called cacao-oj6 in Debian and Ubuntu for example).

More practically, we need to be able to track bugs and issues with
ebuilds easily. IcedTea6 1.2 is a known quantity. It uses a certain
cooked build of OpenJDK6 and a certain set of patches.  Moving to a
new build drop is non-trivial requiring patches to be added, dropped
or updated.  IcedTea is more than simply a build harness and the
resulting binary is different from what would be obtained from a pure
OpenJDK source base.  In addition to the OpenJDK source tree, it
includes (as of the current Mercurial tree):

* 81 patches to the source code, including one to allow the build to
run with ecj + GNU Classpath.  Not all of these are applied
to every build, but the majority are.
* Gary Benson's zero assembler support which allows OpenJDK to be used
on ppc, ppc64, arm, mips, m68k, ia64, etc.
* Webstart support in the form of NetX
* Plugin support from gcjwebplugin (IcedTea plugin is coming soon with
LiveConnect support)
* Support for building using the CACAO VM instead of HotSpot (again
for other architecture support)
* Gary Benson's platform-independent JIT called Shark based on LLVM
* VisualVM support
* Javascript support via Rhino

  In addition, there is always the option that someone may wish to
provide an ebuild that just builds the OpenJDK
or OpenJDK6 tree.  Note that one thing already being considered among
the IcedTea developers is how to add the IcedTea version to
the java -version output because the lack of this is causing issues
with reporting bugs.  By naming our ebuilds using the IcedTea schema,
and directly relating to our upstream codebase, we have already solved
this issue in Gentoo.  Naming it OpenJDK would not reflect
what is being installed or the upstream being used.

For those who hate the aboration of having the version number as part
of the package name, note that this is intended to be short-lived.
As the discussion above implies, the OpenJDK6 tree is a stop-gap,
created to fulfill the need for a complete implementation now.
When 1.7 is released, IcedTea will become the primary JDK again and
IcedTea6 will cease development.  At present, most of the
maintenance work for OpenJDK6/IcedTea6 is being done by the IcedTea
hackers; Sun only have Joe Darcy working on this. Their
concentration is on 1.7.  Thus, we should really note our appreciation
of this work by naming the IcedTea project rather than
hiding it under the name OpenJDK.

When IcedTea6 hits the main tree, most of this will become irrelevant
anyway, as the virtual dependency should just do the right
thing and pull in IcedTea6.  I don't intend IcedTea or any of the live
builds to go into the main tree, but are there for those who wish to
experiment.

Hope that clarifies things,
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8