Re: JNI/CNI Revisited

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <address@hidden> writes:

Jeroen> This allows VMs (such as mine) that don't use an integer as a
Jeroen> file handle, to replace FileDescriptor with a different
Jeroen> implementation, but leave all other i/o classes as is.

Aaron> Can you explain this further?  I'm not clear on the problem,
Aaron> exactly.  In your example, everything is still long.  If you
Aaron> changed your instance variable to an int, I don't know what
Aaron> that buys us.

Aaron> [ ... ]
Aaron> In really offbeat cases, there may be no alternative to but
Aaron> replace FileDescriptor completely.

I think his example code was to show how the reference implementation
would look.  The idea is that the FileDescriptor API would consist of
instance (not static) methods, and in the reference implementation
these would just call the appropriate native (static) methods.  If the
FileDescriptor API is done this way, then it facilitates replacing the
FileDescriptor implementation, because the other classes in java.io
won't have to be changed.

I have a slight preference for this since it lets us make less changes
in libgcj :-).  But really it isn't a major point.  If
FileOutputStream.write(byte) is written:

    return FileDescriptor.nativeWrite(fd.nativeDescriptor, b);

or:

    return fd.write(b);  // Delegates to nativeWrite, like Jeroen's example

... either way a VM implementer could replace FileDescriptor, since
the above doesn't depend on the type of
FileDescriptor.nativeDescriptor.  Still, the latter seems a bit
clearer.

Tom