harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [jchevm] porting harmony classlib to JCHEVM
Date Sun, 12 Feb 2006 16:11:37 GMT

Archie Cobbs wrote:
> Geir Magnusson Jr wrote:

>> TO me, the ideal is to have a very clear demarcation of what is the 
>> Harmony Classlibrary VM interface.
>> So I'd see
>>    Harmony VM Interface
>> --------------------------
>>     Harmony/Classpath Adapter
>> --------------------------
>>           JCHEVM
>> Is this what you mean?
> Yes.. that's the basic near term idea... (although technically if
> the adapter is written in Java (as we've discussed) then the Harmony
> VM interface is not really a VM interface).
> However I think ideally Classlib's API should be implemented to be equal
> Classpath's API. That may sound strange so let me try to explain why.
> The state of things now is that the VM API defined by Classlib
> is, well, not very well defined :-)

That's not actually true.  We may be missing documentation or something, 
but the Harmony Classlib VM API is a well-tested production API used by 
IBM in their commercial VM offerings.

Hard to argue with that.

That's why the IBM J9 VM that was offered for evaluation purposes just 

> Compare Classlib's Thread.java:
>   trunk/modules/kernel/src/main/java/java/lang/Thread.java
> with these files from Classpath:
> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup

> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup

> Note every method in Classlib's Thread.java is: "return null". On the other
> hand, Classpath's API is much more complete and fully developed,
> race conditions have been analyzed and handled, SecurityManager 
> implications
> have been taken into account, etc. To get Classlib to the same level,
> you'd have to duplicate a whole bunch of (at times very tricky and subtle)
> work -- not only implementing the API, but figuring out what the right API
> is -- that's already been figured out over several years in Classpath.

Ok, I'm not sure what you are referring to.  I know that our VM API is 
production tested on a certified, complete stack.  I'm not sure where 
Classpath has been used in anger yet.

> In short there is lots of unimplemented stuff remaining in Classlib's
> existing API. From a simple argument of expediency, not to mention the
> benefits for debugging previously mentioned, adopting the "already baked"
> Classpath API makes lots of sense.

We might be missing information from IBM on this.  Tim?


View raw message