Re: JNI/CNI Revisited

[Aaron M. Renn]

Tom Tromey (address@hidden) wrote:
> 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.

Thanks.  I liked the gcj approach better because it had fewer classes
with native methods.  And a lot of the differences between the two code
sets are of the "six of one, half dozen of the other" variety and I'm
not averse to just adopting the gcj approach in those cases, assuming
it doesn't create too horribly much work :) 
 
> 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.

Right now Classpath just hardcodes these as FD 0, 1, and 2.  Probably
not a good idea.  The nativeInit() method was one I envisioned being
called as part of static initialization a la gcj, and thus it could
set up these values.
 
> 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.

Hmm.  That would be a problem.  And you're right that native code could
easily be shared regardless.  Even now most of the actual Classpath
native methods just delegate to another function that does the real work.
Probably best to keep them in FileDescriptor then.

> 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.

Interesting that it was done for performance reason.  I thought perhaps
it was becuase we could not always guarantee that we could
determine the current file position without tracking it.  I think
Classpath does something like lseek(fd, 0, SEEK_CUR) but this may not
be portable.

-- 
Aaron M. Renn (address@hidden) http://www.urbanophile.com/arenn/