Java 怎么在模块化系统中使用自动模块-java教程-PHP中文网

自动模块是传统jar在模块路径下的过渡形态，名称由manifest中automatic-module-name指定或按文件名推导（如log4j-core-2.20.0.jar→log4j.core），默认导出所有包且无封装、反射及spi支持，需手动补足能力缺口。

java 怎么在模块化系统中使用自动模块

Java 模块化系统中使用自动模块，核心是让未模块化的传统 JAR 包在模块路径（--module-path）下“可用但可控”。它不是为了替代显式模块，而是为迁移争取时间、降低升级门槛。关键不在于“能不能用”，而在于“怎么用得稳、不出错”。

当你把一个不含 module-info.class 的 JAR（比如 guava-32.1.3-jre.jar）放到模块路径启动应用时，JVM 会自动赋予它模块身份：

若 JAR 的 META-INF/MANIFEST.MF 中声明了 Automatic-Module-Name: com.google.guava，就直接采用该名称
否则按文件名推导：去掉 .jar、版本号、非字母数字字符，用点分隔符替换短横线和下划线，例如：
log4j-core-2.20.0.jar → log4j.core（注意：末尾数字被截断，不是 log4j.core.2.20.0）

这个推导出的名字必须是合法 Java 标识符，否则会失败。建议在构建阶段主动注入 Automatic-Module-Name，避免命名冲突或非法字符问题。

自动模块有两大隐式特性，看似方便，实则埋雷：

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

默认 导出所有包：任何模块（包括未命名模块）都能访问其 public 类——破坏封装原则，也易引发 split-package 错误
默认 requires 所有其他模块（包括 java.base 和其他自动模块）：它能调用几乎所有公开 API，但反过来，它无法被其他模块安全地“反向依赖”

典型问题场景：

两个不同版本的 commons-lang3 同时出现在模块路径 → JVM 报 split package 错误
主类在未命名模块（如 -cp 启动），却想通过反射访问自动模块中 package-private 成员 → 触发 IllegalAccessError

你不能在 module-info.java 中写 requires guava.32.1.3.jre; 这种带版本号的名称——它不是合法模块名。你应该用推导后或 MANIFEST 中声明的规范名：

确认名称：运行 jdeps --print-module-deps your-app.jar 查看实际识别出的自动模块名
在 module-info.java 中声明依赖：
requires com.google.guava;（如果 MANIFEST 设了该名）或 requires guava;（如果按文件名推导）
注意：自动模块不会校验 requires 是否真实存在，但若运行时找不到对应 JAR，仍会报 Module not found

自动模块不处理反射、SPI、资源加载等深层机制，需手动干预：

需要反射访问内部类（如 sun.misc.Unsafe）？加 JVM 参数：
--add-opens java.base/sun.misc=ALL-UNNAMED
要用 ServiceLoader 加载服务实现？在你的显式模块中声明：
uses com.example.spi.MyService;
跨模块读取 META-INF/services/xxx？确保提供方模块已 opens 对应包，或改用 ClassLoader.getSystemResource() 等兼容方式

这些不是可选项，而是必要补丁——否则看似能编译，运行时大概率失败。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南