Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Transfer-Encoding: 7bit
Message-Id: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: harmony-dev@incubator.apache.org
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: [arch] VM/Classlibrary interface
Date: Fri, 27 May 2005 12:33:31 -0400

I think that this is a good topic that many around here have  
experience with and can get involved in.

I think that it's not breaking new ground to say that we'll need a  
standard interface between the VM and the classlibrary, to let people  
integrate the various VMs and class libraries that we'll probably see.

The GNU Classpath project has documented what they need

http://www.gnu.org/software/classpath/docs/vmintegration.html

and this seems to break down to :

1) Some sort of initialization protocol (currently seems to be  
defined in code, and only up to v1.1 - that may be stale docs...)

2) Core classes implemented by the VM for class-library usage
    - standard - things that you expect in java.lang (java.lang.Object)
    - non-standard - extension to java.lang (java.lang.VMObject)

3) VM hooks into the classlib

4) RMI stuff

Clearly this is one model, and one that works because it's been used  
by many integrations.  Now, questions :

0) Standing back from this specific model, can the model be generalized?

1) Are there other models?  How do some of the commercial VMs do it?

2) Are there things that the GNU Classpath model is missing due to  
the version of the API it's implementing?  (I.e. they don't realize  
they need it yet...)

3) I was uncomfortable with extending java.lang.  I understand the  
argument - that as they are package private, the language can be  
depended upon to keep them safe from user code using them rather than  
some security infrastructure.  However, isn't this a bit dangerous in  
terms of standard java.lang changes colliding?


I'd like to drive to a standard interface that we can all agree on,  
and hopefully GNU Classpath will support it.  This would insulate us  
from the ongoing legal discussion surrounding the license, and let us  
get on with using it directly.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org