From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14147 invoked by alias); 7 May 2009 16:25:13 -0000 Received: (qmail 14126 invoked by uid 22791); 7 May 2009 16:25:11 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_40 X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (80.101.103.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 May 2009 16:25:05 +0000 Received: from fedora.wildebeest.org ([192.168.1.31]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1M26P1-00020V-1D; Thu, 07 May 2009 18:24:55 +0200 Subject: Re: GCJ with OpenJDK Java API instead of GNU Classpath From: Mark Wielaard To: Andrew John Hughes Cc: Chris Gray , bmckinlay , aph , svferro , java In-Reply-To: <17c6771e0905070828n441803edx6cf6291ed9b01e5e@mail.gmail.com> References: <17c6771e0905070828n441803edx6cf6291ed9b01e5e@mail.gmail.com> Content-Type: text/plain Date: Thu, 07 May 2009 16:25:00 -0000 Message-Id: <1241713494.3769.6.camel@fedora.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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/msg00021.txt.bz2 On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote: > 2009/5/7 Chris Gray : > > > > Quoth Andrew John Hughes: > >> > Huh? I was assuming Java compatibility was the goal. > > > > Compatibility with the non-existent specification for Java 7, or with the > > equally non-existent JCK for Java 7 (for which there is no JSR)? > > > 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. That said, adopting something like jigsaw for the core class library and then having the option to switch modules seems a fine idea. Compatibility is much more about running actually code than some opaque proprietary test suite. Cheers, Mark