I think that is in fact what Mark was suggesting and I think this is definitely a good idea. There are a lot of VMs that don't (want to) use JNI for their "native" methods. Having all native methods in the VM* classes makes this much easier.
I was suggesting that. Sorry for not responding earlier. But having you and Patrik affirm that it is a good thing is more valuable then when 'the guy without his own VM' says it :)
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.
It even helps for code maintenance, and you can then use automated tools to look for missing native implementations in the VM very easily. Same applies to class library.
Hopefully we won't do it at the expense of elegance 'and' efficiency, but I agree that sometimes it won't be possible to achieve both. As our Hacker Guide puts it (even though it leaves out elegance):
When you write code for Classpath, write with three things in
mind, and in the following order: portability, robustness, and
efficiency.
If efficiency breaks portability or robustness, then don't do it
the efficient way. If robustness breaks portability, then
bye-bye robust code. Of course, as a programmer you would
probably like to find sneaky ways to get around the issue so
that your code can be all three ...
And I am also sure that there might be better designs then the grouping
of platform dependent methods into their own VMInterface classes for
some VMs.
I habve yet to find time for it, but I should within the upcoming months. I see the possibility to use m4-like macros so that most VMs would share VM*.java implementations, but be able to apply changes to them without disrupting other VMs.
Etienne
-- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
