Java NIO can't read files from JRT image

When we create Java runtime by jlink it takes all java classes/resources and places them into JRT image file: lib/modules.

Here is basic Maven project resources structure I use:


I'm just trying to read xkcd_en text file. If we look into JRT file, here it is:

>> jimage list /path/to/lib/modules
Module: main

Also I've explicitly opened it in module-info, just in case:

module main {
    opens dict;
    // code omitted

The only way I could read the file is obtaining it as input stream:


public static InputStream getResourceAsStream(String resource) {
    return FileUtils.class.getResourceAsStream(resource);

System.out.println(new BufferedReader(
    new InputStreamReader(getResourceAsStream("/dict/xkcd_en")))


But if I'm trying to get the file URI and read it via Java NIO API, it doesn't work:

public static URL getResourceOrThrow(String resource) {
    URL url = FileUtils.class.getResource(resource);
    return url;

1 - Java NIO can't find the file. But it definitely does exist, otherwise getResource() returns null.

// /main/dict/xkcd_en


Caused by: java.nio.file.NoSuchFileException: /main/dict/xkcd_en
        at java.base/jdk.internal.jrtfs.JrtFileSystem.checkNode(
        at java.base/jdk.internal.jrtfs.JrtFileSystem.getFileContent(
        at java.base/jdk.internal.jrtfs.JrtFileSystem.newInputStream(
        at java.base/jdk.internal.jrtfs.JrtPath.newInputStream(
        at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newInputStream(

2 - The same if you'll use FileSystem directly:

FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/"));
// main/dict/xkcd_en


Caused by: java.nio.file.NoSuchFileException: /main/dict/xkcd_en
    at java.base/jdk.internal.jrtfs.JrtFileSystem.checkNode(

3 - Java NIO doesn't even know what jrt:/ scheme is.


Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 3: jrt:/main/dict/xkcd_en
    at java.base/sun.nio.fs.WindowsPathParser.normalize(
    at java.base/sun.nio.fs.WindowsPathParser.parse(
    at java.base/sun.nio.fs.WindowsPathParser.parse(
    at java.base/sun.nio.fs.WindowsPath.parse(
    at java.base/sun.nio.fs.WindowsFileSystem.getPath(
    at java.base/java.nio.file.Path.of(
    at java.base/java.nio.file.Paths.get(

Here is the specs of JRT FS.

A jrt URL is a hierarchical URI, per RFC 3986, with the syntax


where $MODULE is an optional module name and $PATH, if present, is the path to a specific class or resource file within that module. The meaning of a jrt URL depends upon its structure:

jrt:/$MODULE/$PATH refers to the specific class or resource file named $PATH within the given $MODULE.
jrt:/$MODULE refers to all of the class and resource files in the module $MODULE.
jrt:/ refers to the entire collection of class and resource files stored in the current run-time image.

So obtained path looks ok to me. Where am I wrong?

1 answer

  • answered 2019-01-11 08:41 Slaw

    The part of the spec you quote deals with URLs, not NIO. The two are different mechanisms. A URL simply represents the location; how the real location is resolved depends on the URL protocol. In this case, the form is jrt:/[$MODULE]/[$PATH] and it will search the image and return the proper resource.

    However, when using NIO you are accessing the runtime image as a file system. If you look at JDK-8066492 you'll see the JRT file system was enhanced at one point to add two directories: modules and packages. These directories are directly under the root and their meaning is described in the issue. If you want to access the image as a file system you'll need to take the modules directory into account.

    It's not that NIO can't read files from the JRT image, it's that /main/dict/xkcd_en really does not exist; the real location is /modules/main/dict/xkcd_en.

    According to JDK-8216553 (linked by Alan Bateman in the question comments), the fact Paths.get(/* jrt uri */) returns a non-existent Path is a bug.

    You can see an example of this here.