| Lesson 12 | Module Graphs with jdeps |
| Objective | Interpret Java module dependencies and verify them with jdeps. |
To minimize page weight and keep the lesson focused, we use a single comprehensive diagram that
summarizes all read edges discovered by jdeps. The narrative below walks from first principles
to the full graph so the image functions as the final “answer key,” not a spoiler.
In the Java Platform Module System (JPMS), a read edge indicates that one module
reads (depends on) another. Every module implicitly reads java.base.
Qualified exports and requires transitive shape which modules must be read directly
and which dependencies are inherited.
jdepsStart with a summary scan, then drill down if needed:
# Summary: module-to-module edges only
jdeps -summary org.module.global org.module.util org.module.base org.module.concrete
# Verbose: down to the class level (useful for surprises)
jdeps -verbose org.module.global
Inspect a specific module’s directives:
# Shows requires / exports / transitive / qualified-exports
java --module-path . --describe-module org.module.util
jdeps -summary across all four modules.
Reading the diagram from top to bottom:
org.module.util and org.module.global both read java.base.org.module.base reads org.module.util and org.module.global (plus the implicit java.base).org.module.concrete reads org.module.util, org.module.global, and java.base.
If org.module.util declares requires transitive org.module.global, then any module that
reads org.module.util will also read org.module.global implicitly. That is why
org.module.base can acquire a read edge to org.module.global even without a
direct requires in its descriptor.
java.base.requires statements in dependents but still
results in a read edge when summarized by jdeps.
jdeps -summary org.module.global org.module.util org.module.base org.module.concrete
Use the summary to sanity-check the final image: count the arrows (read edges) and confirm they match the summary lines. If they don’t, your diagram, or your assumptions are off.