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

[Christian Schlichtherle]

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)).

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.

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.

4.       Why are all these I/O methods like newByteChannel(),
newInputStream() and newOutputStream() in FileSystemProvider? I think
FileSystem would be a better match.

 

Anyway, I guess it's way too late to change anything in the public API. You
would just p*** off too many people. But you could still change the
implementation for point 2 and amend the Javadoc for point 3.

 

Regards,

Christian

 

Von: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Gesendet: Freitag, 10. Juni 2011 16:04
An: christian at schlichtherle.de
Cc: nio-discuss at openjdk.java.net
Betreff: Re: TrueZIP 7.2-beta-1 with NIO.2 FileSystemProvider

 

Christian Schlichtherle wrote: 

Hi everyone,

 

this is a quick note to let you know that I have released a first beta
version of TrueZIP 7.2 to Maven Central.

Good to hear that you've make progress that you've got a first beta
available.

I tried it. Some things work, some things are clearly not implemented but
it's a good start. The main thing that I ran into is that the Path object
returned by FileSystem's getPath doesn't work as expected and you need
construct a de.schlichtherle.truezip.nio.fsp.TPath yourself via the public
constructor. I assume you are working on this as it doesn't be necessary to
import anything from this package to use the API. 

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110610/19a4bb7f/attachment.html