Module Graphs

jdeps -v org.module.global

jdeps -verbose org.module.global
The verbose option will explain the dependencies down to the class level.

jdeps -v org.module.global
jdeps -s org.module.global

D:\ModuleTesting\out\production> java --module-path . --describe-module org.module.util org.module.util file:///D:/ModuleTesting/out/production/./org.module.util/

requires java.base mandated
requires org.module.global transitive
qualified exports org.pkg.util to org.module.base org.module.concrete

We can see that although there was a directive that requires org.module.global transitive. The summary listing of jdeps did not show org.module.global as a dependency of org.module.util.
You can interpret a module graph by the way the arrow (called the read edge) is directing you. In this case the graph says pictorially âorg.module.globalâ reads java.base

org.module.util reads java.base,
org.module.global also reads java.base,

Note that org.module.util does not read org.module.global The read edges correspond to the number of elements listed in the jdeps -s listing.

D:\ModuleTesting\out\production>jdeps -summary org.module.global org.module.util org.module.base
org.module.base -> java.base
org.module.base -> org.module.global
org.module.base -> org.module.util
org.module.global -> java.base
org.module.util -> java.base

Our graph is going to become more complicated because we have 5 read edges. Drawing it looks like the following. Note that we have 5 arrows which represents our read edges. org.module.base has a dependency on org.module.global, although it is not specified in the directive file, this was created by the requires transient directive in org.module.util.

jdeps -summary org.module.global org.module.util org.module.base org.module.concrete

D:\ModuleTesting\out\production>jdeps -summary org.module.global org.module.util org.module.base org.module.concrete

org.module.base -> java.base
org.module.base -> org.module.global
org.module.base -> org.module.util
org.module.concrete -> java.base
org.module.concrete -> org.module.global
org.module.concrete -> org.module.util
org.module.global -> java.base
org.module.util -> java.base

Our full module graph is shown below.

The Java exam may have a question about the module graph, but will be restricted to 2 or 3 modules.

Read the descriptors carefully, looking for qualified exports and transitive dependencies, these actually reduce the dependencies.
The java.base module is an implicit dependency for every module. If you see a module graph with any module that does not read java.base, it is not an accurate graph.
If you see a module graph with a node that is a package, then it is not a valid module graph.