From: Andrew John Hughes <gnu_andrew@member.fsf.org>
To: Mark Wielaard <mark@klomp.org>
Cc: Andrew Haley <aph@redhat.com>, Chris Gray <chris.gray@kiffer.be>,
bmckinlay <bmckinlay@gmail.com>, svferro <svferro@gmail.com>,
java <java@gcc.gnu.org>
Subject: Re: GCJ with OpenJDK Java API instead of GNU Classpath
Date: Fri, 08 May 2009 00:22:00 -0000 [thread overview]
Message-ID: <17c6771e0905071722m4ac664fft7293bf91b78df804@mail.gmail.com> (raw)
In-Reply-To: <1241718259.3769.36.camel@fedora.wildebeest.org>
2009/5/7 Mark Wielaard <mark@klomp.org>:
> 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
next prev parent reply other threads:[~2009-05-08 0:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 14:31 Chris Gray
2009-05-07 15:29 ` Andrew John Hughes
2009-05-07 16:25 ` Mark Wielaard
2009-05-07 16:32 ` Andrew Haley
2009-05-07 17:10 ` Mark Wielaard
2009-05-07 17:20 ` Andrew Haley
2009-05-07 17:24 ` David Boreham
2009-05-07 17:34 ` Andrew Haley
2009-05-07 17:44 ` Mark Wielaard
2009-05-08 0:22 ` Andrew John Hughes [this message]
2009-05-08 10:13 ` Andrew Haley
2009-05-08 11:00 ` Mark Wielaard
-- strict thread matches above, loose matches on Subject: below --
2009-05-06 20:43 Sal
2009-05-07 9:17 ` Andrew Haley
2009-05-07 11:45 ` Bryce McKinlay
2009-05-07 13:25 ` Andrew John Hughes
2009-05-07 13:43 ` Andrew Haley
2009-05-07 13:50 ` Bryce McKinlay
2009-05-07 20:24 ` Sal
2009-05-08 8:04 ` Robert Schuster
2009-05-08 10:08 ` Andrew Haley
2009-05-07 16:28 ` Mark Wielaard
2009-05-08 13:47 ` Robert Schuster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17c6771e0905071722m4ac664fft7293bf91b78df804@mail.gmail.com \
--to=gnu_andrew@member.fsf.org \
--cc=aph@redhat.com \
--cc=bmckinlay@gmail.com \
--cc=chris.gray@kiffer.be \
--cc=java@gcc.gnu.org \
--cc=mark@klomp.org \
--cc=svferro@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).