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