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

[Mark Wielaard]

Hi,

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)?

The VMInterface classes define all methods that a particular VM might
want to/has to implement to get a complete working core libraries
implementation. We try to provide default implementations whenever
possible in the VMInterface classes. A particular VM/Classpath system is
then free to override/reimplement those VMInterface classes to work with
their internals and system libraries, or to get more optimal performance
then the generic implementations can provide.

For VMs that actually use the tradition JNI based native methods we
provide implementations that work with the native methods in those
VMInterface classes. But VMs that don't use JNI or don't even have a
concept of native methods can provide their own VMInterface classes.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part