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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
