AW: Misleading Javadoc for Path.toURI()

[Christian Schlichtherle]

I wasn't aware that there is an update to RFC 2396?! I am relying on this
RFC because TrueZIP's FsPath implementation (conceptually similar to Path)
is also using the "legacy JAR URI syntax".

 

BTW: I'm not sure I like the fact that Path is tied to FileSystem. It's a
constraint when implementing a FileSystemProvider like TrueZIP where such
boundaries do not exist. Now I have to create dummy FileSystem objects just
to please the API.

 

Regards,

Christian

 

Von: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Gesendet: Donnerstag, 26. Mai 2011 20:59
An: christian at schlichtherle.de
Cc: nio-discuss at openjdk.java.net
Betreff: Re: Misleading Javadoc for Path.toURI()

 

Christian Schlichtherle wrote: 

:

 

One thing which concerns me is that I could find no method to get to a Path
referring to archive.jar/META-INF/MANIFEST.MF without creating a file system
first. Any attempt resulted in an exception. Looking at the code, I figured
this may be only an issue with the implementation of ZipFileSystemProvider.
It also tries to mount the archive file upon the call to
FileSystems.newFileSystem() which is redundant because I am not doing any
I/O here. I had to add the TFile.createNewFile() and TFile.umount() calls
just because of this.

A Path is associated with a FileSystem and so the FileSystem must exist. For
what you are doing, can you keep a cache of FileSystem instances to reduce
the continuous opening/closing of zip files?

I'll need to get back you on the JAR URL syntax issue. The original zip
provider used the "zip" scheme but was changed to the legacy JAR URL syntax
to provide compatibility with JarURLConnection. Unfortunately that syntax is
problematic, or will be if/when URI is updated to the most recent RFCs.

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110526/5bb443de/attachment.html