Any class that is not on the module path is part of an unnamed module. Technically, there may be more than one unnamed module, but all of them together act as if they are a single module which is called the unnamed module. As with automatic modules, the unnamed module can access all other modules, and all of its packages are exported and opened.
However, no explicit module can access the unnamed module. (An explicit module is a module that is neither automatic nor unnamed—that is, a module with a module-info.class on the module path.) In other words, explicit modules are always free from the “class path hell.”
Consider, for example, the program of the preceding section. Suppose you put commons-csv-1.5.jar onto the class path instead of the module path:
java –module-path v2ch09.automod \
–class-path commons-csv-1.5.jar \
-m v2ch09.automod/com.horstmann.places.CSVDemo
Now the program won’t start:
Error occurred during initialization of boot layer
java.lang.module.FindException: Module commons.csv not found, required by v2ch09.automod
Therefore, migration to the Java Platform Module System is necessarily a bottom-up process:
- The Java platform itself is modularized.
- Next, libraries are modularized, either by using automatic modules or by turning them into explicit modules.
- Once all libraries used by your application are modularized, you can turn the code of your application into a module.
Source: Horstmann Cay S. (2019), Core Java. Volume II – Advanced Features, Pearson; 11th edition.