Re: gnu.java.nio.FileChannelImpl

[Ewout Prangsma]

So here is my suggestions. - Rename gnu.java.nio.FileChannelImpl to VMFileChannel (placed in vm/reference) - Rename gnu.java.nio.FileLockImpl to VMFileLock (placed in vm/reference) - Add a new VMFileChannelImpl in java.io (placed in vm/reference) that constains 1. a static method FileChannel open(...) the default implementation is to return a new VMFileChannel(...), but vm's can decide to implement it themselves. 2. a static method FileChannel getOut(), FileChannel getIn(), FileChannel getErr() to replace the in, out, err fields of FileChannelImpl - Add a new VMChannels to java.nio.channels (placed in vm/reference) that implements the native methods of Channels (newInputStream, newOutputStream) - Replace the FileChannelImpl instanceof check in Channels by a FileChannel instanceof check. - Replace the FileChannelImpl.in/out/err reference in java.io.FileDescriptor with VMFileChannelImpl.getIn()/getOut()/getErr(). Placing into vm/reference is generally good but not into the java.* packages. I think the way Jeroen pointed out is our way. I'm fine with using the security framework, in fact that is very good, as long as i'm able to use classpath (hopefully out of the box) without the need for native methods.  Since i'm writing a java os all in java i want to implement java.io & java.nio.* directly on top of our filesystem api and having to rewrite parts of classpath because they are using natives is not something i want to do, especially if there are good ways to avoid the natives using the VMxyz classes. Ewout Michael

_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath