The jdeps tool analyzes the dependencies of a given set of JAR files. Suppose, for example, that you want to modularize JUnit 4. Run
jdeps -s junit-4.12.jar hamcrest-core-1.3.jar
The -s flag generates a summary output:
hamcrest-core-1.3.jar -> java.base
junit-4.12.jar -> hamcrest-core-1.3.jar
junit-4.12.jar -> java.base
junit-4.12.jar -> java.management
That tells you the module graph:
If you omit the -s flag, you get the module summary followed by a mapping from packages to required packages and modules. If you add the -v flag, the listing maps classes to required packages and modules.
The –generate-modute-info option produces module-info files for each analyzed module:
jdeps –generate-modute-info /tmp/junit junit-4.12.jar hamcrest-core-1.3.jar
Use the jtink tool to produce an application that executes without a separate Java runtime. The resulting image is much smaller than the entire JDK. You specify the modules that you want to have included and an output directory.
jtink –module-path com.horstmann.greet.jar:v2ch09.exportedpkg.jar:$JAVA_HOME/jmods \
–add-modules v2ch09.exportedpkg –output /tmp/hello
The output directory has a subdirectory bin with a java executable. If you run
bin/java -m v2ch09.exportedpkg
the main method of the module’s main class is invoked.
The point of jlink is that it bundles up the minimal set of modules required to run the application. You can list them all:
bin/java –list-modules
In this example, the output is
v2ch09.exportedpkg
com.horstmann.greet
java.base@9
All modules are included in a runtime image file lib/modules. On my computer, that file is 23MB, whereas the runtime image of all JDK modules takes up 181MB. The entire application takes up 45MB, less than 10% of the JDK which is 486MB.
This can be the basis of a useful tool for packaging applications. You would still need to produce file sets for multiple platforms and launch scripts for the application.
Finally, the jmod tool builds and inspects the module files that are included with the JDK. When you look into the jmods directory inside the JDK, you will find a file with extension jmod for each module. There is no longer a rt.jar file.
Like JAR files, these files contain class files. In addition, they can hold native code libraries, commands, header files, configuration files, and legal notices. The JMOD files use the ZIP format. You can inspect their contents with any ZIP tool.
Unlike JAR files, JMOD files are only useful for linking—that is, for producing runtime images. There is no need for you to produce JMOD files unless you also want to bundle binary files such as native code libraries with your modules.
This brings us to the end of the chapter on the Java Platform Module System. The following chapter covers another important topic: security. Security has always been a core feature of the Java platform. As the world in which we live and compute gets more dangerous, a thorough understanding of Java security will be of increasing importance for many developers.
Source: Horstmann Cay S. (2019), Core Java. Volume II – Advanced Features, Pearson; 11th edition.