Java JMOD与模块化JAR的用途有什么区别

模块化JAR适合常见的模块发布与运行部署；JMOD主要用于编译或链接阶段的模块封装，能同时收纳本地库、配置等内容，不能像JAR那样直接放到运行时模块路径使用。需要用jlink生成运行时镜像，也不意味着应用必须先变成JMOD：模块化JAR同样可以作为链接输入。

官方工具文档：https://docs.oracle.com/en/java/javase/25/docs/specs/man/jmod.html。下面以JDK 25文档为依据，用同一个小模块解释两种产物的用途。示例是供读者自行尝试的命令，本文没有执行或提供运行截图。

普通模块部署为什么优先选JAR

假设已有一个纯Java命令行工具，只需要发布给使用者，让他们通过模块路径启动。为它额外生成JMOD，未必带来使用价值，反而可能让接收方误以为可以直接运行那个文件。官方jmod说明也建议多数模块路径部署和Maven仓库发布继续采用模块化JAR。

模块化JAR不是“文件名里有module”的JAR，而是带有模块描述符的归档。普通JAR在模块路径上可能被当成自动模块，这与显式模块仍有区别；给普通JAR换扩展名不会补出module-info.class。

同一个模块怎样打成两种文件

在一个新的示例目录中，准备以下两个源文件。模块名是demo.packing，主类为demo.Main。它只依赖隐式的java.base，没有第三方依赖，也不包含任何本地库。

src/demo.packing/module-info.java：

// 显式模块描述符：本例无需向其他模块导出包。
module demo.packing {
}

src/demo.packing/demo/Main.java：

package demo;

// 简单入口，仅用于说明打包形式不会改变类的业务逻辑。
public class Main {
    public static void main(String[] args) {
        System.out.println("module packaging demo");
    }
}

下面使用类Unix shell语法，并假定javac、jar、jmod和jlink来自同一套完整JDK 25。目录名用于把同名模块的两种产物分开，避免后面使用模块路径时混入重复模块。

# 在全新示例目录中准备编译输出和两种归档目录。
mkdir -p classes mjar mjmod

# 编译描述符与主类，module-info.class位于classes根目录。
javac -d classes src/demo.packing/module-info.java src/demo.packing/demo/Main.java

# 同一组class文件形成显式模块化JAR。
jar --create --file mjar/demo.packing.jar -C classes .

# JMOD的--class-path指定要收纳的类，不是运行时类路径。
jmod create --class-path classes mjmod/demo.packing.jmod

命令成功时应得到两个不同的归档文件。若JMOD目标文件已存在，应选择新的输出文件名或按自己的构建清理规则处理；不要把JMOD创建失败误判成模块描述符只能用于JAR。

为什么JAR能运行而JMOD要交给链接器

模块化JAR可直接交给Java启动器，通过模块名与主类启动；JMOD则作为链接器输入，链接后运行的是镜像里的Java运行时，而不是原始JMOD归档。

# 从模块化JAR启动；因为没有打包主类属性，显式给出模块/主类。
java --module-path mjar --module demo.packing/demo.Main

# 用JMOD链接独立镜像，输出目录必须尚不存在。
jlink --module-path mjmod --add-modules demo.packing --output runtime-jmod
./runtime-jmod/bin/java --module demo.packing/demo.Main

# 模块化JAR也能作为链接输入，另用一个新的输出目录。
jlink --module-path mjar --add-modules demo.packing --output runtime-jar
./runtime-jar/bin/java --module demo.packing/demo.Main

上面的主类预期打印源码中的一行文字，不是本文实测输出。jlink会解析根模块及其依赖；JDK 25文档说明，在指定模块路径但无法从中解析java.base时，会补入该JDK的jmods路径。因此这里没有手工拼接JDK安装目录。换成裁剪环境、跨平台构建或不同版本工具链时，需要重新确认模块来源及平台匹配条件。

哪些场景才值得增加JMOD产物

如果交付中需要组织本地库、本地命令或可编辑配置，并准备将模块链接到运行时镜像，JMOD的专门选项才更有意义。例如jmod提供--libs、--cmds和--config等入口。它帮助组织链接所需内容，不能自动把Linux本地库变成Windows可用版本，也不能替代目标平台构建。

反过来，只有Java类与普通资源、面向仓库发布和模块路径运行的库，通常先保留模块化JAR即可。不要把“多一种格式”当作模块化程度更高；模块名、requires、exports等描述符语义，才是模块边界的关键。

自定义镜像也不是一次生成后永久免维护。应用与所含运行时模块的更新需要由交付方安排；更换模块产物后应重新构建相应镜像，而不是把新JMOD文件随意复制进旧镜像就期待它生效。

模块路径相关问题怎么判断

JMOD是不是可以用java -jar启动？

不可以把它当可执行JAR使用。即使模块化JAR也要区分是否设置了主类；本文用模块名加主类启动，不依赖Main-Class属性。

把JAR改名成.jmod就能给jlink用吗？

不要这样做。格式由内容与工具定义，改后缀不是转换。如果本来已经是显式模块化JAR，直接作为相应模块路径输入即可。

同一目录里放JAR和同名JMOD更保险吗？

没有必要。应控制模块路径的候选内容，避免同名模块产生歧义；示例专门使用两个产物目录，每次只选择需要的那一套。

参考：JDK 25 jmod文档、jar文档、jlink文档。