module-info.java是Java 9模块系统的强制配置文件,必须位于源码根目录、以module关键字声明模块名,并通过requires和exports显式管理依赖与可见性。

模块声明必须用 module-info.java 文件
Java 9 引入的模块系统要求每个模块必须有且仅有一个 module-info.java,放在源码根目录(src/main/java 下同级)。它不是类,不能被编译成 .class,也不能被反射加载。
常见错误是把它写成普通类、放在子包里,或试图用 new module-info() 这类语法——这些都会导致编译失败,报错类似:error: module info expected 或 error: class, interface, enum, or record expected。
-
module-info.java必须以module关键字开头,后跟模块名(符合 Java 标识符规则,推荐全小写+点号分隔,如com.example.util) - 模块名不能重复;JVM 启动时若发现两个模块声明同名,会直接拒绝加载
- 模块名不等于包名,但建议保持一致,否则容易混淆导出与封装边界
requires 和 exports 控制依赖与可见性
模块之间默认完全隔离。要让本模块用到其他模块的 API,必须显式写 requires;要让其他模块能访问本模块的某包,必须用 exports。二者缺一不可,且作用方向相反。
例如:模块 com.example.web 依赖 com.example.data 的 com.example.data.model 类,那么:
立即学习“Java免费学习笔记(深入)”;
module com.example.web {
requires com.example.data;
}
但此时 com.example.data 模块仍需主动导出对应包:
module com.example.data {
exports com.example.data.model;
}
-
requires transitive表示“传递依赖”:Arequires transitiveB,那么依赖 A 的模块也能自动访问 B 的导出包(无需再写requires B) -
exports ... to可限制只对特定模块开放,比如exports com.example.internal to com.example.test,避免意外泄露内部 API - 没写
exports的包,即使在 classpath 上也对外不可见——这是模块系统和传统 classpath 最根本的区别
运行时模块路径(--module-path)不能和 classpath 混用
一旦用了模块系统,启动命令就不能再用 -cp 或 -classpath 加载模块化 JAR;必须用 --module-path(或简写 -p),并配合 --module(或 -m)指定主模块。
典型错误是把模块 JAR 放进 -cp,结果 JVM 报:java.lang.NoClassDefFoundError 或更隐蔽的 Module not found,因为 JVM 此时按传统方式加载,完全忽略 module-info.class。
- 模块 JAR 必须包含
module-info.class,且位于顶层(即解压后直接可见) - 非模块化 JAR(无
module-info.class)可放在--module-path上,JVM 会将其视为“自动模块(automatic module)”,名字取自 JAR 文件名(如guava-31.1-jre.jar→ 模块名guava),所有包默认导出,但无法被requires static约束 - 混合使用时,自动模块可依赖命名模块,但命名模块不能
requires自动模块(除非用requires static,且运行时必须存在)
模块系统不解决类加载冲突,反而强化了封装边界
很多人误以为模块系统能替代 ClassLoader 隔离或解决 ClassNotFoundException 冲突。其实恰恰相反:模块系统让类加载失败更早、更明确。它不提供运行时动态加载/卸载能力,也不改变双亲委派模型本身。
比如两个模块都导出同名包(com.example.api),JVM 在解析阶段就会报错:Duplicate package com.example.api,而不是等到运行时。
- 模块系统强制“强封装”:未导出的包,连反射也无法访问(
setAccessible(true)会抛InaccessibleObjectException) - 想绕过封装?必须加 JVM 参数
--add-opens,例如:--add-opens java.base/java.lang=ALL-UNNAMED - 模块图(module graph)在编译期和启动期静态验证,这意味着 IDE 或构建工具(如 Maven)必须支持模块描述,否则可能编译通过但运行失败
真正难的从来不是写对 module-info.java,而是理清哪些包该导出、哪些依赖该设为 transitive、以及如何与遗留的非模块化生态共存——这些决策一旦定下,重构成本远高于初期多花十分钟画张依赖草图。









