- 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.8 Automatic Modules
You now know to put the Java Platform Module System to use. If you start with a brand-new project in which you write all the code yourself, you can design modules, declare module dependencies, and package your application into modular JAR files.
However, that is an extremely uncommon scenario. Almost all projects rely on third-party libraries. Of course, you can wait until the providers of all libraries have turned them into modules, and then modularize your own code.
But what if you don't want to wait? The Java Platform Module System provides two mechanisms for crossing the chasm that separates today’s premodular world and fully modular applications: automatic modules and the unnamed module.
For migration purposes, you can turn any JAR file into a module simply by placing it onto a directory in the module path instead of the class path. A JAR without a module-info.class on the module path is called an automatic module. An automatic module has the following properties:
The module implicitly has a requires clause for all other modules.
All of its packages are exported and opened.
If there is an entry with key Automatic-Module-Name in the JAR file manifest META-INF/MANIFEST.MF, its value becomes the module name.
Otherwise the module name is obtained from the JAR file name, dropping any trailing version number and replacing sequences of non-alphanumeric characters with a dot.
The first two rules imply that the packages in the automatic module act as if they were on the class path. The reason for using the module path is for the benefit of other modules, allowing them to express dependencies on this module.
Suppose, for example, that you are implementing a module that processes CSV files and uses the Apache Commons CSV library. You would like to express in your module-info.java file that your module depends on Apache Commons CSV.
If you add commons-csv-1.9.0.jar onto the module path, then your modules can reference the module. Its name is commons.csv since the trailing version number -1.9.0 is removed and the non-alphanumeric character - is replaced by a dot.
This name might be an acceptable module name because Commons CSV is well known and it is unlikely that someone else will try to use the same name for a different module. But it would be better if the maintainers of this JAR file could quickly agree to reserve a reverse DNS name, preferably the top-level package name org.apache.commons.csv, as the module name. They just need to add a line
Automatic-Module-Name: org.apache.commons.csv
to the META-INF/MANIFEST.MF file inside the JAR. Eventually, hopefully, they will turn the JAR file into a true module by adding module-info.java with the reserved module name—and every other module that refers to the CSV module with that name will just continue to work.
NOTE
The migration plan to modules is a great social experiment, and nobody knows whether it will end well. Before you put third-party JARs on the module path, check whether they are modular, and if not, whether their manifest has a module name. If not, you can still turn the JAR into an automatic module, but be prepared to update the module name later.
As this book is being written, version 1.9.0 of the Commons CSV JAR file does not have a module descriptor or an automatic module name. Nevertheless, it will work fine on the module path. You can download the library from https://commons.apache.org/proper/commons-csv. Place the commons-csv-1.9.0.jar file into the directory of the v2ch9.automod module. That module contains a simple program that reads a CSV file with country data:
package com.horstmann.places;
import java.io.*;
import org.apache.commons.csv.*;
public class CSVDemo
{
public static void main(String[] args) throws IOException
{
var in = new FileReader("countries.csv");
Iterable<CSVRecord> records = CSVFormat.EXCEL.withDelimiter(';')
.withHeader().parse(in);
for (CSVRecord record : records)
{
String name = record.get("Name");
double area = Double.parseDouble(record.get("Area"));
System.out.println(name + " has area " + area);
}
}
}
Since we will use commons-csv-1.9.0.jar as an automatic module, we need to require it:
@SuppressWarnings("module")
module v2ch09.automod
{
requires commons.csv;
}
Here are the commands for compiling and running the program:
javac -p v2ch09.automod:commons-csv-1.9.0.jar v2ch09.automod/com/horstmann/places/CSVDemo.java v2ch09.automod/module-info.java java -p v2ch09.automod:commons-csv-1.9.0.jar -m v2ch09.automod/com.horstmann.places.CSVDemo