From dev-return-39966-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Mon Nov 08 15:35:43 2010 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 78344 invoked from network); 8 Nov 2010 15:35:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Nov 2010 15:35:43 -0000 Received: (qmail 479 invoked by uid 500); 8 Nov 2010 15:36:14 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 250 invoked by uid 500); 8 Nov 2010 15:36:12 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 241 invoked by uid 99); 8 Nov 2010 15:36:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 15:36:11 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_MED,SPF_NEUTRAL,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 195.212.17.161 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [195.212.17.161] (HELO mtagate1.de.ibm.com) (195.212.17.161) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 15:36:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id oA8FZhbD005623 for ; Mon, 8 Nov 2010 15:35:43 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA8FZhTN3588312 for ; Mon, 8 Nov 2010 16:35:43 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id oA8FZgFD029399 for ; Mon, 8 Nov 2010 16:35:42 +0100 Received: from anaheim.local (dhcp-9-20-183-160.hursley.ibm.com [9.20.183.160]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id oA8FZgdB029389 for ; Mon, 8 Nov 2010 16:35:42 +0100 Message-Id: <201011081535.oA8FZgdB029389@d12av04.megacenter.de.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3 In-reply-to: <4CCFE67A.8040908@gmail.com> References: <4CC7EE60.2080300@gmail.com> <62342.91.183.51.65.1288556593.squirrel@k-embedded-java.com> <4CCFE67A.8040908@gmail.com> Comments: In-reply-to Tim Ellison message dated "Tue, 02 Nov 2010 10:22:50 +0000." From: Mark Hindess To: dev@harmony.apache.org Subject: Re: [general] Harmony future roadmap Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Nov 2010 15:35:42 +0000 In message <4CCFE67A.8040908@gmail.com>, Tim Ellison writes: > > On 31/Oct/2010 20:23, chris.gray@k-embedded-java.com wrote: > > > > Tim Ellison wrote: > > > > > > I think all options and opinions are open for discussion. We > > > could simply continue with the current goal and encourage the > > > Apache Board to seek the JCK license by whatever means is > > > posible, we could modify our goal and plan to release an > > > uncertified Java SE runtime, or more radically change Harmony's > > > goal away from Java SE. > > > > Previously the situation was that Harmony didn't *want* to pass the > > JCK, Harmony *had* to pass the JCK in order to be able to make a > > release. > > Well, not really. We have always said that Harmony's goal was for a > compatible and compliant implementation of Java SE. Passing the JCK > has a number of advantages, including the ability to demonstrate to > our users that Harmony is 'real' Java. Indeed. Passing the TCK is key to our goal to be "compatible and compliant". We *need* to pass the TCK to meet the goal of being compliant, but we also *want* to pass the TCK as it is a good measure (arguably the best measure) of our being "compatible". Passing the TCK is also important to gaining credibility with some potential users. > > But that was all based on agreements and contracts which have now > > been unequivocally abrogated, so I guess it doesn't matter much any > > more. In which case I think Harmony should turn its back on the JCK > > and instead seek to be as compatible as possible "by whatever means > > is posible". > > I've certainly hear others making that argument too -- that is to > say, continue with the goal of of full Java compatible runtime, and > accept that Harmony won't be certified. Of course, there are other > assurances and rights that come with passing the JCK, and so it would > be interesting to hear the importance that contributors and consumers > of Harmony place on that. A year ago several people were suggesting that we might take a stand and release Harmony. To take one random example: http://www.jroller.com/niclas/entry/oracle_s_java_community_commitment Even ignoring changes since that time, I think this misses the important point that no matter how safe we, the ASF, think we are there is no point making releases that no one (with more to lose?) would risk using. So my problem with taking anything but the "continue with the current goal and encourage the Apache Board to seek the JCK license by whatever means is posible" option is that I believe that the other options I can imagine are rather short on potential users. That said, from a purely technical perspective some of the other options are rather appealing so I'd be happy to be convinced my non-technical conclusions are wrong. Regards, Mark.