Module path & Resolution
Modulepath sounds similar to the classpath. However, a module path is a list of path to individual modules and directories containing modules. Java compiler and java runtime resolve the module using module descriptors. Modules are resolved from module path. Whereas earlier versions of java resolve the classes from the classpath.
During module resolution through module path java compiler and runtime knows exactly what modules to be resolved. Module resolution starts from root module and recursively resolves the dependent (required) modules. Each resolved module is added to a resolved set. and, the resolution process tends to terminate when there is no module further has new dependency to be resolved. Once the modules are resolved the dependency graph generated would be acyclic. For resolving multiple root modules, each root module is resolved separately and then the union of resolved modules will be considered.
Fig: Module dependency.
For instance, from the above figure module resolution happens as follows.
requires
) on module 1. Now try to resolve module 1. Since, module 1 has already been resolved, ignore and move on to the next step.Based on the context of usage, we segregate modules into FOUR different categories.
Automated modules
The third party dependency jars we use as part of the application do fall into automated modules category, provided they do not have module descriptor. All the libraries that are part of our application and are not migrated to support Java 9 modularity considered as automated modules.
Platform modules
Java SE platform itself is modularized as part of Project Jigsaw. These modules are called platform modules.
Unnamed module
To use Java 9 it is not mandatory to program with modularity and java modules. We can follow conventional java programming with Java 9 as well. When no modularity is considered, Java treats the entire application under the unnamed module.
Application modules
Modules created part of your application are considered as Application modules.