Jeroen wrote: > Bryce McKinlay wrote: > > 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. > > I think that is in fact what Mark was suggesting and I think this is > definitely a good idea. There are a lot of VMs that don't (want to) use > JNI for their "native" methods. Having all native methods in the VM* > classes makes this much easier. >
I agree with this. Moving all the native methods in the VM* classes would be easier for the VM implementors, because it is easier to document or find out which methods must be provided (a grep native *.java doesn't help much!). > > 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. > > This assumption is not true for some VMs. My VM (IKVM) has no native > methods and I'm pretty sure this is also true for JAOS and maybe others. > How I'm going to explain this...? Well Jaos uses the Oberon language to provide the native methods (native == written in a language other than java), but doesn't go through JNI: both languages have the same object model with garbage collection, so no object pinning and similar stuff is needed, and the jitter compiles the byte-code using the same data layout and calling convention, such that the generated code is identical for both languages. It is the task of the linker to patch the native implementation entry points into the method tables, and from that point java can call oberon and oberon can call java. Moving all the native methods to a separate class would make my job simpler: I would replace the complete class with an oberon class instead of having to merge them. And because the interface is stable, I would be able to get rid of a lot of bootstrap code, which checks every time whether the methods and fields have changed. > > 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. > > The VM* classes don't mean "interfaces with the VM", but are a way for > VM implementers to easily replace their implementation. (The idea being > that the interface between the non-VM and VM classes is fairly stable). > Well, the VM classes are part of the VM interface, which is much broader. I agree that they will be fairly stable, thus making the port simpler to maintain. -Patrik -------- Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath