RE: Thoughts on 'reference classes'

[Jeroen Frijters]

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 ;-)

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.

* The use of native code should be limited. Preferrably to primitive operations that cannot be performed from within Java

* I really like Mark's approach of introducing the VMxxx classes. The interface between xxx and VMxxx should be well defined and we should try to minimize changes too it, but we also have to recognize that this is a hard problem. Not all VMs have the same requirements/trade-offs.

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. Similarly, sometimes I implement native methods in C#, but other times I use Java code to directly call the .NET class library. Here is a fragment from my java.lang.Thread:

public static Thread currentThread()
{
  Thread javaThread = (Thread)system.threading.Thread.GetData(localDataStoreSlot);
  if(javaThread == null)
  {
    // threads created outside of Java always run in the root thread group
    javaThread = new Thread(ThreadGroup.root, system.threading.Thread.get_CurrentThread());
    system.threading.Thread.SetData(localDataStoreSlot, javaThread);
  }
  return javaThread;
}

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.

Regards,
Jeroen