In JRE-9/lib
directory (at least on Windows), there is a new file called modules
whose size is about 107 MB. Is it possible to extract that file or maybe list java modules within it?
I can see that a new tool called jmod
is available at jdk-9/bin/jmod.exe
, but that is for reading .jmod
files which is located at jdk-9/jmods
and it cannot read the file modules
.
Defining the Java 9 module. A module is a collection of code, data, and resources. It is a set of related packages and types (classes, abstract classes, interfaces, and more) with code, data files, and some static resources.
The jmod tool is intended for modules that have native libraries or other configuration files or for modules that you intend to link, with the jlink tool, to a runtime image. The JMOD file format let's you aggregate files other than . class files, metadata, and resources.
The module descriptor ( module-info. java ) needs to be located in the src/main/java directory. Maven will set up javac to use the appropriate module source path.
Adding Modules to the Unnamed Module For example, when we try to run Java 8 programs as-is with Java 9 compiler we may need to add modules. In general, the option to add the named modules to the default set of root modules is –add-modules <module>(,<module>)* where <module> is a module name.
The modules
file is a container file. It's internal to the JDK and the format is not documented (it may change at any time). For troubleshooting purposes, the jimage
tool in the bin directory can be used to list or extract the contents.
The runtime resources are handled in a backwards compatible way. E.g. when you did
URL url = Object.class.getResource("Object.class"); System.out.println(url);
in the past, you usually got something like
jar:file:/path-to-jre/lib/rt.jar!/java/lang/Object.class
Running the same under Java 9 will give you
jrt:/java.base/java/lang/Object.class
instead. In either case, you can open a FileSystem
on it to inspect the other available resources (since Java 7). While the ZipFileSystem
had to be created via FileSystems.newFileSystem
first, Java 9’s file system is even already open for use:
private static void readMyOwnJRE() throws IOException { try { Path p = Paths.get(URI.create("jrt:/")).resolve("/modules"); System.out.println("My own JRE's modules:"); Files.list(p).forEach(m -> System.out.println(m.getFileName())); System.out.println(); } catch(FileSystemNotFoundException ex) { System.out.println("Could not read my modules (perhaps not Java 9?)."); } }
If you are running under a different JRE than the one you want to inspect, you have to load the appropriate file system implementation manually first, but this opens the possibility to inspect a Java 9 installation even from a Java 8 JRE:
public static void readOtherJRE(Path pathToJRE) throws IOException { Path p = pathToJRE.resolve("lib").resolve("jrt-fs.jar"); if(Files.exists(p)) { try(URLClassLoader loader = new URLClassLoader(new URL[]{ p.toUri().toURL() }); FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), Collections.emptyMap(), loader)) { System.out.println("Modules of "+pathToJRE); Files.list(fs.getPath("/modules")).forEach(System.out::println); System.out.println(); } } }
Once you have a file system (or a Path
into it), you can use all standard functions of, e.g. Files
to inspect or extract/copy the data, though the right term would be “to store an equivalent class file” in a different file system, as the runtime image’s representation doesn’t have to be a class file at all.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With