为何要用java Module模块

使用 Java Module（模块，JPMS，Java Platform Module System），主要是为了解决传统 Java 项目在可维护性、安全性、依赖管理和大规模系统演化方面的问题。简单来说：模块让“能做什么、不能做什么”变得明确和可控。

下面从「为什么需要」和「解决什么问题」两个角度说明。

一、传统 Java（没有 Module）的问题

1. 类路径（Classpath）是“扁平的”

在 classpath 模式下：

• 所有类都在一个“大池子”里
• 任何类都可以访问任何 public 类
• 编译期可能没问题，运行期才报 NoClassDefFoundError

➡ 依赖关系不清晰、容易出错

2. public 太“公开”了

只要类是 public：

• 谁都能用
• 内部 API 无法真正隐藏
• 重构成本极高（你不知道谁在用）

➡ 无法控制对外暴露的边界

3. 大型系统难以演化

JDK 本身也越来越庞大：

• Java 8 有上万个类
• 很多内部 API 被滥用（如 sun.misc.*）

➡ JDK 自己都难以维护和裁剪

二、Java Module 解决的核心问题

1. 明确的模块边界（强封装）

模块通过 module-info.java 声明：

module com.example.service {
    exports com.example.service.api;
    requires com.example.util;
}

好处：

• 只有 exports 的包对外可见
• 其他包即使 public 也不能被外部访问
• 真正实现“内部实现隐藏”

✅ 提高安全性与可维护性

2. 显式依赖（编译期+运行期）

• requires 明确声明依赖
• 缺失依赖 → 编译失败
• 不再有“神秘 classpath 问题”

✅ 依赖关系清晰、可控

3. 更好的性能与体积控制

• 可只使用需要的模块（如微服务）
• 配合 jlink 生成最小 JVM
• 适合云原生、容器环境

✅ 启动更快、镜像更小

4. 支持大型系统与长期演进

• JDK 自身已模块化（java.base 等）
• 内部 API 被封锁
• 系统可以安全地重构内部结构

✅ 适合长期维护的项目

三、什么时候“应该”用 Module

✅ 适合：

• 大型系统 / 平台 / 框架
• 长期维护的核心系统
• 需要强封装和清晰边界的库
• 云原生、微服务、jlink 场景

❌ 不一定需要：

• 小工具 / 脚本
• 一次性项目
• 纯 Spring Boot 业务项目（可用可不用）

四、一句话总结

Java Module 的意义：把“隐式依赖 + 公开一切”变成“显式依赖 + 可控暴露”。

如果你愿意，我也可以：

• 用 Spring Boot + Module 示例说明
• 对比 Module vs Maven/Gradle 依赖
• 讲 为什么很多项目仍不用 Module