If your Java project hides surprise dependencies like a raccoon in the attic then jdeps is the flashlight you need. This guide walks through using jdeps for dependency analysis on jars and modules while giving you a few sarcastic comments to keep things lively. Expect clear reports useful for build tools and ongoing code maintenance.

Pick a target and run a quick scan

Start by pointing jdeps at the artifact that is acting suspiciously. You can inspect a full jar or a single class if you want a surgical look. For a compact summary run a minimal command for a fast read on package level coupling.

jdeps -s myapp.jar

The summary output highlights package to package dependencies which is the prime place to spot unwanted third party or platform references.

Read the report and hunt for surprises

Look for unexpected links to platform modules or external libraries. Those are the lines that will bite you during upgrades or when you try to modularize the app. If you see deprecated or platform modules that you did not intend to use log them as tech debt items and investigate the classes that cause the reference.

Use targeted scans when you do not want to pull an entire jar

• Check a single class file when chasing a particular runtime feature
• Run jdeps on specific packages to narrow noise
• Repeat scans after changing classpath entries to confirm fixes

Generate graphs for visual inspection

When words fail use pictures. Export dot files for Graphviz and make a pretty map that you can pin to the wall or drop in a PR to freak out teammates.

jdeps -dotoutput graphs myapp.jar
# then render with Graphviz
# dot -Tpng graphs/module-deps.dot -o module-deps.png

Visual maps help spot cycles and heavy coupling at a glance which is perfect when you are planning module boundaries or refactors.

Refine results by giving jdeps the right classpath or module path

False positives happen when jdeps cannot see all required classes. Tell it where external jars live to clean up the report. For example:

jdeps -classpath lib/* myapp.jar

For modular projects use the module path option that matches your build tool setup. Accurate inputs equal trustworthy output.

Integration and maintenance tips

• Run jdeps as part of CI as a static analysis gate to catch new dependency surprises
• Store generated dot output for historical comparison when you refactor
• Use the summary flag in automated reports for quick human review
• Combine jdeps findings with your build tools when planning modularization

jdeps does the heavy lifting for static dependency analysis so you can spend less time guessing and more time fixing. Run targeted scans when you chase a nasty dependency and use Graphviz to make a dependency map that actually helps. Now go find that sneaky transitive jar and pretend it never happened.