[Top][All Lists]

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

Re: VMInterface addition: Make native library names part of VMInterface

From: Bryce McKinlay
Subject: Re: VMInterface addition: Make native library names part of VMInterface
Date: Mon, 27 Oct 2003 14:57:26 +1300

On Oct 27, 2003, at 2:01 PM, Mark Wielaard wrote:

On Mon, 2003-10-27 at 13:15, Bryce McKinlay wrote:
On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote:
I suggest to move the System.loadLibrary("javaio") calls completely
into the VMInterface classes. We want to have a system where (at least
for lang, net, io and util) we have the "native" calls in the
VMInterface classes. We then provide a reference implementation that
implements this with JNI using our own libraries.

I don't think that is a good idea. IMO the VMInterface should define
the interface to a particular VM, not the entire native interface for
all classes. Things like and will typically have the
same native interface across different VMs.

Could you explain that a bit more? I don't understand why you think
having the loadLibrary() call in the same (VMInterface) class as the
native methods is not a good idea. Or do you mean that having
loadLibrary() calls at all is a bad idea because VMs should just link
against our default jni libraries (at least for lang/net/io/util)?

Sorry, I think I misunderstood your message. I thought you were suggesting moving all the native methods (eg for IO classes) to separate VM* classes.

What I was suggesting in my previous message was consolidating the javaio, javanet, javanio native libraries (and perhaps others) into a single .so. In that case, we could just load this library once during initialization, with just one System.loadLibrary() call.

The VMInterface classes define all methods that a particular VM might
want to/has to implement to get a complete working core libraries

Right. I think there is a distinction, however, between what the VM must implement to operate with classpath - ie core VM classes like Class, Object, Throwable, Thread; and portable classes which happen to have native methods, such as and The later are just normal classes with native methods, the implementations of which are typically be portable across different VMs. So, they a system/platform interface rather than the VM interface. To put it another way, just because a method is native doesn't mean it interfaces with the VM.



reply via email to

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