JNI/CNI Revisited

[Aaron M. Renn]

I want to throw out a couple random thoughts to stimulate discussion.  I
see this as two separate issues:

1.  What native methods ought to exist (it is different in CP and GCJ today)
2.  How to implement those methods (JNI or CNI)

Like Tom, I'm skeptical of the machine translation of CNI to JNI and I'm
not sure that trying to have a single native implementation is even
desirable.  I see this as something almost akin to the VM interface.  There
is a defined interface and a set of "reference" classes (ie, the Classpath
Unix JNI libraries).  But other JVM implementors or people porting to
other platforms might need to implement native libraries specific to
their platform.  The Red Hat guys do this because their CNI library is
super-fast compared to JNI.

This is sort of brain storming, but what I'm thinking is that we should
try to get agreement on the set of native methods, their signatures,
etc. and forget about trying to merge CNI and JNI implementations.  Let
the GCJ build process build its own native libraries and Classpath 
supply its own Unix type JNI libraries.  (A win32 JVM might have its
own libraries - much as there seem to be Unix and Win versions of CNI
within gcc)

Looking at native methods used to implement FileDescriptor, FileInputStream,
FileOutputStream, and RandomAccessFile (as well as a quick glance at
FileChannel in NIO), I pulled together a quick list of potential 
methods as a sort of provider interface that would do everything but
File stuff (so far).  I'll attach it below.  Because NIO does a lot
of the same stuff as java.io, perhaps sticking this somewhere under
the gnu.java hierarchy would allow both java.io and java.nio to share
it.  Because I pass the FD as the first parameter (to avoid gratutious
field lookups in JNI), these could probably all be static methods.

Comments?

Needed for java.io (except File)
--------------------------------
  void nativeInit(); // For any required initialization

  void nativeSync(long fd) throws SyncFailedException
  boolean nativeValid(long fd)
  long nativeOpen(String path, int mode) throws IOException // returns fd
  long nativeClose(long fd) throws IOException
  long nativeWrite(long fd, int byte) throws IOException
  long nativeWrite(long fd, byte[] buf, int offset, int len) throws IOException
  long nativeGetLength(long fd) throws IOException
  void nativeSetLength(long fd, long len) throws IOException
  long nativeSeek(long fd, long offset, int whence, eof_trunc) throws IOE
  long nativeGetFilePointer(long fd) throws IOException
  int nativeRead(long fd) throws IOException
  long nativeRead(long fd, byte[] buf, long offset, long len) throws 
IOException  long nativeAvailable(long fd) throws IOException

Needed for NIO FileChannel
--------------------------
  long nativeLock(long fd, long pos, long size, boolean shared) throws IOE
  long nativeUnlock(long fd) throws IOException
  long nativeMmap(???????????)
  long nativeMunmap(???????????)
  long nativeTruncate(long fd, long pos) throws IOException ??

The immediate problem I see is that gcj uses an instance variable in
FileDescriptor called position to track the current file position. 
If we are able to wipe that, or assume you'll store all of your state
using the fd handle, then that is solved.

If these sat in a gnu.java class, we could probably drop the native prefix
and still avoid confusion.

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