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
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13 JDK 14
13 b23Fixed 14Fixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8224908 :  
Description
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())));


Comments
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