Java Module 为何要引入

Java 9 引入 Java Platform Module System（JPMS，即 Java Module），核心目的是解决“大型 Java 应用越来越难维护、越来越复杂”的问题。在模块系统出现之前，Java 主要依赖 classpath 和 JAR 包，这种方式在大型、长期演进的项目中暴露出很多结构性缺陷。

下面从动机、解决的核心问题、带来的好处三个层面来解释。

一、引入 Java Module 的核心动机

一句话总结：

让 Java 平台和应用在“结构、依赖、封装”上更清晰、更可控、更安全。

二、classpath 时代的主要问题

在 Java 9 之前，依赖管理主要依赖 classpath + JAR：

1️⃣ 封装失控（强访问问题）

• public 是“全公开”
• 无法表达：
  • 哪些类是对外 API
  • 哪些是内部实现细节
• 结果：
  • 别人很容易依赖你的内部类
  • 重构困难，升级风险高

✅ Module 引入真正的“模块级封装”

2️⃣ 依赖关系不清晰

• JAR 本身不声明自己依赖谁
• 运行时才发现 ClassNotFoundException / NoClassDefFoundError
• 大型项目依赖关系像“毛线球”

✅ Module 显式声明依赖（requires）

3️⃣ 启动慢、内存大（JDK 本身问题）

• JDK 是一个巨大的整体
• 即使是“Hello World”，也要加载大量无关类
• 无法裁剪 JDK

✅ Module 让 JDK 本身模块化（java.base 等）

4️⃣ 反射滥用

• 任何类都可以被反射访问
• 破坏封装
• 框架过度依赖内部实现

✅ Module 精确控制反射权限（opens / opens … to）

三、Java Module 解决了什么

✅ 1. 真正的封装（关键）

module com.example.app {
    exports com.example.api;
}

• 只有 com.example.api 对外可见
• 其他包即使 public 也不可访问

✅ 2. 显式依赖

module com.example.app {
    requires java.sql;
    requires com.google.gson;
}

• 编译期就能发现依赖缺失
• 不再靠“运气”和“classpath 顺序”

✅ 3. 可靠的配置（Reliable Configuration）

• 模块图在启动时就确定
• 不再有运行时才发现的依赖问题

✅ 4. JDK 可分拆、可裁剪

• JDK 拆分为 90+ 模块
• 可构建 自定义 runtime（jlink）

jlink --module-path mods \
      --add-modules com.example.app \
      --output myapp-runtime

✅ 特别适合：

• 微服务
• 容器
• 云原生
• 嵌入式

✅ 5. 更强的可维护性

• 模块边界清晰
• API 与实现强制分离
• 长期演进更安全

四、一个简单的对比

五、为什么不是所有人都马上用？

✅ 现实情况：

• 模块系统 偏重量级
• 对老项目迁移成本高
• 很多库仍是“自动模块”

因此在以下场景更常见：

• JDK 内部
• 基础框架 / 平台
• 新项目
• 对稳定性要求高的系统

六、一句话总结

Java Module 的引入，是为了让 Java 从“能跑就行”走向“结构清晰、依赖明确、长期可维护”。

如果你愿意，我可以：

• 用 classpath vs module 的真实示例对比
• 讲 自动模块 / 未命名模块
• 分析 Spring Boot 是否适合用 Module
• 给你一个 最小可运行 module 示例

你想从哪一块深入？