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
|