Java jdeps 怎样列出JAR依赖的模块名称

想从一个 JAR 中列出它依赖的 Java 模块，最直接的命令是 jdeps --list-deps app.jar。如果结果要直接作为 jlink --add-modules 的输入，则改用 jdeps --print-module-deps app.jar，它会输出逗号分隔的模块名称。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/specs/man/jdeps.html

先用 --list-deps 看清楚依赖关系，再用 --print-module-deps 取机器可消费的模块列表。两者都分析 JAR，但输出目的不同；不要把包名列表误当成模块名列表。

一、先确认 jdeps 分析的对象

jdeps 可以分析单个 .class 文件、目录、JAR，或者指定模块。对普通应用，直接把 JAR 路径作为最后一个参数即可。默认输出偏向包级依赖概览，而不是只打印一列模块名。

# 先确认 jdeps 来自当前 JDK，而不是只安装了 JRE
jdeps --version

# 分析应用 JAR 的默认依赖概览
jdeps build/app.jar

默认输出通常会先显示类似 app.jar -> java.base 的模块关系，再展开到包。这个视图适合先判断应用是否依赖 java.desktop、java.logging 等模块，但还不是后续脚本最方便消费的格式。

二、用 --list-deps 列出模块依赖

需要阅读结果时，使用 --list-deps。Oracle 文档将它定义为列出模块依赖，同时列出被引用的 JDK 内部 API 包；它还会在引用到类路径或模块路径中的库时进行传递分析。

# 列出应用需要的模块；输出适合人工阅读
jdeps --list-deps build/app.jar

# 如果只想看当前 JAR 的直接依赖，关闭传递遍历
jdeps --list-deps --no-recursive build/app.jar

把这两个命令放在一起比较，可以看出“直接依赖”和“传递依赖”的区别。应用只直接使用 java.sql，并不代表运行时只需要这一项；开启递归分析时，模块图中被带入的其他依赖也可能被列出。

三、用 --print-module-deps 得到纯模块名列表

如果问题是“怎样列出 JAR 依赖的模块名称”，通常最终需要的是下面这个参数。--print-module-deps 等价于减少隐含读取边的模块依赖输出，并打印逗号分隔的模块依赖列表；该列表可以用于 jlink --add-modules。

# 输出可复制到构建脚本中的逗号分隔模块列表
jdeps --print-module-deps build/app.jar

# 将模块列表保存给后续 jlink 命令使用
MODULES="$(jdeps --print-module-deps build/app.jar)"
# 把模块列表交给 jlink，生成只包含这些模块的运行时镜像
jlink --add-modules "$MODULES" --output build/runtime

这里不要对输出再按空格切分，因为它的设计就是逗号分隔。若脚本要把结果传给其他工具，可以先保留原字符串，再根据目标工具的参数格式转换。

四、类路径和模块路径要与真实运行环境一致

当 JAR 依赖外部库时，分析命令需要知道这些库在哪里。模块化应用可以通过 --module-path 提供模块路径；传统依赖则使用 --class-path。如果路径不完整，输出可能出现缺失依赖，不能仅凭一份不完整清单判断应用真正需要的模块。

# 提供模块化依赖所在目录，分号按 Windows 环境调整
jdeps --print-module-deps \
  --module-path "lib/modules" \
  build/app.jar

# 提供传统类路径依赖并保留缺失项提示
jdeps --list-deps \
  --class-path "lib/*" \
  build/app.jar

模块路径解决“按模块查找”的输入，类路径解决“按类文件查找”的输入。二者不是为了让同一个库重复填写；应根据你的应用实际打包方式选择。

五、遇到缺失依赖时怎样判断结果

当分析环境缺少某个依赖时，先补齐 --module-path 或 --class-path，再重新分析。只有明确接受不完整结果时，才考虑 --ignore-missing-deps；它会隐藏缺失依赖带来的干扰，但不会替你推断缺失模块名称。

# 先显示缺失依赖，便于定位打包或路径问题
jdeps --list-deps --missing-deps build/app.jar

# 明确只想取得已解析部分时再忽略缺失项
jdeps --print-module-deps --ignore-missing-deps build/app.jar

如果目标是制作最小运行时镜像，不建议一开始就忽略缺失项。先让依赖路径完整，再用 --print-module-deps 生成模块集合，得到的镜像更容易解释和复现。

六、把三个常用命令放进排查顺序

1. 用 jdeps build/app.jar 看默认的模块到包关系，确认输入和大致范围。
2. 用 jdeps --list-deps --no-recursive build/app.jar 看当前 JAR 的直接依赖。
3. 用 jdeps --list-deps build/app.jar 观察递归分析后的完整模块依赖。
4. 用 jdeps --print-module-deps build/app.jar 生成脚本或 jlink 需要的逗号分隔结果。

这样既能保留面向人的解释信息，也能拿到面向工具的模块参数。最常见的误区是把 jdeps 的包级展开输出直接复制给 jlink，或者在依赖缺失时把不完整结果当成最终模块集合。

常见问题

--list-deps 和 --print-module-deps 有什么区别？

前者更适合阅读依赖清单，后者直接打印逗号分隔的模块名，适合传给 jlink --add-modules。

为什么输出里出现包名而不是模块名？

默认分析会展开包级或类级依赖。使用 --list-deps 或 --print-module-deps，并确认输入和路径解析完整，可以得到模块层面的结果。

--no-recursive 什么时候使用？

当你只想判断当前 JAR 直接声明或直接引用的依赖时使用；要准备完整运行时模块集合，则不能只看非递归结果。

可以把 jdeps 当成模块化改造工具吗？

它能帮助发现依赖和 JDK 内部 API 使用情况，但不会自动替你完成业务代码的模块边界设计。模块描述符、导出关系和运行时测试仍需要单独处理。