From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25673 invoked by alias); 8 May 2009 00:22:27 -0000 Received: (qmail 25663 invoked by uid 22791); 8 May 2009 00:22:25 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_12,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f224.google.com (HELO mail-bw0-f224.google.com) (209.85.218.224) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 May 2009 00:22:17 +0000 Received: by bwz24 with SMTP id 24so1090270bwz.8 for ; Thu, 07 May 2009 17:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.102.15 with SMTP id e15mr2908011bko.196.1241742133817; Thu, 07 May 2009 17:22:13 -0700 (PDT) In-Reply-To: <1241718259.3769.36.camel@fedora.wildebeest.org> References: <17c6771e0905070828n441803edx6cf6291ed9b01e5e@mail.gmail.com> <1241713494.3769.6.camel@fedora.wildebeest.org> <4A030CE7.6050309@redhat.com> <1241716199.3769.16.camel@fedora.wildebeest.org> <4A031855.3030505@redhat.com> <1241718259.3769.36.camel@fedora.wildebeest.org> Date: Fri, 08 May 2009 00:22:00 -0000 Message-ID: <17c6771e0905071722m4ac664fft7293bf91b78df804@mail.gmail.com> Subject: Re: GCJ with OpenJDK Java API instead of GNU Classpath From: Andrew John Hughes To: Mark Wielaard Cc: Andrew Haley , Chris Gray , bmckinlay , svferro , java Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00031.txt.bz2 2009/5/7 Mark Wielaard : > 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 ac= cess >> >>> 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 softwar= e. >> > 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. =C2=A0It just means that >> you don't want to do it, and you don't think that the gcj >> community should do it. =C2=A0It'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. =C2=A0What evidence do you have of progra= ms >> 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 > > --=20 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