Overview
jdeps statically analyses class files and reports what they depend on — at class,
package or module granularity. It exists chiefly as the migration companion to the module
system: it tells you which platform modules an application really needs, whether it leans
on JDK-internal APIs, and can draft a module-info.java for a plain jar.
Key points
- Granularity: default is package-level per jar;
-verbose:classdrills to classes,-summary(-s) rolls up to module/jar level. -jdkinternals: flags uses ofsun.*/jdk.internal.*APIs and suggests the supported replacement — the first thing to run when a JDK upgrade breaks a legacy app.--generate-module-info dir: emits a draftmodule-info.javaper jar from observed dependencies — a starting point for modularising, not a finished descriptor (it cannot see reflection).--print-module-deps: prints the comma-separated platform module list, exactly the format jlink--add-modulesexpects — the standard step when cutting minimal runtime images for containers.- Scope control:
--multi-release 21for MR-jars;-R(recursive over transitive deps),--ignore-missing-depswhen the full classpath isn't available (common with Spring Boot fat jars — analyse the explodedBOOT-INFinstead). - Blind spots: purely static — reflection,
ServiceLoaderproviders andClass.forNameusage are invisible, so treat its output as a lower bound.
Examples
jdeps -jdkinternals legacy-app.jar
jdeps --print-module-deps --ignore-missing-deps app.jar # → java.base,java.sql,...
jdeps --generate-module-info out lib/plain-lib.jar
Related
- The JDK, the JRE & their tools — parent catalog of the toolchain.
- jlink — consumes
--print-module-depsoutput to build minimal runtimes. - javap — the per-class view when jdeps' aggregate view isn't enough.
- Build ecosystem — build plugins wrap jdeps for image-building pipelines.