Java 9 模块系统（JPMS）入门：构建更加清晰和可维护的项目结构

引言

Java 9 引入了模块系统（Java Platform Module System, JPMS），这是自 Java 语言诞生以来最重大的一次架构变革。模块系统的目标是为 Java 提供一种更强大、更灵活的方式来组织代码，使得项目的结构更加清晰，依赖关系更加明确，从而提高代码的可维护性和安全性。通过模块化，开发者可以更好地控制哪些类和包是公开的，哪些是私有的，从而避免不必要的耦合和潜在的安全风险。

本文将深入探讨 Java 9 模块系统的概念、语法、使用方法，并通过具体的代码示例展示如何在实际项目中应用模块化技术。我们将从模块的基本概念出发，逐步介绍模块声明、模块依赖、服务提供者等核心特性，并结合实际案例分析模块化带来的好处。

1. 模块系统的基本概念

1.1 什么是模块？

在 Java 9 之前，Java 项目通常由多个包（package）组成，而这些包之间并没有严格的访问控制机制。所有的类都可以通过 import 语句相互引用，这虽然提供了灵活性，但也带来了许多问题，例如：

• 全局可见性：所有公共类都对整个应用程序可见，可能导致不必要的依赖和耦合。
• 缺乏封装性：无法有效地隐藏实现细节，外部代码可以随意访问内部类和方法。
• 类路径混乱：随着项目的规模增大，类路径（classpath）可能会变得非常复杂，导致类加载冲突或找不到类的问题。

为了应对这些问题，Java 9 引入了模块系统。模块是一个更高层次的封装单元，它不仅包含多个包，还定义了模块之间的依赖关系和访问权限。每个模块都有一个唯一的名称，并且可以通过 module-info.java 文件声明其导出的包和依赖的其他模块。

1.2 模块与包的区别

特性	包（Package）	模块（Module）
封装级别	包内的类默认对同一包内的类可见	模块内的包默认对外部模块不可见
访问控制	只能通过 public 关键字控制类的可见性	通过 exports 声明控制包的可见性
依赖管理	无显式的依赖声明	通过 requires 声明显式的依赖关系
命名空间	局部命名空间，可能存在冲突	全局命名空间，模块名称必须唯一

1.3 模块化的优点

• 更好的封装性：模块可以严格控制哪些包和类对外部可见，避免不必要的暴露。
• 显式的依赖声明：模块之间的依赖关系是显式声明的，避免了隐式的类路径依赖，减少了类加载冲突的可能性。
• 更强的安全性：模块化系统可以防止外部代码随意访问模块的内部实现，增强了代码的安全性。
• 更好的性能：模块化系统可以在启动时进行优化，减少类加载的时间，提升应用程序的启动速度。

2. 模块声明与模块信息文件

2.1 module-info.java 文件

每个模块的核心是 module-info.java 文件，它是模块的入口点，定义了模块的名称、导出的包、依赖的其他模块以及其他配置信息。module-info.java 文件必须位于模块的根目录下，并且只能有一个。

以下是一个简单的 module-info.java 文件示例：

module com.example.myapp {
    // 导出 com.example.myapp.api 包
    exports com.example.myapp.api;

    // 依赖 java.sql 模块
    requires java.sql;

    // 依赖第三方模块 com.thirdparty.library
    requires com.thirdparty.library;
}

2.2 模块名称

模块名称必须是唯一的，并且遵循 Java 包命名规则，通常以域名反向表示法命名。例如，com.example.myapp 是一个有效的模块名称。模块名称的唯一性确保了不同模块之间的冲突不会发生。

2.3 导出包（Exports）

exports 语句用于声明模块中的哪些包可以被其他模块访问。默认情况下，模块中的包是私有的，只有通过 exports 声明的包才能被外部模块使用。

module com.example.myapp {
    // 导出 com.example.myapp.api 包
    exports com.example.myapp.api;

    // 导出 com.example.myapp.util 包，但只对特定模块可见
    exports com.example.myapp.util to com.example.anothermodule;
}

在上面的例子中，com.example.myapp.api 包对所有模块可见，而 com.example.myapp.util 包只对 com.example.anothermodule 可见。这种细粒度的控制可以有效减少不必要的依赖，增强模块的封装性。

2.4 依赖模块（Requires）

requires 语句用于声明模块依赖的其他模块。依赖的模块必须存在于类路径或模块路径中，否则编译时会报错。

module com.example.myapp {
    // 依赖 java.sql 模组
    requires java.sql;

    // 依赖第三方模块 com.thirdparty.library
    requires com.thirdparty.library;

    // 依赖可选模块，如果不存在也不会报错
    requires static com.optional.module;
}

requires static 表示该依赖是可选的，即使目标模块不存在，编译也不会失败。这在处理可选功能或插件时非常有用。

2.5 使用模块

一旦模块声明完成，其他模块可以通过 import 语句使用该模块中导出的包。例如，假设我们有两个模块 com.example.myapp 和 com.example.anothermodule，其中 com.example.myapp 导出了 com.example.myapp.api 包，那么 com.example.anothermodule 可以通过以下方式使用该包：

// com.example.anothermodule 中的代码
import com.example.myapp.api.MyClass;

public class AnotherClass {
    public void doSomething() {
        MyClass myObject = new MyClass();
        // 使用 MyClass 的功能
    }
}

3. 模块依赖与传递依赖

3.1 直接依赖与传递依赖

在模块化系统中，模块之间的依赖关系可以分为直接依赖和传递依赖。直接依赖是指模块显式声明的依赖，而传递依赖是指通过依赖的模块间接引入的依赖。

例如，假设我们有三个模块 A、B 和 C，其中 A 依赖 B，B 依赖 C。在这种情况下，A 对 C 的依赖是传递依赖。

// 模块 A
module com.example.moduleA {
    requires com.example.moduleB;
}

// 模块 B
module com.example.moduleB {
    requires com.example.moduleC;
}

// 模块 C
module com.example.moduleC {
    exports com.example.moduleC.api;
}

3.2 传递依赖的作用域

默认情况下，传递依赖是不可见的。也就是说，A 不能直接使用 C 中的类，除非 B 显式地将 C 中的包导出给 A。要使传递依赖可见，可以在 B 的 module-info.java 文件中使用 exports ... to 语句。

// 模块 B
module com.example.moduleB {
    requires com.example.moduleC;
    exports com.example.moduleC.api to com.example.moduleA;
}

通过这种方式，A 可以访问 C 中的 com.example.moduleC.api 包，而不需要直接依赖 C。

3.3 传递依赖的优势

传递依赖的一个重要优势是减少了模块之间的直接依赖，降低了模块之间的耦合度。通过合理的传递依赖管理，可以简化模块的依赖关系，使项目的结构更加清晰。

4. 服务提供者与服务使用者

4.1 什么是服务提供者？

服务提供者（Service Provider）是模块化系统中的一个重要概念，它允许模块之间通过接口进行松耦合的协作。服务提供者模式的核心思想是将接口与实现分离，模块只需要依赖接口，而不关心具体的实现类。

例如，假设我们有一个 Logger 接口，不同的模块可以提供不同的 Logger 实现（如 FileLogger、ConsoleLogger 等）。通过服务提供者机制，模块可以在运行时动态选择合适的 Logger 实现，而不需要硬编码具体的类名。

4.2 定义服务接口

首先，我们需要定义一个服务接口。这个接口将作为服务提供者的契约，所有服务提供者都必须实现该接口。

// com.example.logging.Logger.java
package com.example.logging;

public interface Logger {
    void log(String message);
}

4.3 注册服务提供者

接下来，我们需要在模块中注册服务提供者。服务提供者必须实现服务接口，并在模块的 module-info.java 文件中使用 provides 语句声明。

// com.example.filelogger.FileLogger.java
package com.example.filelogger;

import com.example.logging.Logger;

public class FileLogger implements Logger {
    @Override
    public void log(String message) {
        // 将日志写入文件
        System.out.println("Writing to file: " + message);
    }
}

// module-info.java
module com.example.filelogger {
    requires com.example.logging;

    // 提供 com.example.logging.Logger 服务
    provides com.example.logging.Logger with com.example.filelogger.FileLogger;
}

4.4 使用服务提供者

最后，服务使用者可以通过 ServiceLoader 类来查找并使用服务提供者。ServiceLoader 会自动扫描所有已加载的模块，并返回实现了指定接口的服务提供者实例。

// com.example.app.Main.java
package com.example.app;

import com.example.logging.Logger;
import java.util.ServiceLoader;

public class Main {
    public static void main(String[] args) {
        ServiceLoader<Logger> loader = ServiceLoader.load(Logger.class);
        for (Logger logger : loader) {
            logger.log("Hello, World!");
        }
    }
}

4.5 服务提供者的优势

服务提供者模式的最大优势在于它实现了接口与实现的解耦，使得模块之间的依赖更加灵活。通过服务提供者机制，模块可以在不修改代码的情况下动态替换实现类，增强了系统的可扩展性和可维护性。

5. 模块化项目的构建与部署

5.1 构建工具支持

为了支持模块化项目，主流的构建工具（如 Maven 和 Gradle）都提供了对模块系统的支持。在 Maven 中，我们可以通过 pom.xml 文件中的 module-info.java 配置来声明模块信息。同样，Gradle 也提供了类似的配置选项。

以下是 Maven 项目中 pom.xml 的示例：

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>myapp</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>9</maven.compiler.source>
        <maven.compiler.target>9</maven.compiler.target>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <release>9</release>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

5.2 模块路径与类路径

在模块化项目中，类路径（classpath）和模块路径（modulepath）的概念有所不同。类路径用于加载传统的非模块化类库，而模块路径用于加载模块化的 JAR 文件。为了确保模块化项目的正确运行，必须正确配置模块路径和类路径。

例如，在命令行中运行模块化应用程序时，可以使用 --module-path 参数指定模块路径：

java --module-path mods -m com.example.myapp/com.example.myapp.Main

5.3 模块化 JAR 文件

模块化 JAR 文件与传统的 JAR 文件不同，它包含了 module-info.class 文件，描述了模块的元数据。生成模块化 JAR 文件时，编译器会自动将 module-info.java 编译为 module-info.class，并将其打包到 JAR 文件中。

javac -d out $(find src -name "*.java")
jar --create --file myapp.jar --main-class=com.example.myapp.Main -C out .

6. 模块化带来的挑战与解决方案

6.1 与现有项目的兼容性

对于已经存在的非模块化项目，迁移到模块化系统可能是一个复杂的任务。为了简化迁移过程，Java 9 提供了两种模式：模块路径模式和类路径模式。在类路径模式下，现有的项目可以继续正常运行，而无需进行任何修改。然而，为了充分利用模块化系统的优点，建议逐步将项目迁移到模块路径模式。

6.2 处理反射与模块化

模块化系统对反射的支持进行了限制，某些反射操作可能会受到模块边界的影响。例如，默认情况下，模块中的私有类和方法是无法通过反射访问的。为了绕过这些限制，可以使用 opens 语句将特定的包开放给反射。

module com.example.myapp {
    exports com.example.myapp.api;

    // 开放 com.example.myapp.impl 包给反射
    opens com.example.myapp.impl to java.base;
}

6.3 处理自动模块

自动模块（Automatic Module）是指那些没有 module-info.java 文件的 JAR 文件。Java 9 会自动将这些 JAR 文件视为模块，并根据 JAR 文件的名称推断模块名称。虽然自动模块可以简化迁移过程，但它们也有一些局限性，例如无法显式声明依赖关系。因此，建议尽量将自动模块转换为正式的模块。

结论

Java 9 模块系统（JPMS）为 Java 项目带来了全新的模块化方式，使得代码结构更加清晰，依赖关系更加明确，安全性更高。通过模块化，开发者可以更好地控制代码的可见性和依赖关系，减少不必要的耦合，提升项目的可维护性和扩展性。

尽管模块化系统的引入带来了一些新的挑战，但随着工具和框架的支持逐渐完善，越来越多的开发者已经开始受益于这一强大的功能。无论是新建项目还是现有项目的迁移，掌握模块化系统的使用方法都将为未来的开发工作打下坚实的基础。

希望本文能够帮助你更好地理解 Java 9 模块系统的核心概念和使用方法，并为你在实际项目中应用模块化技术提供有价值的参考。