Re: JNI/CNI Revisited

[Tom Tromey]

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

Aaron> Looking at native methods used to implement FileDescriptor,
Aaron> FileInputStream, FileOutputStream, and RandomAccessFile (as
Aaron> well as a quick glance at FileChannel in NIO), I pulled
Aaron> together a quick list of potential methods as a sort of
Aaron> provider interface that would do everything but File stuff (so
Aaron> far).

This list looks basically the same as what we've got in the libgcj
FileDescriptor (in some cases your names are clearer).  Nice summary
btw.

You'll want a static initialization function, too, to set
FileDescriptor.in, out, and err.  We could also change System to use
these fields to construct the standard streams, eliminating 3 native
methods in java.lang.VMSystem.

Aaron> I'll attach it below.  Because NIO does a lot of the same stuff
Aaron> as java.io, perhaps sticking this somewhere under the gnu.java
Aaron> hierarchy would allow both java.io and java.nio to share it.

Then you have to do security checks in the code, to avoid malicious
use.  I think one major reason that Mark wanted to put the VM helper
classes in the packages themselves was so that we could just use the
language's access protection mechanisms to avoid security issues.

This may mean some redundancy.  OTOH our native code doesn't have to
precisely map to the Java API -- we could share code at the native
layer.  (In libgcj we accomplish this by circumventing the language
protections in CNI -- default access in Java translates to "public" in
C++.  But ordinary factoring could be used for the Classpath C code.)

Aaron> The immediate problem I see is that gcj uses an instance
Aaron> variable in FileDescriptor called position to track the current
Aaron> file position.

Mark added this recently for performance reasons.  I don't recall what
program prompted him to make this change.

Tom