Am Freitag, 26. November 2004 10:04 schrieb 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.
No, VM* classes cannot be avoided for your goals, but these classes can be located into gnu.* namespace (inside vm/reference). Michael -- Homepage: http://www.worldforge.org/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
