当前位置：首页 > news >正文

Java：JPMS模块化开发

news 来源：原创 2025/5/14 6:40:41

JPMS（Java Platform Module System）简介

为什么用JPMS？

JPMS（Java 平台模块系统）是 Java 9 引入的模块化系统，也称为 Jigsaw 项目。它为 Java 提供了更精细的模块化机制，用于组织和管理代码，以解决 JAR 包管理的复杂性和依赖问题。

JAR包的问题

JAR包是早期Java组件化开发的核心构件,关于jar包的具体使用，不妨看看我的这篇文章Java：JAR包的创建、导入与运行-CSDN博客
在Java程序运行时，JVM会从JAR包中抽取所有类构成一张 “大表”，然后在这张大表中按顺序查找特定的类型。
因为一个类会从类路径中第一个包含它的JAR中加载，所以这个类会导致所有其他同名类不可用，这被称为覆盖
由于在类路径扫描中只有第一个搜索到的实例（它覆盖了所有其他实例）会被加载，所以JAR文件的扫描顺序决定了哪些代码会被执行。
这就导致了当两个类库分别依赖第三方类库的两个不兼容版本时，就会发生版本冲突。可能会导致加载意料之外的版本，或者是两个版本先后被混合加载。
在这里插入图片描述

默认情况下，诸如Maven这样的构建系统，会选择组件树中“最近的（closest）”的版本加载。
当类路径集合包容太多的文件夹，太多的JAR文件，管理和维护它们将变得极其复杂。

某个JAR依赖包缺失
某个JAR依赖包被多次包含，并且很可能以不同版本的形式被多次包含
JAR包依赖的传递性导致出现循环依赖
外部代码使用反射等技术访问JAR包中的非公有类型代码，导致升级和维护困难
较差的启动性能
如果某程序在运行时依赖于某个类，JVM的“类加载器（Class Loader）”是没办法知道它来自于哪个JAR的，所以它必须对类路径中的所有JAR都执行一次线性扫描，才能找到并加载这个类。
又比如，在程序运行时如果想知道有哪些类添加了特定的“注解（annotation）”，就需要调用反射技术查询类路径中的所有类。
由于JVM采用了“延迟加载类型”的策略，可能需要多次扫描类路径中的JAR包，这些都是耗时操作，所以，这也是“Java程序”启动慢、占用系统资源多的原因

为了维护JAR包之间复杂的组件依赖关系，人们先后发明了诸如Maven和Gradle这样的构建管理工具，自动管理一个项目所引用的Jar 包之间的依赖关系，但这些工具只能在开发与编译期间起作用，对运行时出现的各种情况，它们无能为力，还是没有从根本上解决问题。

因此，需要引入模块化技术

启动时就能发现模块的缺失问题而立即报错，不需要等到运行后，程序走到特定流程时才触发错误。
能明确地控制代码的可访问性，不希望开放的代码，外部就无法访问。
由于提前知道了许多信息，因此，有可能对其进行进一步的优化。
可定制运行时环境，目标计算机上不再需要安装完整版本的JRE，节约了磁盘空间。

JPMS模块化

模块化是将单体系统切分为多个小的相对独立的子系统的一种技术手段，每个切分出来的子系统，可以顺畅地进一步被重构和演化为微服务
在这里插入图片描述
对于小的应用来说，是否采用模块化，其实影响不大，但对于需要长期维护并且持续演化的信息系统来说，采用模块化，会带来明显的效益。

模块化开发：允许开发者将代码分割为模块，明确模块的边界。
依赖声明：定义模块之间的依赖关系，避免类路径冲突（“JAR Hell”）。
更小的运行时：支持创建自定义运行时，只包含应用程序所需的模块。
强封装：限制模块对其他模块内部实现的访问，提升安全性和代码维护性。

模块化和模块是不同的：
模块（module） 是包含代码的可识别Java软件构件，使用了元数据（metadata）来描述本模块及其与其他模块之间的依赖关系。你可以把模块看成是一组用于代码重用的包（package）。
模块化（ modularization） 是指将系统分解成独立且相互连接的模块的过程。

JPMS 的核心特性

模块名称：
- 每个模块必须具有唯一的全局名称，例如 java.base 或 com.example.myapp。
模块依赖：
- 使用 requires 语句显式声明模块间的依赖关系，避免隐藏的依赖。
导出包（Exported Package）：
- 模块通过 exports 语句显式声明对外暴露的包，其余包默认是不可见的。
- 解决了类访问范围过宽的问题。
强封装：
- 模块系统通过显式定义导入和导出的内容，防止包污染，提升了代码的安全性和可维护性。
运行时检查：
- 在程序运行时，JPMS 会验证模块间的依赖是否正确，进一步保障系统的稳定性。

**2. JPMS 的组织方式

类和包的模块化特性

类的模块化特性：类是 Java 系统最基础的构件，天然具有“模块化”的特性。通过结合接口，可以实现类的灵活替换和扩展，这为“基于代码重用”的开发模式奠定了基础。
包（Package）分类管理：
- 随着类数量的增加，Java 提供了 package 机制，将类按职责分类。
- 包不仅在逻辑上组织类，还通过访问控制（如 public 和 default）实现类的可见性控制。
JAR 包的物理封装：
- JAR（Java Archive）是 Java 项目中最基础的物理构件，可以包含多个包。
- 包与包之间的依赖关系，决定了 JAR 包之间的“依赖”关系。

构建工具与依赖管理

Maven 和 Gradle：
- 现代构建工具（如 Maven 和 Gradle）通过配置文件（pom.xml 或 build.gradle），解决了编译时 JAR 包依赖和版本管理问题。
- 依赖管理方式：
  1. 声明依赖关系（比如指定具体版本或范围）。
  2. 自动下载依赖及其传递性依赖。
- 局限性：
  - Maven 和 Gradle 的依赖管理主要针对编译时，运行时的依赖问题（例如冲突或循环依赖）需要额外处理。
  - 无法直接控制类的访问权限，容易导致包的污染。

模块（Module）

模块（Module）”是Java平台模块系统（JPMS）的基石。像JAR一样，模块也是类型和资源的容器，但相比JAR，它们还具有额外的特性：

必须有一个名称（全局唯一）
必须显式声明对其他模块的依赖；
定义了一个由导出包（exported package）构成的 “应用程序编程接口（API）”。

Java模块具有很强的封装性，即使是公有类型，如果它所在的包没有导出的话，外部是不能访问它们的。

–JAR 和 Module 的对比

特性	JAR（Java Archive）	Module（JPMS 模块）
基本单位	包含多个 `package`，每个 `package` 包含多个类。	同样包含多个 `package`，每个 `package` 包含多个类。
依赖关系管理	无法直接定义 JAR 包之间的依赖关系，只能通过外部工具（如 Maven 或 Gradle）进行依赖管理。	模块自带一个 `module-info.java` 配置文件，可显式定义模块之间的依赖关系（`requires`）。
依赖检查	依赖关系在运行时动态解析，如果无法满足依赖，会在运行时抛出异常，问题发现较晚。	编译时就能进行依赖关系检查，若模块依赖无法满足，编译器会报错，问题发现更早。运行时也会再次验证依赖关系，保障安全性。
访问控制	JAR 内部的 `public` 类对所有其他 JAR 可见，容易造成包污染，访问范围难以控制。	模块通过 `exports` 显式导出特定的包，其余包默认不可见，强封装性避免了包污染。
运行时依赖	无法检测未导入的类是否存在，运行时可能会因类不存在导致 `ClassNotFoundException`。	模块在运行时会验证模块依赖关系，若依赖缺失或冲突，会抛出异常，确保运行时安全。
开发工具支持	构建工具（如 Maven/Gradle）负责管理依赖，但只在编译阶段有效，运行时依赖需自行处理。	JPMS 原生支持模块化，统一管理编译时和运行时依赖，减少对第三方工具的依赖。
典型用途	传统 Java 项目和第三方库的打包与分发。	Java 9+ 项目的模块化开发，尤其是大型应用或需要高内聚的系统。

JAR 包适用于早期项目或简单的组件打包，依赖关系需要通过构建工具显式定义。
Module是对 JAR 的扩展，具备更强的依赖管理和封装能力，适合现代化、模块化开发需求。

在这里插入图片描述

JPMS 的优势

与 JAR 包的关系：
- 模块是 JAR 包的扩展形式，具有更强的封装性和依赖控制能力。
与构建工具的关系：
- JPMS 与 Maven 和 Gradle 无冲突，可以共同使用。构建工具负责依赖管理，JPMS 提供模块化控制。
与 OSGi 的关系：
- JPMS 是 JDK 原生支持的模块化方案，使用更简单、集成更深入，适用于绝大多数场景。

3. 模块化的JDK

在JDK 9之前，Java的运行时库（Runtime Library）由一个庞大的rt.jar所承载，其大小超过60MB，包含了Java大部分运行时类，它们是Java平台的最终载体。
从JDK 9开始，rt.jar 被打散为多个模块。
打散后的JDK模块，以.jmod作为文件扩展名。

模块化的JDK现在有一个jmods文件夹，里面包容了大量的“*.jmod”文件，这其实就是“打散”后的JDK模块。
这些jmod文件，被称为“平台模块”，它们一起构成了 JDK，整个Java软件开发与运行的平台。

在命令行中输入java --list-modules可以列出JDK（9以上版本）的模块清单

以“java.”打头的模块，都是 Java SE规范的一部分。
以“jdk.”开头的模块包含了JDK特定的代码，在不同的JDK实现中可能会有所不同。

在JDK 9以上的版本中，java和 javac等原有JDK命令行工具都针对模块进行了功能增强，添加了一些新的命令行参数，JDK中还添加了诸如jlink之类的新命令行工具。
平台模块间的依赖关系：
在这里插入图片描述
模块之间存在着“单向”依赖关系，Java模块系统不允许模块之间存在循环依赖。

Java Base 模块 (`java.base`)

核心模块：java.base 是 Java 平台最核心、最基础的模块，所有其他模块都直接或间接地依赖于 java.base。
默认依赖：所有 Java 应用默认都依赖于 java.base，并且无需显式声明这个依赖。因为 java.base 导出了 Java 核心类库（如 java.lang、java.util、java.io 等），所以你可以在 JDK 9 及以上版本中直接使用这些核心类，而不需要额外的配置或声明。
内容：java.base 模块包含了 JDK 中的基础类库，包括常用的基础类（如 String、Object、List 等）和 Java 基础的 IO 操作等。

Java SE 模块 (`java.se`)

聚合器模块：java.se 是一个 聚合器模块（aggregator module）。它并不包含具体的类实现，而是通过一组 requires 语句引入了 Java SE 平台的其他模块。换句话说，java.se 模块是将其他功能模块进行逻辑分组的容器。
目的：通过将多个模块组合到一个聚合器模块中，java.se 使得 Java SE 平台的模块化结构更加清晰，避免在 module-info.java 文件中列出大量的 requires 声明。
功能：它包含了构成 Java SE 平台的多个模块（如 java.base、java.sql、java.desktop 等），因此通过依赖 java.se，你可以方便地一次性引入所有 Java SE 标准模块，而无需显式声明每个模块的依赖。

Jmod 与 JAR 的区别

JAR（Java Archive）

定义：JAR 是一种文件格式，用于将 Java 类、资源文件等打包成一个单独的压缩文件。JAR 文件通常用于分发 Java 应用或库。
用途：JAR 文件是广泛用于 Java 项目中打包应用程序或库的标准格式。你可以将 Java 类、图像、配置文件等资源打包在一个 JAR 文件中，方便分发和部署。
独立性：JAR 文件是与模块化系统无关的，它不包含模块化信息，因此不支持模块化的构建与管理。

Jmod

定义：Jmod 是 Java 模块系统中的一种文件格式，它与 JAR 类似，但 Jmod 文件包含模块化信息，可以用于构建、分发和运行 Java 模块化应用。
用途：Jmod 文件通常用于构建 JDK 的模块化运行时环境。它不仅可以包含 Java 类，还包括其他文件（如配置文件、库文件等）和模块化元数据（如 module-info.class）。
jlink 使用：Jmod 文件并不能直接运行，它是为 jlink 工具设计的。jlink 会根据应用程序的需要，将 Jmod 文件中使用到的模块提取出来，生成一个定制化的、精简的 Java 运行时环境（JRE）。
特点：
- Jmod 文件用于创建可以独立运行的“运行时环境”。
- jlink 使用 Jmod 文件来构建一个包含所需模块的 JRE，而不包含无关的模块，从而生成一个体积小且精简的 JDK 环境。
- Jmod 文件并不需要目标计算机上安装特定版本的 JRE，因为它包含了应用运行所需的所有模块。

特性	JAR	Jmod
用途	主要用于打包 Java 应用和库	用于构建、分发和运行 Java 模块化应用
模块支持	不支持模块化	支持模块化，包含模块化元数据
是否可运行	JAR 文件可以直接运行（如果包含 `main` 方法）	Jmod 文件不能直接运行，必须通过 `jlink` 生成运行时环境
目标	用于标准 Java 应用的打包和分发	用于构建定制的 Java 运行时环境
生成工具	使用标准的构建工具（如 Maven、Gradle）生成	使用 `jlink` 工具生成精简版 JRE

4. 使用 JPMS 的基本步骤

`module-info.java` 文件**

这是 JPMS 的核心，用于声明模块。通常位于模块的根目录中。

关键语法：

module <模块名> {requires <依赖的模块名>;      // 声明依赖exports <导出的包名>;         // 声明对外公开的包opens <开放的包名>;           // 开放包供反射使用uses <服务接口>;              // 声明模块使用某服务provides <服务接口> with <实现类>; // 声明模块提供服务
}

示例：一个简单模块

假设我们有一个模块 com.example.hello，包含以下内容：

包名：com.example.hello
类：HelloWorld
模块结构：

com.example.hello/
├── module-info.java
└── com/example/hello/HelloWorld.java

代码示例：

module-info.java：

module com.example.hello {exports com.example.hello; // 对外暴露包
}

HelloWorld.java：

package com.example.hello;public class HelloWorld {public void sayHello() {System.out.println("Hello, JPMS!");}
}

常用模块声明

requires：声明模块依赖。

module my.module {requires java.base; // 默认模块，无需显式声明requires java.sql;
}

exports：声明模块中哪些包可以被外部使用。

module my.module {exports com.example.myapi; // 公开 API 包
}

opens：开放包供反射使用（如给 Jackson 或 Hibernate）。

module my.module {opens com.example.internal; // 只开放反射访问
}

uses 和 provides：用于服务加载机制（SPI）。

module my.module {uses com.example.Service; // 声明使用服务provides com.example.Service with com.example.impl.ServiceImpl; // 提供服务实现
}

JPMS 的核心概念

模块路径：
- 模块运行时位于模块路径上，而不是传统的类路径。
- 使用 --module-path（或 -p）指定模块路径。
模块的强封装：
- 默认情况下，模块中的包是私有的，只有通过 exports 明确导出的包才可被外部访问。
模块图：
- 模块之间的依赖形成一个有向无环图（DAG），避免循环依赖。

创建 module-info.java 文件。
在模块中组织代码和包。

编译模块：

javac --module-path mods -d out/com.example.hello $(find com.example.hello -name "*.java")

运行模块：

java --module-path out -m com.example.hello/com.example.hello.HelloWorld