- Introduction
- Understanding the Java Platform Module System
- From Monolithic to Modular: The Evolution of the JDK
- Continuing the Evolution: Modular JDK in JDK 11 and Beyond
- Implementing Modular Services with JDK 17
- JAR Hell Versioning Problem and Jigsaw Layers
- Open Services Gateway Initiative
- Introduction to Jdeps, Jlink, Jdeprscan, and Jmod
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Introduction to Jdeps, Jlink, Jdeprscan, and Jmod
This section covers four tools that aid in the development and deployment of modular applications: jdeps, jlink, jdeprscan, and jmod. Each of these tools serves a unique purpose in the process of building, analyzing, and deploying Java applications.
Jdeps
Jdeps is a tool that facilitates analysis of the dependencies of Java classes or packages. It’s particularly useful when you’re trying to create a module file for JAR files. With jdeps, you can create various filters using regular expressions (regex); a regular expression is a sequence of characters that forms a search pattern. Here’s how you can use jdeps on the loadLayers class:
$ jdeps mods/com.codekaram.brickhouse/com/codekaram/brickhouse/loadLayers.class loadLayers.class -> java.base loadLayers.class -> not found com.codekaram.brickhouse -> com.codekaram.brickhouse.spi not found com.codekaram.brickhouse -> java.io java.base com.codekaram.brickhouse -> java.lang java.base com.codekaram.brickhouse -> java.lang.invoke java.base com.codekaram.brickhouse -> java.lang.module java.base com.codekaram.brickhouse -> java.nio.file java.base com.codekaram.brickhouse -> java.util java.base com.codekaram.brickhouse -> java.util.function java.base com.codekaram.brickhouse -> java.util.stream java.base
The preceding command has the same effect as passing the option -verbose:package to jdeps. The -verbose option by itself will list all the dependencies:
$ jdeps -v mods/com.codekaram.brickhouse/com/codekaram/brickhouse/loadLayers.class loadLayers.class -> java.base loadLayers.class -> not found com.codekaram.brickhouse.loadLayers -> com.codekaram.brickhouse.spi.BricksProvider not found com.codekaram.brickhouse.loadLayers -> java.io.PrintStream java.base com.codekaram.brickhouse.loadLayers -> java.lang.Class java.base com.codekaram.brickhouse.loadLayers -> java.lang.ClassLoader java.base com.codekaram.brickhouse.loadLayers -> java.lang.ModuleLayer java.base com.codekaram.brickhouse.loadLayers -> java.lang.NoSuchMethodException java.base com.codekaram.brickhouse.loadLayers -> java.lang.Object java.base com.codekaram.brickhouse.loadLayers -> java.lang.String java.base com.codekaram.brickhouse.loadLayers -> java.lang.System java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.CallSite java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.LambdaMetafactory java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.MethodHandle java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.MethodHandles java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.MethodHandles$Lookup java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.MethodType java.base com.codekaram.brickhouse.loadLayers -> java.lang.invoke.StringConcatFactory java.base com.codekaram.brickhouse.loadLayers -> java.lang.module.Configuration java.base com.codekaram.brickhouse.loadLayers -> java.lang.module.ModuleFinder java.base com.codekaram.brickhouse.loadLayers -> java.nio.file.Path java.base com.codekaram.brickhouse.loadLayers -> java.nio.file.Paths java.base com.codekaram.brickhouse.loadLayers -> java.util.Arrays java.base com.codekaram.brickhouse.loadLayers -> java.util.Collection java.base com.codekaram.brickhouse.loadLayers -> java.util.ServiceLoader java.base com.codekaram.brickhouse.loadLayers -> java.util.Set java.base com.codekaram.brickhouse.loadLayers -> java.util.Spliterator java.base com.codekaram.brickhouse.loadLayers -> java.util.function.Consumer java.base com.codekaram.brickhouse.loadLayers -> java.util.function.Function java.base com.codekaram.brickhouse.loadLayers -> java.util.function.IntConsumer java.base com.codekaram.brickhouse.loadLayers -> java.util.function.Predicate java.base com.codekaram.brickhouse.loadLayers -> java.util.stream.IntStream java.base com.codekaram.brickhouse.loadLayers -> java.util.stream.Stream java.base com.codekaram.brickhouse.loadLayers -> java.util.stream.StreamSupport java.base
Jdeprscan
Jdeprscan is a tool that analyzes the usage of deprecated APIs in modules. Deprecated APIs are older APIs that the Java community has replaced with newer ones. These older APIs are still supported but are marked for removal in future releases. Jdeprscan helps developers maintain their code by suggesting alternative solutions to these deprecated APIs, aiding them in transitioning to newer, supported APIs.
Here’s how you can use jdeprscan on the com.codekaram.brickhouse module:
$ jdeprscan --for-removal mods/com.codekaram.brickhouse No deprecated API marked for removal found.
In this example, jdeprscan is used to scan the com.codekaram.brickhouse module for deprecated APIs that are marked for removal. The output indicates that no such deprecated APIs are found.
You can also use --list to see all deprecated APIs in a module:
$ jdeprscan --list mods/com.codekaram.brickhouse No deprecated API found.
In this case, no deprecated APIs are found in the com.codekaram.brickhouse module.
Jmod
Jmod is a tool used to create, describe, and list JMOD files. JMOD files are an alternative to JAR files for packaging modular Java applications, which offer additional features such as native code and configuration files. These files can be used for distribution or to create custom runtime images with jlink.
Here’s how you can use jmod to create a JMOD file for the brickhouse example. Let’s first compile and package the module specific to this example:
$ javac --module-source-path src -d build/modules $(find src -name "*.java") $ jmod create --class-path build/modules/com.codekaram.brickhouse com.codekaram.brickhouse.jmod
Here, the jmod create command is used to create a JMOD file named com.codekaram.brickhouse.jmod from the com.codekaram.brickhouse module located in the build/modules directory. You can then use the jmod describe command to display information about the JMOD file:
$ jmod describe com.codekaram.brickhouse.jmod
This command will output the module descriptor and any additional information about the JMOD file.
Additionally, you can use the jmod list command to display the contents of the created JMOD file:
$ jmod list com.codekaram.brickhouse.jmod com/codekaram/brickhouse/ com/codekaram/brickhouse/loadLayers.class com/codekaram/brickhouse/loadLayers$1.class …
The output lists the contents of the com.codekaram.brickhouse.jmod file, showing the package structure and class files.
By using jmod to create JMOD files, describe their contents, and list their individual files, you can gain a better understanding of your modular application’s structure and streamline the process of creating custom runtime images with jlink.
Jlink
Jlink is a tool that helps link modules and their transitive dependencies to create custom modular runtime images. These custom images can be packaged and deployed without needing the entire Java Runtime Environment (JRE), which makes your application lighter and faster to start.
To use the jlink command, this tool needs to be added to your path. First, ensure that the $JAVA_HOME/bin is in the path. Next, type jlink on the command line:
$ jlink Error: --module-path must be specified Usage: jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...] Use --help for a list of possible options
Here’s how you can use jlink for the code shown in “Implementing Modular Services with JDK 17”:
$ jlink --module-path $JAVA_HOME/jmods:build/modules --add-modules com.example.builder --output consumer.services --bind-services
A few notes on this example:
The command includes a directory called $JAVA_HOME/jmods in the module-path. This directory contains the java.base.jmod needed for all application modules.
Because the module is a consumer of services, it’s necessary to link the service providers (and their dependencies). Hence, the –bind-services option is used.
The runtime image will be available in the consumer.services directory as shown here:
$ ls consumer.services/ bin conf include legal lib release
Let’s now run the image:
$ consumer.services/bin/java -m com.example.builder/com.example.builder.Builder Building a house with bricks...
With jlink, you can create lightweight, custom, stand-alone runtime images tailored to your modular Java applications, thereby simplifying the deployment and reducing the size of your distributed application.