19.11 Categories of Modules
The Java Module System is designed to allow both non-modular and modular code to work together. Types are usually bundled in JAR files. Regardless of whether it a plain JAR or a modular JAR, how its content is handled by the module system depends on the path on which it is placed when using the JDK tools: the class path (§6.4, p. 337) or the module path (p. 1186). Many JDK tools, like javac and java commands, allow both paths to be specified on the command line in order to mix non-modular and modular code. Interpretation of JARs placed on either of these two paths is shown in Table 19.4, and is the subject of this section. Understanding this distinction is also essential for migrating code into modules (p. 1209).
Table 19.4 How JARs Are Handled Depends on the Path
Path | Plain JAR | Modular JAR |
On the class path: -cp | Included in the unnamed module | Included in the unnamed module |
On the module path: -p | Treated as an automatic module | Treated as an explicit module |
Searching for types on the class path is different from searching for types on the module path. Class path search is a linear search on the entire class path, finding the first occurrence of a type and terminating if the type is found. Module path search is according to the module dependencies and therefore more efficient.
The Unnamed Module
Types from any JAR that is placed on the class path are included in the unnamed module, regardless of whether it is a plain or a modular JAR. If it is a modular JAR, its module descriptor is ignored. However, note that a unique unnamed module is associated with each class loader. Classes loaded by a class loader via the class-path are members of the unnamed module associated with that class loader. Colloquially we refer to the unnamed module as the one associated with the application class loader.
The unnamed module is a catchall solution to capture code that is on the class path. It is analogous to code not declared in packages being part of the unnamed package. It is a compatibility feature that allows code on the class path to work with modules on the module path.
Types in the unnamed module can access code from both the class path and the module path—that is, the unnamed module can read all modules.
All packages in the unnamed module are exported and open for reflection. Types in the unnamed module are accessible to other types in the unnamed module, and also accessible to automatic modules, but only by reflection to explicit modules. An explicit module on the module path cannot access code in the unnamed module, as the unnamed module cannot be specified in a requires directive because it has no name. Access to types in the unnamed module is governed by accessibility rules for types in packages—that is, only public types in a package are accessible to other packages in the unnamed module and in any automatic modules.
Leave a Reply