Java模块化核心思想详解

从现在开始，我们要努力学习啦！今天我给大家带来《Java模块化核心思想与机制解析》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

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 类，那么：

module com.example.web {
    requires com.example.data;
}

但此时 com.example.data 模块仍需主动导出对应包：

module com.example.data {
    exports com.example.data.model;
}

• requires transitive 表示“传递依赖”：A requires transitive B，那么依赖 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、以及如何与遗留的非模块化生态共存——这些决策一旦定下，重构成本远高于初期多花十分钟画张依赖草图。

今天关于《Java模块化核心思想详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！