Re: VMInterface addition: Make native library names part of VMInterface
Hi, On Sat, 2003-10-25 at 19:43, Dalibor Topic wrote: One of the things I keep stumbling over whenever I merge code from Classpath into Kaffe is the different native library names. Would it be possible to separate those out into their own VMInterface class and use references instead? I'd prefer something like System.loadLibrary(VMNativeLibraries.IO); to what we have now, System.loadLibrary(javaio); 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. This will be a bit more work since we still have a few classes that do use native methods which don't have a VMInterface counterpart, but it is the cleanest solution in the long run. One thing that isn't split yet is java.io File and FileDescriptor. But Anthony Green already had a proposal for splitting that up on the libgcj mailinglist (he calls the VMInterface classes, Platform classes, but the idea is the same). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
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 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
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 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
VMInterface addition: Make native library names part of VMInterface
Hi all, One of the things I keep stumbling over whenever I merge code from Classpath into Kaffe is the different native library names. Would it be possible to separate those out into their own VMInterface class and use references instead? I'd prefer something like System.loadLibrary(VMNativeLibraries.IO); to what we have now, System.loadLibrary(javaio); where library names are hardcoded in each class that needs to use them. Beside preventing errors the compiler can't catch, like misspelling a library name, it would make the code slightly cleaner in my opinion, as it would replace a hardcoded constant with a single occurence. If everyone agrees, I'd be happy to provide a patch, and an implementation of the VMNativeLibraries class with the current library names. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
On Oct 26, 2003, at 6:43 AM, Dalibor Topic wrote: One of the things I keep stumbling over whenever I merge code from Classpath into Kaffe is the different native library names. Would it be possible to separate those out into their own VMInterface class and use references instead? I'd prefer something like System.loadLibrary(VMNativeLibraries.IO); How about having less native libraries? Does it really make sense to have, for example, separate native libs for java.net, java.io, and java.nio? I think these ones at least should be merged into one library, which is loaded unconditionally at startup. After all, virtually all desktop java apps use some kind of I/O. This way we can get rid of the static initializer System.loadLibrary() calls all over the place, something that could be prone to bugs if someone forgets to include one somewhere. It would simplify the number of files needed to deploy classpath, make for less places that VM implementors need to customize, and probably improve performance as System.loadLibrary can be slowish. The AWT libs, however, should probably remain separate due to the existence of multiple toolkits and such. Regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
