Explicit Modules
As the name implies, an explicit module is described by its module descriptor that explicitly specifies its name and the modules it reads (i.e., its dependencies), including any packages it exports or opens, or any services it provides or uses. A modular JAR is treated as an explicit module when specified on the module path.
Access to types in an explicit module is determined by the accessibility rules for types in packages exported or opened by the explicit module.
An explicit module cannot access code in the unnamed module as it cannot refer to the unnamed module in its module declaration.
Named Modules
Explicit modules and automatic modules are characterized as named modules. In the case of the explicit module, the name is specified in the module declaration. For the automatic modules, the name is either in the manifest file of its JAR or generated from its file name. A plain JAR or a modular JAR is treated as a named module when specified on the module path. Comparison of modules is shown in Table 19.5.
Table 19.5 Module Comparison
Named modules | |||
Criteria | Unnamed module | Automatic module | Explicit module |
JAR | Plain or modular JAR | Plain JAR | Modular JAR |
Path | On class path | On module path | On module path |
Name | Not applicable | Either in manifest file or from file name | Specified in module descriptor |
Module descriptor | Not applicable | Not applicable | Mandatory |
Reads | All modules | All modules | Only named modules that are required |
Exports/Opens | All packages | All packages | Only exported/open packages |
19.12 Migrating to Modules
The module system allows incremental migration of non-modular code to modules. Knowledge of dependencies between types in the plain JARs is crucial to drive this migration. This is probably easier with an application whose code one has control over than it is with libraries and frameworks from third parties. Regardless, having a better handle on dependencies makes the process easier. The jar tool (p. 1211) is useful to obtain information about the contents of a JAR and the jdeps tool (p. 1214) is a great tool to discover dependencies in the code.
The scenarios presented below are very much idealized, and deal with code in plain and modular JARs. The basic idea is to move code from the class path to the module path, either converting plain JARs to explicit modules directly or via automatic modules.
Leave a Reply