JAR file URLs were, prior to Java 9, used by some APIs to identify specific files in the runtime image. These URLs contain a jar:file: prefix with two paths—one to the jar and one to the specific resource file within the jar. Here is the syntax for the pre-Java 9 JAR URL:

jar:file:<path-to-jar>!<path-to-file-in-jar>

With the advent of Java's modular system, containers will house resource files instead of individual JARs. The new syntax for accessing resource files is as follows:

jrt:/<module-name>/<path-to-file-in-module>

A new URL schema, jrt, is now in place for naming resources within a runtime image. These resources include classes and modules. The new schema allows for the identification of a resource without introducing a security risk to the runtime image. This increased security ensures that the runtime image's form and structure remain concealed. The following is the new schema:

jrt:/[$MODULE[/$PATH]]

Interestingly, a jrt URL's structure determines its meaning, suggesting that the structure can take one of several forms. Here are three examples of different jrt URL structures:

• jrt:/$MODULE/$PATH: This structure provides access to the resource file, identified with the $PATH parameter, within the module specified with the $MODULE parameter
• jrt:/$MODULE: This structure provides reference to all resource files within the module specified with the $MODULE parameter
• jrt:/: This structure provides reference to all resource files in the runtime image

If you have preexisting code that uses URL instances returned by APIs, you should not have any problems. On the other hand, if your code is dependent on the jar URL structure, you will have problems.