harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Tue, 16 Aug 2005 08:00:33 GMT
Hi Weldon,

Weldon Washburn wrote:
> 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

Agreed.  Geir has been refining the Authorized Contributor Questionnaire
[1] document and it looks pretty good to me.  I'd just like to see the
list of components in Part II tweaked to maximize participation in
Harmony while still ensuring the protection from previous exposure.  But
that's a different subject.

[1]  http://incubator.apache.org/harmony/auth_cont_quest.html

>>>>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
> 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.

Good -- hopefully we can be in a position where simple bridging code
maps between the interfaces; then we can mix and match.

>>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).
> 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.

Probably best if we don't call the Harmony code "classpath" though ;-)
Let's simply call it the ClassLibrary/VM interface.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message