Re: [arch] VM/Classlibrary Interface (take 2)

[Weldon Washburn <we...@gmail.com>]

On 7/12/05, Tim Ellison <t....@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.

Re: [arch] VM/Classlibrary Interface (take 2)

[Tim Ellison <t....@gmail.com>]

Hi Weldon,

Weldon Washburn wrote:
> On 7/12/05, Tim Ellison <t....@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
>>>>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.

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

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.

Re: [arch] VM/Classlibrary Interface (take 2)

["Geir Magnusson Jr." <ge...@apache.org>]

On Aug 15, 2005, at 11:48 AM, Weldon Washburn wrote:

> On 7/12/05, Tim Ellison <t....@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

Indeed.  I have another rev to propose - it will invert the  
questionnaire to

a) make it clear that people will be able to work on *anything* for  
which there isn't a problem due to previous exposure, rather than  
only be able to work on things they initially declared

b) ensure there's an included "resolution procedure" for cases where  
previous exposure is resolvable

c) Make the compontent list a bit finer grained so previous exposure  
to X doesn't keep you from working on things unrelated solely because  
of our bucketing.
>

geir

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