1 |
On Fri, Sep 12, 2008 at 12:35 AM, Andrew John Hughes |
2 |
<gnu_andrew@××××××××××.org> wrote: |
3 |
> It seems there has been some confusion over the naming of the ebuilds |
4 |
> for OpenJDK/IcedTea |
5 |
> support within Gentoo, so, at Petteri's request, this e-mail aims to |
6 |
> clear things up and hopefully |
7 |
> alleviate some of these issues. |
8 |
> |
9 |
> Understanding the naming really involves understanding the development |
10 |
> of OpenJDK so far. |
11 |
> The release of Sun's reference implementation of the Java SE platform |
12 |
> was completed in May 2007, |
13 |
> and this codebase was known as OpenJDK. This basically represents the |
14 |
> current state of what |
15 |
> will eventually become Java 1.7 or JDK7, the contents of which are |
16 |
> still unknown as there is no |
17 |
> JSR for this platform as yet. The platform specification does not |
18 |
> include the plugin or webstart support, |
19 |
> so, given the state of this code, it was not included. On initial |
20 |
> release, about 4% of the code base |
21 |
> was also missing, having to be replaced by proprietary binary plugs |
22 |
> from one of the proprietary Sun JDKs. |
23 |
> Thus, although we were much closer to a complete Free JDK, there were |
24 |
> three major issues remaining: |
25 |
> |
26 |
> * The released code was for 1.7, not the 1.6 release actually in use, |
27 |
> and it couldn't be certified as Java(TM). |
28 |
> * The code couldn't be built Freely, preventing its use in Fedora, |
29 |
> Debian and Ubuntu. |
30 |
> * The plugin and webstart support which users would expect from a JDK |
31 |
> were missing. |
32 |
> |
33 |
> Two of these issues were quickly solved by hackers at Red Hat who |
34 |
> started the IcedTea project. This provided |
35 |
> a way of building OpenJDK using existing Free Java runtimes such as |
36 |
> GCJ and provided replacements for the |
37 |
> encumbrances using code from GNU Classpath. gcjwebplugin was also |
38 |
> modified to provide plugin support |
39 |
> against Sun's applet code rather than GNU Classpath's, and the |
40 |
> existing NetX project continued its development |
41 |
> as part of IcedTea, providing webstart support. Resulting binaries |
42 |
> shipped as a package named 'icedtea' in |
43 |
> Fedora Core 8. |
44 |
> |
45 |
> Over time, OpenJDK and IcedTea continued to develop. Sun provided |
46 |
> replacements for some of the encumbrances, |
47 |
> mainly in the area of Java2D such as font and renderer support, and |
48 |
> cryptography. IcedTea was kept up to date with |
49 |
> each new OpenJDK cooked build, by modification of the existing |
50 |
> patches. This continues today, with the latest |
51 |
> IcedTea release being 1.7. Ebuilds for both 1.7 and the live |
52 |
> Mercurial repository are held in java-experimental, as |
53 |
> they provide a snapshot of 1.7 development rather than a completed JDK |
54 |
> aimed at the user. |
55 |
> |
56 |
> In early 2008, Sun began the OpenJDK6 project to provide a Free 1.6 |
57 |
> implementation, and allowed external developers |
58 |
> (notably Red Hat) access to the Java Compatibility Kit (JCK) so that |
59 |
> the resulting builds could be demonstrated to be |
60 |
> compatible with the existing proprietary JDK6 builds provided by Sun. |
61 |
> OpenJDK6 was created, not from the proprietary |
62 |
> JDK6 tree (which would require another legal review on the epic scale |
63 |
> already undertaken for the JDK7 code), but by |
64 |
> taking the OpenJDK tree and removing new features added by Sun developers. |
65 |
> |
66 |
> The issues with building the code and the encumbrances remained with |
67 |
> OpenJDK6 so a matching IcedTea6 tree was launched |
68 |
> to provide the same level of support to the new code base. It is a |
69 |
> build of IcedTea6 from Fedora that recently passed the JCK, |
70 |
> finally proving that a certifiable Free JDK implementation can exist. |
71 |
> Getting to this point was non-trivial, as the base of OpenJDK |
72 |
> and then additional patching by IcedTea meant that the codebase was |
73 |
> quite distinct from the proprietary JDK6 being shipped by |
74 |
> Sun, notably with some of the Free replacements for the encumbrances |
75 |
> being completely different code from the proprietary version |
76 |
> in JDK6. |
77 |
> |
78 |
> In the java overlay, we currently have an ebuild for IcedTea6 1.2. |
79 |
> This matches the name of the upstream project and version. There |
80 |
> is also a live build in experimental, and 1.3 is likely to become |
81 |
> available in the next few weeks. On IRC, some have expressed dislike |
82 |
> for this naming, preferring including terms like 'OpenJDK' and the |
83 |
> cooked build on which it is based. This is further confused by the |
84 |
> binary builds in Fedora, Debian and Ubuntu now being called 'OpenJDK'. |
85 |
> This isn't because they just felt like changing the name. |
86 |
> Use of the 'OpenJDK' name is subject to the OpenJDK trademark license |
87 |
> and requires fulfilling certain conditions, including the codebase |
88 |
> being almost completely based on the tree from Sun. |
89 |
> |
90 |
> In Gentoo, we work at the source level in general, whereas the |
91 |
> approach of Fedora, Debian and Ubuntu is from one of a binary package. |
92 |
> With OpenJDK and IcedTea, this presents some differences. The most |
93 |
> prominent is the use of the trademark license. With a binary |
94 |
> build, the distro developer knows what is in the binary and whether it |
95 |
> qualifies to be called OpenJDK. The source from which these binaries |
96 |
> are built is still IcedTea6, as may be demonstrated via executing |
97 |
> 'java -version'. With Gentoo, the presence of USE flags and local |
98 |
> settings |
99 |
> mean that we don't know what will result from the ebuild in binary |
100 |
> form. Some builds will be roughly equivalent to the builds in Fedora, |
101 |
> Debian |
102 |
> and Ubuntu, but some may not. There is functionality in IcedTea, such |
103 |
> as the ability to use CACAO instead of HotSpot, that would mean |
104 |
> the resulting binary does not qualify to be called OpenJDK (such |
105 |
> packages are called cacao-oj6 in Debian and Ubuntu for example). |
106 |
|
107 |
AIUI and IMNSHO *NO* local build from source qualifies. gentoo |
108 |
*SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY* |
109 |
source build even from the sun tree. |
110 |
|
111 |
BTW i'm on AMD64 which has very poor support from the sun java |
112 |
codebase. are there any plans to add support for the harmony VM? |
113 |
|
114 |
- robert |