> I am also strongly in favor of putting all VM-specific native methods in
> VM* classes, and all library-specific native methods outside of VM* classes.
I suspect the notion of a VM-specific native method vs. a library-specific native method is pretty fuzzy. One example is VMFloat, most VM's would probably view those as library specific, but Jikes RVM wants to think of them as VM-specific because we can do a better job of implementing them in a VM-specific way than the native method does (and we don't want to have to provide our own complete implementation of Float.java just to change a couple methods). But, the native method is VM neutral and works just fine on Jikes RVM, it is just much less efficient for us.
There are also obviously Java methods that are (or can be) VM specific. Some of these have been moved to VM* classes, others have not. I don't think there is an easy solution to this as it is unlikely that a single VMInterface will fit the needs of all VMs perfectly. In some cases (java.lang.ref.* for example), I don't think that it is reasonable for classpath to try to provide an implementation that will actually work unchanged on all VMs. The details of this class are pretty closely tied into the details of the GC system and there is very little code that isn't VM specific.
--dave
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
