一、为什么我们需要模块化系统

在软件开发的世界里，项目规模越来越大，代码库越来越复杂。想象一下，你正在维护一个庞大的Java项目，里面有成百上千个类，依赖关系错综复杂。这时候，你会发现：

  • 依赖地狱：A模块依赖B模块，B又依赖C，而C又偷偷依赖了A，形成循环依赖，编译都过不了。
  • 类路径污染：不同版本的jar包在类路径里打架，运行时莫名其妙报NoSuchMethodError。
  • 启动缓慢：JVM启动时要加载一堆用不到的类，内存浪费严重。

这时候，Java 9带来的JPMS（Java Platform Module System，也叫Jigsaw）就像救世主一样出现了。它让Java代码可以像乐高积木一样，明确声明依赖关系，按需加载，避免混乱。

二、JPMS的核心概念

JPMS引入了几个关键概念：

  1. 模块（Module）：一个带有module-info.java的代码单元，明确声明自己需要什么（requires）以及对外暴露什么（exports）。
  2. 模块路径（Module Path）：替代传统的类路径（Classpath），让JVM能精准找到模块。
  3. 封装强化：默认情况下，模块内部的类对外不可见，除非显式exports。

来看一个简单的模块定义示例（技术栈：Java 11+）：

// 模块定义文件：module-info.java
module com.example.user {      // 定义模块名
    requires java.logging;     // 声明依赖JDK内置模块
    requires com.example.utils; // 依赖另一个自定义模块
    exports com.example.user.api; // 对外暴露的包
}

这个模块声明了它需要java.logging和com.example.utils，同时只对外暴露com.example.user.api包下的类。

三、迁移实战：从传统项目到模块化

假设我们有一个传统Maven项目，结构如下：

legacy-project/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   ├── com/
│   │   │   │   ├── service/
│   │   │   │   ├── dao/
│   │   │   │   └── util/
│   │   └── resources/
├── pom.xml

步骤1：分析现有依赖

首先用Maven命令生成依赖树：

mvn dependency:tree

找出哪些是必须的，哪些可以剔除。比如发现commons-lang3和guava功能重叠，可以保留一个。

步骤2：拆分模块

按功能划分模块，比如：

modern-project/
├── user-service/
│   ├── src/
│   │   ├── main/
│   │   │   ├── java/
│   │   │   │   ├── com/
│   │   │   │   │   ├── user/
│   │   │   │   │   └── module-info.java
│   ├── pom.xml
├── order-service/
│   └── ...类似结构...

每个子模块的module-info.java明确定义边界：

// user-service模块定义
module com.example.user {
    requires transitive com.example.common; // 传递依赖
    exports com.example.user.service;
}

步骤3：处理反射和隐式依赖

传统项目常用反射（如Spring），但JPMS默认禁止跨模块反射。解决方案：

  1. 对需要反射的包添加opens：
module com.example.user {
    opens com.example.user.internal; // 允许反射访问
}
  1. 或用命令行参数--add-opens临时放宽限制（不推荐长期使用）。

四、踩坑与最佳实践

坑1：自动模块的陷阱

如果依赖的jar没有模块化，JPMS会将其转为"自动模块"（模块名取自文件名）。这可能导致问题：

  • 文件名变更导致模块名变化
  • 隐式依赖不可控

建议：逐步推动关键依赖库升级为显式模块。

坑2：IDE配置

IntelliJ IDEA对JPMS支持较好，但需注意：

  1. 确保项目SDK版本≥9
  2. 模块路径配置正确，避免和类路径混用

最佳实践

  1. 渐进式迁移：先选一个非核心模块试点。
  2. 分层设计：
    • 顶层模块（如app）聚合子模块
    • 底层模块（如common）减少对外暴露
  3. 工具辅助： 
    jdeps --generate-module-info ./out my-library.jar
    用jdeps分析已有jar包的模块化可行性。

五、总结：模块化的收益与代价

优点

  • 依赖清晰化：再也不用猜某个类是从哪个jar包来的了。
  • 启动优化：JVM可以仅加载必要的模块，提升速度。
  • 安全增强：默认封装减少了意外API暴露。

缺点

  • 迁移成本高：尤其是对老旧项目或重度依赖反射的框架（如Spring）。
  • 生态适配：部分库尚未提供模块化版本。

适用场景

  • 新项目：强烈推荐从一开始就用JPMS。
  • 大型遗留系统：建议分模块逐步迁移，配合CI/CD验证。

最终，模块化不是银弹，但它为Java的大规模工程化提供了必不可少的基石。就像整理一间杂乱的书房——刚开始很痛苦，但整理完后，找书的速度快多了！