- 9.1 The Module Concept
- 9.2 Naming Modules
- 9.3 The Modular "Hello, World!" Program
- 9.4 Requiring Modules
- 9.5 Exporting Packages
- 9.6 Modular JARs
- 9.7 Modules and Reflective Access
- 9.8 Automatic Modules
- 9.9 The Unnamed Module
- 9.10 Command-Line Flags for Migration
- 9.11 Transitive and Static Requirements
- 9.12 Qualified Exporting and Opening
- 9.13 Service Loading
- 9.14 Tools for Working with Modules
This chapter is from the book
This chapter is from the book
This chapter is from the book
9.6 Modular JARs
So far, we have simply compiled modules into the directory tree of the source code. Clearly, that is not satisfactory for deployment. Instead, a module can be deployed by placing all its classes in a JAR file, with a module-info.class in the root. Such a JAR file is called a modular JAR.
To create a modular JAR file, use the jar tool in the usual way. If you have multiple packages, it is best to compile with the -d option which places class files into a separate directory. The directory is created if it doesn't already exists. Then use the -C option of the jar command to change to that directory when collecting files.
javac -d modules/com.horstmann.greet $(find com.horstmann.greet -name *.java) jar -c -v -f com.horstmann.greet.jar -C modules/com.horstmann.greet .
If you use a build tool such as Maven, Ant, or Gradle, just keep building your JAR file as you always do. As long as module-info.class is included, you get a modular JAR.
Then, include the modular JAR in the module path, and the module will be loaded.
CAUTION
In the past, classes of a package were sometimes distributed over multiple JAR files. (Such a package is called a “split package”.) This was probably never a good idea, and it is not possible with modules.
As with regular JAR files, you can specify a main class in a modular JAR:
javac -p com.horstmann.greet.jar -d modules/v2ch09.exportedpkg $(find v2ch09.exportedpkg -name *.java) jar -c -v -f v2ch09.exportedpkg.jar -e com.horstmann.hello.HelloWorld -C modules/v2ch09.exportedpkg .
When you launch the program, you specify the module containing the main class:
java -p com.horstmann.greet.jar:v2ch09.exportedpkg.jar -m v2ch09.exportedpkg
When creating a JAR file, you can optionally specify a version number. Use the --module-version parameter, and also add @ and the version number to the JAR file name:
jar -c -v -f com.horstmann.greet@1.0.jar --module-version 1.0 -C com.horstmann.greet .
As already discussed, the version number is not used by the Java Platform Module System for resolving modules, but it can be queried by other tools and frameworks.
NOTE
You can find out the version number through the reflection API. In our example:
Optional<String> version = Greeter.class.getModule().getDescriptor().rawVersion();
yields an Optional containing the version string "1.0".
NOTE
The module equivalent to a class loader is a layer. The Java Platform Module System loads the JDK modules and application modules into the boot layer. A program can load other modules, using the layer API (which is not covered in this book). Such a program may choose to take module versions into account. It is expected that developers of programs such as Java EE application servers will make use of the layer API to provide support for modules.
TIP
If you want to load a module into JShell, include the JAR on the module path and use the --add-modules option:
jshell --module-path com.horstmann.greet@1.0.jar --add-modules com.horstmann.greet