On Fri, Sep 12, 2008 at 12:35 AM, 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
> 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,
> 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.
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?