AW: TrueZIP 7.2-beta-1 with NIO.2 FileSystemProvider

[Alan Bateman]

Christian Schlichtherle wrote:
>
> Hi Alan,
>
>  
>
> I found some minor quirks in the NIO.2 API. I wonder if it isn't too 
> late to discuss API changes anyway but AFAIK the JSR 203 is not yet 
> final?!
>
>  
>
> 1.       FileSystem.getSeparator() should be Path.getSeparator(): 
> After all the, the separator is part of the addressing scheme, not the 
> file system. For example, when wirting a "copy constructor" which 
> accepts another Path instance as a parameter I had to write 
> path.toString().replace(path.getFileSystem().getSeparator(), 
> SEPARATOR)) rather than the more natural 
> path.toString().replace(path.getSeparator(), SEPARATOR)).
>
The FileSystem getSeparator method gives you the separator for all Paths 
that are associated with the FileSystem. It might be strange to have it 
as a property of the Path as that leads to the possibility of Paths 
associated with the same FileSystem having different separators. The 
need to use the separator is significantly reduced in this API related 
to java.io.File (getPath uses varargs for example). If I understand 
correctly then you are actually converting a Path associated with one 
provider to a different Path, in which case an alternative is to 
iterator over the name elements and use resolve to combine.

> 2.       Files.createFile(Path, FileAttribute<?>...) uses 
> FileSystemProvider.newByteChannel() rather than 
> FileSystemProvider.newOutputStream(). If Path is a TPath and the 
> addressed entry is an archive entry, this would require the TrueZIP 
> Kernel to create a cache entry for the archive entry so that you could 
> do random I/O. However, you're just closing the channel immediately. 
> This results in the most expensive way to create a new archive entry 
> in TrueZIP.
>
This is just an implementation choice as newOutputStream(CREATE) and 
newByteChannel(CREATE,WRITE) both create the file. However, point taken, 
if a provider implementation treats these differently and has to prepare 
for random access if newByteChannel is called then it may be less 
efficient. This is easily changed (but not for 7 as it is way too late 
to change anything).


> 3.       Path.getFileName() returns a Path rather than just a String. 
> Well, that's strange -- just consider Path a = Paths.get("foo", 
> "bar"); Path b = a.getFileName(); Now what is supposed to happen if I 
> provide these two objects to the Files class. Will I get the same 
> results? I could argue that this would be desirable because after all 
> the two objects are addressing the same file system entity, just with 
> different labels. However, the WindowsPath implementation does not act 
> like this. The Javadoc for Path.getFileName() does not specify this. I 
> think this could get avoided if Path.getFileName() were just returning 
> a String.
>
It returns a Path so that it can be used with other APIs and also has a 
useful side effect that it preserves the platform representation. As 
specified, operations on relative paths are resolved against the current 
directory so if you access "bar" then it will access bar in the current 
directory. For this case this would be no different to creating a Path 
with getPath("bar") and uses it to access a file.


> 4.       Why are all these I/O methods like newByteChannel(), 
> newInputStream() and newOutputStream() in FileSystemProvider? I think 
> FileSystem would be a better match.
>
Users of the API are supposed to use the java.nio.file package with the 
I/O operations delegating to the appropriate provider (implementations 
of FileSystemProvider). We deliberately did not delegate to FileSystem 
as that would clutter the API (so yes, a bit more work for provider 
implementation but they are expected to be few).

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110610/3f35ba58/attachment-0001.html