Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

["Andrew John Hughes" <gnu_andrew@member.fsf.org>]

2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Fri, Sep 12, 2008 at 12:35 AM, Andrew John Hughes
> <gnu_andrew@member.fsf.org> wrote:
>> 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).
>
> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
> source build even from the sun tree.
>

Maybe that's being a bit over cautious, but the problem generally is
Sun thought of this with binary distribution in mind, not source.
As with any legal agreement, the best solution is to consult a lawyer.
I'm not one.

> BTW i'm on AMD64 which has very poor support from the sun java
> codebase. are there any plans to add support for the harmony VM?
>

What 'poor support'? IcedTea6 works fine for me here on amd64.  Feel free
to package Harmony, but I don't see how that will solve your problems, given
it doesn't yet have a complete implementation of even 1.5.

> - robert
>
>

-- 
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