Re: gnu.java.nio.FileChannelImpl

[Michael Koch]

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/