JDEPS(1)

💖 JDEPS(1) — jdeps 💖

okay bestie, welcome to JDEPS(1), aka the page where jdeps launches the Java class dependency analyzer. No cap, this tool is lowkey iconic for seeing what your Java classes are linked to. 🫶

🌸 NAME 🌸

jdeps — launch the Java class dependency analyzer. That's the whole name, periodt. 💅

✨ SYNOPSIS ✨

jdeps [options] path ...

• options — command-line options. For detailed descriptions of the options that can be used, see:
  • Possible Options
  • Module Dependence Analysis Options
  • Options to Filter Dependences
  • Options to Filter Classes to be Analyzed
• path — a pathname to the .class file, directory, or JAR file to analyze. Drop it in, bestie. 📁

🦋 DESCRIPTION 🦋

The jdeps command shows the package-level or class-level dependencies of Java class files. The input class can be a path name to a .class file, a directory, a JAR file, or it can be a fully qualified class name to analyze all class files. The options determine the output. By default, the jdeps command writes the dependencies to the system output. The command can generate the dependencies in DOT language (see the -dotoutput option). It's giving "X-ray vision for your Java classes." 🔥

🎀 POSSIBLE OPTIONS 🎀

• -?, -h, --help — prints the help message. Say less, honestly.
• -dotoutput dir or --dot-output dir — specifies the destination directory for DOT file output. If this option is specified, then the jdeps command generates one .dot file for each analyzed archive named archive-file-name.dot that lists the dependencies, and also a summary file named summary.dot that lists the dependencies among the archive files. DOT files = cute little graph gossip. 🕸️
• -s, -summary — prints a dependency summary only. Just the TL;DR.
• -v, -verbose — prints all class-level dependencies. This is equivalent to -verbose:class -filter:none.
• -verbose:package — prints package-level dependencies excluding, by default, dependences within the same package. Same-package drama stays out unless you say otherwise. 💅
• -verbose:class — prints class-level dependencies excluding, by default, dependencies within the same archive. Same-archive drama, not today.
• -apionly, --api-only — restricts the analysis to APIs, for example, dependences from the signature of public and protected members of public classes including field type, method parameter types, returned type, and checked exception types. API-only, very VIP. 👑
• -jdkinternals, --jdk-internals — finds class-level dependences in the JDK internal APIs. By default, this option analyzes all classes specified in the --classpath option and input files unless you specified the -include option. You can't use this option with the -p, -e, and -s options. Warning: The JDK internal APIs are inaccessible. So like, don't expect to touch them, bestie. 🚫
• -cp path, -classpath path, or --class-path path — specifies where to find class files.
• --module-path module-path — specifies the module path. It's the module path, your honor.
• --upgrade-module-path module-path — specifies the upgrade module path.
• --system java-home — specifies an alternate system module path.
• --add-modules module-name[, module-name...] — adds modules to the root set for analysis. Multiple module names, comma-separated, slay.
• --multi-release version — specifies the version when processing multi-release JAR files. version should be an integer >=9 or base.
• -q, -quiet — doesn't show missing dependencies from -generate-module-info output. Quiet girlie behavior. 🤫
• -version, --version — prints version information.

🌈 MODULE DEPENDENCE ANALYSIS OPTIONS 🌈

• -m module-name or --module module-name — specifies the root module for analysis. Pick your main character module. 🌟
• --generate-module-info dir — generates module-info.java under the specified directory. The specified JAR files will be analyzed. This option cannot be used with --dot-output or --class-path options. Use the --generate-open-module option for open modules.
• --generate-open-module dir — generates module-info.java for the specified JAR files under the specified directory as open modules. This option cannot be used with the --dot-output or --class-path options.
• --check module-name [, module-name...] — analyzes the dependence of the specified modules. It prints the module descriptor, the resulting module dependences after analysis and the graph after transition reduction. It also identifies any unused qualified exports. Very forensic, very detective. 🔍
• --list-deps — lists the module dependences and also the package names of JDK internal APIs (if referenced). This option transitively analyzes libraries on class path and module path if referenced. Use --no-recursive option for non-transitive dependency analysis.
• --list-reduced-deps — same as --list-deps without listing the implied reads edges from the module graph. If module M1 reads M2, and M2 requires transitive on M3, then M1 reading M3 is implied and is not shown in the graph.
• --print-module-deps — same as --list-reduced-deps with printing a comma-separated list of module dependences. The output can be used by jlink --add-modules to create a custom image that contains those modules and their transitive dependences.
• --ignore-missing-deps — ignore missing dependences. Pretend you didn't see them, bestie. 🙈

🍓 OPTIONS TO FILTER DEPENDENCES 🍓

• -p pkg_name, -package pkg_name, or --package pkg_name — finds dependences matching the specified package name. You can specify this option multiple times for different packages. The -p and -e options are mutually exclusive. Pick a lane, bestie. 💅
• -e regex, -regex regex, or --regex regex — finds dependences matching the specified pattern. The -p and -e options are mutually exclusive.
• --require module-name — finds dependences matching the given module name (may be given multiple times). The --package, --regex, and --require options are mutually exclusive.
• -f regex or -filter regex — filters dependences matching the given pattern. If you give it multiple times, the last one will be selected.
• -filter:package — filters dependences within the same package. This is the default.
• -filter:archive — filters dependences within the same archive.
• -filter:module — filters dependences within the same module.
• -filter:none — no -filter:package and -filter:archive filtering. Filtering specified via the -filter option still applies.
• --missing-deps — finds missing dependences. This option cannot be used with -p, -e and -s options.

🧚 OPTIONS TO FILTER CLASSES TO BE ANALYZED 🧚

• -include regex — restricts analysis to the classes matching pattern. This option filters the list of classes to be analyzed. It can be used together with -p and -e, which apply the pattern to the dependencies.
• -R, --recursive — recursively traverses all run-time dependences. The -R option implies -filter:none. If -p, -e, or -f options are specified, only the matching dependences are analyzed.
• --no-recursive — do not recursively traverse dependences.
• -I, --inverse — analyzes the dependences per other given options and then finds all artifacts that directly and indirectly depend on the matching nodes. This is equivalent to the inverse of the compile-time view analysis and the print dependency summary. This option must be used with the --require, --package, or --regex options.
• --compile-time — analyzes the compile-time view of transitive dependencies, such as the compile-time view of the -R option. Analyzes the dependences per other specified options. If a dependency is found from a directory, a JAR file or a module, all classes in that containing archive are analyzed.

🌟 EXAMPLE OF ANALYZING DEPENDENCIES 🌟

The following example demonstrates analyzing the dependencies of the Notepad.jar file.

Linux and macOS:

$ jdeps demo/jfc/Notepad/Notepad.jar
Notepad.jar -> java.base
Notepad.jar -> java.desktop
Notepad.jar -> java.logging
   <unnamed> (Notepad.jar)
      -> java.awt
      -> java.awt.event
      -> java.beans
      -> java.io
      -> java.lang
      -> java.net
      -> java.util
      -> java.util.logging
      -> javax.swing
      -> javax.swing.border
      -> javax.swing.event
      -> javax.swing.text
      -> javax.swing.tree
      -> javax.swing.undo

Windows:

C:\Java\jdk1.9.0>jdeps demo\jfc\Notepad\Notepad.jar
Notepad.jar -> java.base
Notepad.jar -> java.desktop
Notepad.jar -> java.logging
   <unnamed> (Notepad.jar)
      -> java.awt
      -> java.awt.event
      -> java.beans
      -> java.io
      -> java.lang
      -> java.net
      -> java.util
      -> java.util.logging
      -> javax.swing
      -> javax.swing.border
      -> javax.swing.event
      -> javax.swing.text
      -> javax.swing.tree
      -> javax.swing.undo

💫 EXAMPLE USING THE --INVERSE OPTION 💫

$ jdeps --inverse --require java.xml.bind
Inverse transitive dependences on [java.xml.bind]
java.xml.bind <- java.se.ee
java.xml.bind <- jdk.xml.ws
java.xml.bind <- java.xml.ws <- java.se.ee
java.xml.bind <- java.xml.ws <- jdk.xml.ws
java.xml.bind <- jdk.xml.bind <- jdk.xml.ws

Okay that's the whole JDEPS(1) moment. This iconic page is from JDK 25.0.5.0.3, dated 2026. Go analyze those dependencies, bestie — mwah 💋✨