Re: GCJ with OpenJDK Java API instead of GNU Classpath

2009/5/7 Mark Wielaard <[email protected]>:
> Hi Andrew,
>
> On Thu, 2009-05-07 at 18:20 +0100, Andrew Haley wrote:
>> Mark Wielaard wrote:
>> > On Thu, 2009-05-07 at 17:31 +0100, Andrew Haley wrote:
>> >> Mark Wielaard wrote:
>> >>> On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
>> >>>>>
>> >>>> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
>> >>>> http://openjdk.java.net/groups/conformance/
>> >>> I don't think that is a serious option, that is only available under NDA
>> >>> and only granted to people who sign an SCA with Sun and even then access
>> >>> is only granted if Sun feels like it.
>> >> So why is it not a serious option?
>> >
>> > Because it isn't a thing that a free software community can do
>> > collaboratively in the open and involves requiring proprietary software.
>> > Maybe a third party could do it for their own binary builds, but I don't
>> > see how we as a community can recommend it, nor would I want to
>> > recommend it myself.
>>
>> That doesn't make it not a serious option.  It just means that
>> you don't want to do it, and you don't think that the gcj
>> community should do it.  It's still a serious option.
>
> I think we agree. Let just s/serious//. It is an option. Just not one
> that is IMHO feasible nor desirable for a free software project.
>
>> > :) Since the JCK is under NDA that claim is not verifiable. But you
>> > could say that the JCK assumes one particular interpretation yeah.
>> > Still, if a secret test suite would say things should work one way, but
>> > actual programs expect things differently I would go with not breaking
>> > existing stuff.
>>
>> This is FUD, plain and simple.  What evidence do you have of programs
>> that require Java behaviour at odds with the JCK?
>
> That is exactly my point. And you cannot prove the other way, that the
> JCK tests behavior that is actually specified and not just a test for an
> implementation detail. So we would be raising some smoke screen with no
> way for the end user or our fellow hackers to do anything with except to
> just trust those behind the NDA. They won't even be able to tell if it
> is something that just happens on the particular setup that runs the TCK
> or not.
>

The clause in the OpenJCK6 license which restricts its use to projects
'substantially derived' from OpenJDK (judgement of which is made
secretly by Sun as part of the decision process) makes me very dubious
about it being a test of the specification.  It's very clearly a test
of compatibility with the reference implementation provided by Sun and
only JDKs derived from this reference implementation have ever passed
it.  There are places where the specification is unclear and the TCK
will resolve them in favour of how Sun chose to interpret the
specification.  I'm not saying this is a bad thing, but let's also not
fool ourselves that this is all there is to being able to run Java
applications.  For me, keeping the tests a secret and only allowing
them to be run against approved JDKs just makes me distrust the whole
process.  We know from our work on GNU Classpath and GCJ that many
applications can be run without passing the TCK or even having a
complete implementation of every API imaginable.  Similarly, we know
from working on IcedTea that there are issues above and beyond the
bounds of TCK testing.

> Cheers,
>
> Mark
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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