Re: Thoughts on 'reference classes'

[Brian Jones]

"Jeroen Frijters" <address@hidden> writes:

> Hi,
> 
> I'm a VM implementer too and I have a few comments. One general
> point is that the current GNU Classpath version is 0.05, this
> suggests that it isn't mature yet so I think VM implementers should
> expect that the VM interface isn't yet stable. BTW, personally I
> think that 0.05 is a way too low number for the current state of
> affairs, but maybe I'm just reading too much into the number ;-)

I don't like it either, but we have this long standing thing of making
1.0 a full 1.1 (+++) release.  Aaron's recent email speaks to this
really well.

> Some random points (all IMHO):
> * I don't mind changes to the Classpath <-> VM interface, if they
> improve the situation. I'd love to hear what other VM implementers have
> to say about this, but I agree with Archie sometimes there is too much
> inertia.

Some degree of control needs to be exercised over the reference
interface or nothing would ever work with Classpath CVS and JVM
implementors might not enjoy tracking a rapidly moving target.
  
> * The use of native code should be limited. Preferrably to primitive
> operations that cannot be performed from within Java

I agree.  Most JVMs are going to run Java code much faster than
marshaling/unmarshaling to native code and back.

> And finally, here is an example of how some of the requirements can be
> very different: My VM (http://ikvm.net) is built on top of .NET, so I
> want to use the .NET class libraries for I/O, but the current
> java.io.FileDescriptor uses an int as the native handle, while I want
> the use a reference to a .NET stream object.

This is an assumption that isn't even valid under all flavors of UNIX;
think 64 bit file systems for example.  Perhaps Aaron will be able to
tackle this.

> This is why I really like the native methods to live in a VMxxx class,
> because that way I can choose to implement the method inline and still
> retain the ability to keep using the latest Classpath code (except for
> the vm/reference classes) as long as the interface between the xxx and
> VMxxx classes remains stable.

To make it more clear, perhaps things that are "native" that we
provide implementations for should be moved to some other type of
interface scheme such as NativeXXX instead of VMXXX.  Putting these
things in VMXXX makes it terribly unclear what needs to be implemented
by a JVM and what is "optional".  Opinions?

Brian
-- 
Brian Jones <address@hidden>