Misleading Javadoc for Path.toURI()

Christian Schlichtherle christian at schlichtherle.de
Thu May 26 08:52:35 PDT 2011


Hi Alan,

 

the Javadoc for Path.toUri() says that the returned URI is hierarchical.
However, this is not necessarily true. I used the following demo to verify
this with TrueZIP 7.1 and the ZipFileSystemProvider from the JDK 7 demos.

 

<code>

import de.schlichtherle.truezip.file.*;

import java.io.*;

import java.net.URI;

import java.nio.file.*;

import java.util.*;

 

public class Test {

    public static void main(String[] args) throws IOException {

        PrintStream out = System.out;

 

        TFile file = new TFile("archive.jar/META-INF/MANIFEST.MF");

        file.createNewFile();

        TFile.umount();

 

        out.println(file.toFsPath());

        out.println(file.toPath());

        out.println(file);

 

        Map<String, ?> env = Collections.emptyMap();

        URI uri = file.getInnerArchive().toURI();

        FileSystem fs = FileSystems.newFileSystem(uri, env);

        Path path = fs.getPath(file.getInnerEntryName());

 

        out.println(path);

        out.println(path.toUri());

    }

}

</code>

 

Running this program outputs the following for me:

 

<output>

jar:file:/C:/Users/christian/Documents/NetBeansProjects/truezip-fsp-jse7/arc
hive.jar!/META-INF/MANIFEST.MF

archive.jar\META-INF\MANIFEST.MF

archive.jar\META-INF\MANIFEST.MF

META-INF/MANIFEST.MF

jar:file:///C:/Users/christian/Documents/NetBeansProjects/truezip-fsp-jse7/a
rchive.jar!/META-INF/MANIFEST.MF

</output>

 

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.

 

Best regards,

Christian

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


More information about the nio-discuss mailing list