[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VMInterface addition: Make native library names part ofVMInterface

From: Etienne Gagnon
Subject: Re: VMInterface addition: Make native library names part ofVMInterface
Date: Thu, 06 Nov 2003 09:39:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2

Mark Wielaard wrote:
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
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 M. Gagnon, Ph.D.   

reply via email to

[Prev in Thread] Current Thread [Next in Thread]