Geir Magnusson Jr wrote:
I like your idea of zero mods to JCHEVM. I will attempt to localize
all mods to Classlibrary's Kernel Classes. Maybe this set of modified
Kernel Classes could be used by any VM that runs GNU Classpath.
I assume you're talking about making a "glue layer" that the standard
Harmony Classlibrary can work with?
Yes..
will try some experiments with java class name space to see if we can
create wrappers that satisfy all the stakeholders.
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 :-)
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.
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.
For example: if there's more than one Harmony VM, you'd have to have a
different version of the complicated adapter "glue" for each one.
Instead, why not write the glue once, include it as part of Classlib,
and make the "VM interface" really be a native interface, instead of a
big "grey area". Plus there's already a working example of what the glue
should look like to base it on.
There's also this important principle lurking here, which has been learned
over the years in Classpath: if there's a choice between implementing
something in Java or forcing the VM to implement it, it's almost always
preferable to implement it in Java. Java is much easier to debug, and you
only have to debug it once - not N times for each of N VM implementations.
FYI, the Classpath Java/VM API is defined by the files in this subtree:
http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/?root=classpath
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
