NIO Filesystem API

[Alan Bateman]

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 
package name.

-Alan.