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
