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 ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
