Re: [jchevm] porting harmony classlib to JCHEVM

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

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

geir