Bug ID: JDK-8216553 JrtFIleSystemProvider getPath(URI) omits /modules element from file path

Type: Bug
Component: tools
Sub-Component: jlink
Affected Version: 13

Priority: P3
Status: Closed
Resolution: Fixed

Submitted: 2019-01-11
Updated: 2019-06-14
Resolved: 2019-05-29

JDK 13	JDK 14
13 b23Fixed	14Fixed

Consider the following:

        var uri = URI.create("jrt:/java.base/module-info.class");
        var path = Path.of(uri);
        assertTrue(Files.exists(path));

This fails because the file path returned by JrtFIleSystemProvider getPath(URI) is "/java.base/module-info.class", it should be "/modules/java.base/module-info.class".

If this bug is fixed then the following round trip should also work:

        // check round-trip
        var jrtfs = FileSystems.getFileSystem(URI.create("jrt:/"));
        assertTrue(Files.exists(jrtfs.getPath(path.toString())));

You cannot reopen a bug once a changeset has been pushed for it. A new "redo" bug will need to be filed to apply this fix again.
29-05-2019
Broke build
28-05-2019
I think toUri has to fail if the absolute path doesn't start with "/modules". I suspect it may have to fail if the path contains a ".." element too. The getPath(URI) change looks right. It could also reject the URI if the resulting path has a ".." element.
24-05-2019
Tried the following change: diff -r 98ed47cd114a src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java --- a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.javaWed May 22 21:50:16 2019 -0400 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.javaFri May 24 16:40:26 2019 +0530 @@ -193,7 +193,7 @@ if (path == null \|\| path.charAt(0) != '/') { throw new IllegalArgumentException("Invalid path component"); } - return getTheFileSystem().getPath(path); + return getTheFileSystem().getPath("/modules" + path); } private FileSystem getTheFileSystem() { diff -r 98ed47cd114a src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java --- a/src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Wed May 22 21:50:16 2019 -0400 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Fri May 24 16:40:26 2019 +0530 @@ -25,6 +25,7 @@ package jdk.internal.jrtfs; import java.io.File; +import java.io.IOError; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; @@ -170,7 +171,15 @@ @Override public final URI toUri() { try { - return new URI("jrt", toAbsolutePath().path, null); + String p = toAbsolutePath().path; + if (p.startsWith("/packages")) { + throw new IOError(new RuntimeException(p + " cannot be represented as URI")); + } + + if (p.startsWith("/modules")) { + p = p.equals("/modules")? "/" : p.substring("/modules".length()); + } + return new URI("jrt", p, null); } catch (URISyntaxException ex) { throw new AssertionError(ex); } There is one test failure with this though. Existing test makes assumptions (Basic.java) makes assumptions about URI-Path conversion (and vice versa). [~alanb] Does the above change look okay for you? Thanks.
24-05-2019
One related issue is the question on the URI representation for a file that is not in the /modules tree. It might be that the jrt URL format needs to be extend to support resources or the URL format continues to only support resources in modules and so the links in /packages cannot be represented (toUri will throw an exception, as it is allowed to do).
12-01-2019
The issue came up here: https://stackoverflow.com/questions/54140750/java-nio-cant-read-files-from-jrt-image
11-01-2019

Relates :	JDK-8224946 - jrtfs URI to Path and Path to URI conversions are wrong
Relates :	JDK-8224908 - Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path