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

[Bryce McKinlay]

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 java.net and java.io 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
> implementation.

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 java.io.File and java.net.PlainSocketImpl. 
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.

Regards,

Bryce