Re: VMInterface addition: Make native library names part ofVMInterface

[Patrik Reali]

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/