harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 15 Aug 2005 15:48:32 GMT
On 7/12/05, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 
> Geir Magnusson Jr. wrote:
> >
> > On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
> >
> >> Recently, within IBM, we have been defining the interface between  IBM's
> >> class library and the J9 VM.  We deliberately haven't looked at the  GNU
> >> Classpath/VM interface specification.

A few of us at Intel have also done something similar.  That is, we
created a simple, easy to understand Classpath/VM interface.  We also
did not look at GNU Classpath because of its license.  Hopefully
Harmony licensing issues will get resolved soon so that actual code
containing interfaces can be donated to Apache.  This will make
pulling the best ideas from each version of  VM/Classlib interface
into Apache Harmony much easier

> >> The principal goals are to enable the class libraries to be hosted on
> >> different versions of a virtual machine, and potentially different
> >> virtual machines, without sacrificing performance or introducing
> >> complexity.  

Yes these are the correct goals and it is fairly straight forward to
achieve them.  I connected GNU Classpath to ORP several years back. 
My experience indicates that moving between Harmony Class Classpath
and GNU Classpath should not be that much engineering effort.  In
other words, it's not really worth debating.

> As I said before, there  are other VM-specific classes that are entirely
> the responsibility of the VM developer (e.g. Class, Thread, etc.) and
> these are covered by regular Java API specifications.
> 
> A few classes are predominantly common (i.e. reusable) code.  VM
> developers can choose to either implement the entire class, or pick up
> the common code and implement one or two methods to complete them (e.g.
> AccessController, and String).
> 
> Regards,
> Tim
> 

This basically matches our experience in the interface between the VM
and the classpath.  Again, this interface is one probably one of the
easiest interfaces to change in a modular JVM.  The idea of a generic
common code implementation that can be replaced by a vm specific
implementation is classic software engineering practice.  It's a good
idea, not new and should be used in the Classpath/VM interface.

Mime
View raw message