Java模块化是全链路依赖与封装机制,强制声明模块名、依赖和导出,module-info.java为必需身份证;未声明则视为传统classpath代码,需严格遵循语法与路径规则。
Java模块化系统不是“加个module-info.java就完事”的语法糖,而是一套从编译、运行到部署全链路重构的依赖与封装机制——它强制你回答三个问题:这个模块叫什么?它用谁?它让谁用它?
没有module-info.java的项目,哪怕目录结构再规整,JVM也只当它是传统类路径(classpath)下的普通代码,享受不到模块系统的任何保护或优化。
module com.example.app { ... })严格匹配,否则编译报错error: module not found
requires java.base可以省略(隐式依赖),但requires com.example.utils这类自定义模块必须显式声明,否则编译期直接失败,而不是等到Class.forName时才抛NoClassDefFoundError
exports com.example.api后,外部模块仍需requires该模块才能访问;没exports的包,哪怕全是public类,其他模块也完全看不见module com.example.storage {
requires java.sql;
requires transitive com.example.core; // 子模块自动继承此依赖
exports com.example.storage.api;
opens com.example.storage.internal to com.example.test; // 仅测试模块可反射
}很多人以为“用了模块就得抛弃-cp”,其实不是。JVM允许两者并存,但行为截然不同:
--module-path里的JAR必须是命名模块(含module-info.class)或自动模块(无module-info的JAR会被转为自动模块,所有包默认导出,模块名通常来自JAR名)-cp里的JAR永远处于“未模块化”状态,对模块内代码不可见——除非你把它也加进--module-path,或者用--add-modules强行拉进来javac -cp lib/utils.jar --module-path mods/ ... → utils.jar在类路径里,模块代码根本看不到它;正确做法是把utils.jar也放进--module-path,让它成为自动模块opens或open修饰符Spring、Hibernate、Jackson这些框架重度依赖反射,而模块系统默认禁止跨模块反射访问私有成员——这不是bug,是设计。
opens com.example.model:运行时开放整个包供任意模块反射(宽松,慎用)opens com.example.model to com.fasterxml.jackson.databind:只允许指定
模块反射(推荐)open module com.example.app(在module-info.java中):整个模块开放反射,等价于所有包都opens,仅用于极简原型,生产环境避免setAccessible(true)仍抛InaccessibleObjectException,99%是因为目标类所在包没被opens,或目标模块没被requires
光写module-info.java只是开始,验证和交付才是关键。
jdeps --summary app.jar:看你的JAR实际依赖哪些模块,识别出意外引入的“幽灵依赖”(比如某个工具类偷偷用了java.desktop,但你本意只想用java.base)jlink --module-path mods/ --add-modules com.example.app --output myruntime:生成最小化JRE,里面只含真正需要的模块;如果app没声明requires java.desktop,那myruntime里就不会有AWT/Swing相关类——这点对容器部署尤其重要jlink不支持自动模块,所有依赖必须是命名模块或JDK系统模块;否则会报error: module not found
模块化真正的复杂点不在语法,而在思维转换:它要求你把“能跑”变成“明确知道为什么能跑”。一个exports漏写、一个opens少配、一条requires没加,都会在编译期或启动时报错——这看似麻烦,实则是把原本藏在运行时的脆弱性,提前暴露给你。