Java jmod 怎样列出模块归档中的文件

要列出 JMOD 模块归档里的文件名，直接使用 jmod list，把目标归档路径放在命令末尾：

# 只列出 JMOD 归档中的所有条目名称
jmod list path/to/application.jmod

官方地址：https://docs.oracle.com/en/java/javase/25/docs/specs/man/jmod.html

jmod list 输出的是归档条目名称，不是模块描述，也不是把文件释放到目录。如果你只想检查 JMOD 里有哪些文件，使用 list；想看模块声明用 describe；想把内容展开到磁盘才使用 extract。

jmod list 到底列出什么

Oracle 对 jmod 的定义包含创建 JMOD 和列出已有 JMOD 内容两类工作。list 模式的职责很窄：打印归档中所有条目的名称。条目可以来自类文件、资源、配置文件、原生库、头文件或其他被打包进 JMOD 的内容。

因此，下面这条命令的输入是一个已经存在的 JMOD 文件，输出是名称清单：

# 用固定的相对路径检查归档清单，便于把输出保存到同一任务目录
JMOD_FILE="build/jmods/com.example.app.jmod"
jmod list "$JMOD_FILE"

这里的“列出”不等于读取每个文件的完整内容。命令关心的是归档目录里的条目名称，适合确认某个模块是否包含资源、配置或原生文件，也适合在进一步分析前建立清单。

先分清 JMOD 与模块化 JAR 的用途

JMOD 不是普通 JAR 的替代品。官方文档说明，JMOD 可以聚合 .class 文件、元数据、资源以及其他配置内容，但这种格式是可传输的、不可执行的，主要用于编译或链接阶段。通常的模块发布和模块路径部署仍应优先考虑模块化 JAR。

这条边界会影响你对 jmod list 输出的理解：

• 看到 classes/、配置文件或原生库条目，只能说明它们被收进归档。
• 清单中出现模块描述相关文件，不代表当前命令已经完成模块解析。
• 列出条目不会把 JMOD 变成可直接启动的应用，也不会创建运行时镜像。

如果真正目标是部署模块、发布到 Maven 仓库或生成可运行的运行时镜像，就应回到模块化 JAR、jlink 等对应工具，而不是继续给 list 添加不存在的“查看运行状态”参数。

list、describe、extract 的职责边界

同一个 JMOD 归档可以被不同操作读取，但三者的输出对象不同。把它们分开，排查时就不会把“看清单”“看模块信息”和“拿到实际文件”混在一起。

可以把选择规则记成一句话：只需要名称就用 list，需要模块语义就用 describe，需要实际文件树才用 extract。其中 extract 会写入目录，权限和目标路径就从“读取问题”变成了需要单独控制的写入风险。

怎样把列举结果保存成可审计清单

临时查看时直接输出到终端即可；在构建排查或制品审计中，更适合把归档路径和清单保存到明确的工作目录。下面的示例只列出条目，不展开归档，也不覆盖原始 JMOD：

# 让输入归档和输出清单都落在当前构建目录
JMOD_FILE="build/jmods/com.example.app.jmod"
LIST_FILE="build/reports/com.example.app.jmod.list.txt"

# 先创建报告目录，再把 jmod list 的标准输出写入报告文件
mkdir -p "$(dirname "$LIST_FILE")"
jmod list "$JMOD_FILE" > "$LIST_FILE"

# 记录清单文件位置，便于构建日志引用而不泄露完整本机路径
printf 'JMOD 清单已保存到: %s\n' "$LIST_FILE"

这个写法的重点不是把输出加工成另一种格式，而是让输入制品和输出报告形成稳定对应关系。报告中最好同时记录构建编号、JDK 主版本和归档摘要；如果清单要进入制品库，则应限制写入目录和访问权限。

遇到空输出或失败时先看哪几项

jmod list 没有得到预期结果时，先按输入资产、工具来源和访问权限三层排查，不要马上把问题归因到模块内容：

1. 确认输入路径。相对路径是相对于当前工作目录解析的；脚本切换目录后，原来能用的路径可能已经指向别处。
2. 确认文件确实是 JMOD。文件名后缀只能提供线索，归档应由同一构建流程产生，避免把普通 JAR 或临时压缩包传给 jmod。
3. 确认 JDK 工具来源。检查命令来自预期 JDK，而不是被旧版本或系统中另一份工具覆盖；必要时显式使用该 JDK 的 bin/jmod。
4. 区分读取失败与清单为空。命令报错、路径不存在或权限不足，与归档条目少是不同问题，应分别保留错误输出和清单文件。

如果下一步要用 extract，再额外检查目标目录是否专门用于展开，并避免把不可信 JMOD 直接解压到源码目录、部署目录或共享目录。对未知制品，先用 list 建立条目清单，通常比直接写入文件系统更容易控制影响面。

最后记住这条选择规则

Java jmod 列出模块归档文件名的最小写法是：

# 只读取归档目录清单，不展开文件
jmod list path/to/module.jmod

list 给你条目名称，describe 给你模块描述，extract 才会把内容写到目录。把这三个输出对象分开，既能快速定位归档里是否包含目标文件，也能避免为了查看清单而产生不必要的文件写入。

相关问题

jmod list 会显示文件内容吗？

不会。它打印的是 JMOD 归档中条目的名称；需要读取具体文件内容时，应先明确展开或使用其他针对该内容的工具。

jmod list 能列出模块依赖吗？

不能把它当成依赖报告。要查看模块描述和依赖声明，应使用 jmod describe，再结合构建产物和模块路径分析。

为什么不直接用 extract 查看文件？

extract 会产生目录和文件写入，涉及目标路径、权限和覆盖范围。只想确认归档内容时，list 的影响面更小。