Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 17035 invoked from network); 7 Jun 2005 03:38:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Jun 2005 03:38:49 -0000 Received: (qmail 42728 invoked by uid 500); 7 Jun 2005 03:38:44 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 42662 invoked by uid 500); 7 Jun 2005 03:38:43 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 42634 invoked by uid 99); 7 Jun 2005 03:38:43 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from smtp3.su.se (HELO smtp3.su.se) (130.237.93.228) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 06 Jun 2005 20:38:42 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 3181237EAC for ; Tue, 7 Jun 2005 05:38:36 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14463-03-31 for ; Tue, 7 Jun 2005 05:38:35 +0200 (CEST) Received: from mail3.physto.se (syslx09.physto.se [130.242.128.36]) by smtp3.su.se (Postfix) with ESMTP id D244A37E72 for ; Tue, 7 Jun 2005 05:38:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail3.physto.se (Postfix) with ESMTP id A3666C30E4 for ; Tue, 7 Jun 2005 05:38:35 +0200 (CEST) Received: from mail3.physto.se ([127.0.0.1]) by localhost (syslx09.physto.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20782-01 for ; Tue, 7 Jun 2005 05:38:34 +0200 (CEST) Received: from qcplx01.physto.se (qcplx01.physto.se [130.242.128.121]) by mail3.physto.se (Postfix) with ESMTP id DAE3FC30DC for ; Tue, 7 Jun 2005 05:38:34 +0200 (CEST) Subject: Re: The Classpath VM interface. (Please read) From: Sven de Marothy To: harmony-dev@incubator.apache.org In-Reply-To: <42A5083C.5070302@realityforge.org> References: <1118082599.20853.36.camel@qcplx01.physto.se> <42A5083C.5070302@realityforge.org> Content-Type: text/plain Date: Tue, 07 Jun 2005 05:38:34 +0200 Message-Id: <1118115514.2898.33.camel@qcplx01.physto.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 (2.0.3-0.mozer.1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at physto.se X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.4 tagged_above=-99 required=7 tests=ALL_TRUSTED X-Spam-Level: X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Tue, 2005-06-07 at 12:36 +1000, Peter Donald wrote: > [A] Suns rt.jar and derivatives (such as IBMs) class libraries > [B] GNU Classpaths class libraries [..] > In an ideal world Harmony VM would be able to use either [A] or [B] > with a small adapter layer. Much like MMTk can be used in multiple VMs > with a small adapter layer. If you have downloaded Harmony, which intends to be a full JDK including a VM and class library, why would you want to be able to use that with the class library from a different JDK? Disregarding the illegality of distributing such a combo, there is no good practical reason for wanting that either. > It seems unlikely that either [A] or [B] is going to invest the time in > trying to develop a common VM interface because they are not interested in > facilitating reuse of the alternative. Java specifications are created by the JCP and not Sun. This issue should be raised there before jumping to conclusions like that. And as a Classpath developer (but speaking for myself), I feel that we would be quite happy to use a common VM interface, if there was a such a specification. Unless of course if it was so extremely bad, that all the Classpath-using VMs refused to use it. Which I think is unlikely. > So it is probably going to be up to a third party like Harmony to > investigate a common VM layer. Harmony is not a third party. We're all in this together. However, Harmony can help solve this. Apache has a good standing in the JCP, and thus better chances than most for getting this specified. > I am not sure it is going to be possible either technically or politically but it > is an interesting idea and worth trying. The politics are easier when you work from an open mind. /Sven