NIO Filesystem API
Alan.Bateman at Sun.COM
Mon May 26 10:55:46 PDT 2008
David M. Lloyd wrote:
> It's probably a bit late in the game to request this... but... is
> there any chance that you could consider locating all the filesystem
> stuff in a "javax.filesystems" package heirarchy, as opposed to the
> current "java.nio.filesystems"? The reason is that it seems to be
> mostly, if not completely, self-contained (with respect to the other
> NIO stuff), and it would certainly improve adoption of the new
> FileSystem API if backport implementations would be allowed (which,
> unless I'm mistaken, is much more difficult from a licensing
> perspective when the package in question is located in the "java" space).
> Also, the filesystems API has little to do with "NIO", which up until
> now has been concerned primarily with channels, selectors, buffers,
> and transcoding of buffers.
> What do you think?
The package name is java.nio.file and we don't have any plans to move
from that. There are dependencies in that package on new classes that
we've added to the channels package so it isn't as self-contained as it
might seem (Path#newSeekableByteChannel and
FileSystemProvider#newAsynchronousFileChannel come to mind).
That said, there is some interest in "back-porting" the file system part
of the API so that it can be used with jdk6. Carl may wish to say more
about this. Unfortunately any "back-port" does require choosing a
More information about the nio-dev