concept module resolution in category java

This is an excerpt from Manning's book The Java Module System.
Now you have three nodes in the graph, but only two were resolved. The dependencies of java.xml are still unknown, so the JPMS checks them next. It doesn’t have any dependencies other than java.base, though, so module resolution concludes. Starting with my.xml.app and the omnipresent base module, the process built a small graph with three nodes.
Figure 5.3 The
--limit-modules
option is evaluated before module resolution.![]()
Diagnostic messages during module resolution
With the option
--show-module-resolution
, the module system prints messages during module resolution. The following is the output from launching the ServiceMonitor application with that option. It identifies the root modules (one, in this case), modules that were loaded as a dependency, and which dependency that was:$ java --module-path mods:libs --show-module-resolution #1 --limit-modules monitor #2 --dry-run #3 --module monitor # for each module the file is listed; # I removed that for succinctness but it can be helpful > root monitor > monitor requires monitor.observer > monitor requires monitor.rest > monitor requires monitor.persistence > monitor requires monitor.observer.alpha > monitor requires monitor.observer.beta > monitor requires monitor.statistics > monitor.rest requires spark.core > monitor.rest requires monitor.statistics > monitor.persistence requires hibernate.jpa > monitor.persistence requires monitor.statistics > monitor.observer.alpha requires monitor.observer > monitor.observer.beta requires monitor.observer > monitor.statistics requires monitor.observer # Spark dependencies truncated # Hibernate dependencies truncatedActivates messages for module resolution