Gentoo Archives: gentoo-java

From: Andrew John Hughes <gnu_andrew@××××××××××.org>
To: Robert Burrell Donkin <robertburrelldonkin@×××××.com>
Cc: gentoo-java@l.g.o
Subject: Re: [gentoo-java] OpenJDK, IcedTea and Package Naming
Date: Sun, 14 Sep 2008 16:01:33
Message-Id: 17c6771e0809140901s55ef3bccj1d2e787d1ec313b9@mail.gmail.com
In Reply to: Re: [gentoo-java] OpenJDK, IcedTea and Package Naming by Robert Burrell Donkin
1 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@×××××.com>:
2 > On Sun, Sep 14, 2008 at 3:26 PM, Andrew John Hughes
3 > <gnu_andrew@××××××××××.org> wrote:
4 >> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@×××××.com>:
5 >>> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
6 >>> <gnu_andrew@××××××××××.org> wrote:
7 >>>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@×××××.com>:
8 >>>
9 >>> <snip>
10 >>>
11 >>>>> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
12 >>>>> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
13 >>>>> source build even from the sun tree.
14 >>>>>
15 >>>>
16 >>>> Maybe that's being a bit over cautious,
17 >>>
18 >>> i agree that sun is unlikely to sue any users over java ATM but
19 >>> trademarks must be defended or cease to exist. sooner or later sun
20 >>> will have to either lose the java trademark or act against
21 >>> unauthorised users.
22 >>>
23 >>
24 >> I wasn't talking about the Java trademark, I was talking about the OpenJDK
25 >> trademark. Use of the Java trademark requires passing the
26 >> certification process,
27 >> and this isn't possible for a source build. Only binaries can pass
28 >> the TCK and thus
29 >> be certified.
30 >
31 > yes
32 >
33 > thanks for clarifying
34 >
35 >>>> but the problem generally is
36 >>>> Sun thought of this with binary distribution in mind, not source.
37 >>>
38 >>> the JCP is set up to manage binaries, not source. IMO this is the
39 >>> fatal flaw in this system. (i'll avoid going OT by repeating the
40 >>> argument again here.)
41 >>>
42 >>
43 >> Yes, the JCP still needs work, being centered around proprietary
44 >> binary distribution for the most part.
45 >
46 > the binary distributions only rule is a consequence of the closed TCK.
47 > the TCK is closed to ensure a revenue stream for the spec leader.
48 >
49 > i'll be interested to see whether the JCP survives. sun broke the
50 > basic premise over the harmony TCK (all participants whether open
51 > source or not hold contracts with sun who acts as an independent
52 > judge). given that most open source projects can't afford to sue sun,
53 > the legal framework needs extensive revision. it would be cleaner for
54 > the JCP to issue a license covering any works that pass an open source
55 > TCK for everything except branding rights including the mutual patent
56 > grants. branding rights are only really required for commercial binary
57 > implementations so an additional secret TCK and payment could be
58 > required to unlock those.
59 >
60 >>>> As with any legal agreement, the best solution is to consult a lawyer.
61 >>>> I'm not one.
62 >>>
63 >>> does gentoo have a agreement with sun?
64 >>> if so, is it available on line?
65 >>> if not, what agreement is being relyed on?
66 >>>
67 >>
68 >> Not as far as I know, but other than naming and trademarks, OpenJDK is just
69 >> like any other FOSS project.
70 >
71 > trademarks are the important point (bit like firefox)
72 >
73 >>>>> BTW i'm on AMD64 which has very poor support from the sun java
74 >>>>> codebase. are there any plans to add support for the harmony VM?
75 >>>>>
76 >>>>
77 >>>> What 'poor support'? IcedTea6 works fine for me here on amd64.
78 >>>
79 >>> eclipse and sun don't play well. however, i haven't tried switching to
80 >>> the iced tea build on gentoo so maybe i'll give that a try next time.
81 >>>
82 >>>> Feel free to package Harmony, but I don't see how that will solve your problems,
83 >>>
84 >>> harmony runs eclipse fine. every couple of months when gentoo changes
85 >>> something, i have to devote a couple of hours fixing stuff so that
86 >>> eclipse works or else switch to harmony until everything's fixed.
87 >>>
88 >>
89 >> That's interesting. I don't know anything about the proprietary Sun
90 >> builds on amd64, I've
91 >> never used them. But I also don't run Eclipse. Have you filled
92 >> appropriate bugs? Certainly try IcedTea and, if you get failures, report them to our bug
93 >> database at
94 >> http://icedtea.classpath.org/bugzilla.
95 >
96 > cool
97 >
98 >>>> given it doesn't yet have a complete implementation of even 1.5.
99 >>>
100 >>> if sun had honoured it's agreement to allow access to the TCK by open
101 >>> source projects, then harmony (and the free JVMs) would have had
102 >>> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
103 >>> well by now. this is a political issue, not a code one.
104 >>>
105 >>
106 >> I seriously doubt that, given it took OpenJDK a year to pass the 1.6
107 >> TCK, despite
108 >> being based on a codebase, the majority of which has passed as part of
109 >> the proprietary work.
110 >
111 > you'd be surprised :-)
112 >
113 > at least one major corporation has taken a derived work based on
114 > harmony codebase through the TCK
115 >
116
117 Is this the TreeMap? If so, it's one class which they modified heavily
118 themselves
119 so that it worked as part of 1.6.
120
121 > and ask yourself if google would have based andriod on harmony unless
122 > it worked...
123 >
124
125 I didn't say it didn't work, I said it wasnt' likely to pass the TCK
126 without a lot of work.
127 You could of course link the Harmony class library up to HotSpot,
128 apply for the OpenJDK6 TCK
129 to certify that combination and prove me wrong.
130
131 > - robert
132 >
133 >
134
135
136
137 --
138 Andrew :-)
139
140 Support Free Java!
141 Contribute to GNU Classpath and the OpenJDK
142 http://www.gnu.org/software/classpath
143 http://openjdk.java.net
144
145 PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
146 Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Replies

Subject Author
Re: [gentoo-java] OpenJDK, IcedTea and Package Naming Robert Burrell Donkin <robertburrelldonkin@×××××.com>