JPMS模块化迁移导致依赖冲突？jdeps分析自动模块与显式模块转换指南 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

JPMS 模块化迁移：依赖冲突分析与自动模块到显式模块转换指南

各位听众，大家好。今天我们来深入探讨一个在Java平台模块系统 (JPMS) 迁移过程中经常遇到的挑战：依赖冲突，以及如何利用 jdeps 工具进行分析并指导自动模块到显式模块的转换。

一、JPMS 模块化迁移的必要性与挑战

Java 9 引入了 JPMS，旨在通过模块化增强Java平台的安全性、可维护性和性能。模块化将代码组织成独立的、声明依赖关系的单元，从而避免了类路径带来的诸多问题，例如版本冲突和隐藏依赖。

然而，将现有的基于类路径的大型项目迁移到JPMS模块化是一项复杂的任务。这主要因为：

隐式依赖关系: 旧项目通常依赖于类路径的隐式行为，即任何类都可以在任何地方访问。模块化要求显式声明依赖关系，这可能暴露出之前未被察觉的依赖。
版本冲突: 类路径上可能存在同一库的不同版本，导致运行时错误。模块化通过强制版本声明可以解决这个问题，但也需要在迁移过程中进行仔细的依赖管理。
自动模块的局限性: 为了简化迁移，JPMS 允许将非模块化的 JAR 包作为“自动模块”使用。但自动模块会暴露其所有类，可能导致不必要的依赖，并且不能充分利用模块化的优势。

二、依赖冲突的根源与表现形式

在 JPMS 模块化迁移中，依赖冲突主要表现为以下几种形式：

模块加载冲突 (Module-path Conflicts): 两个或多个模块尝试定义相同的包。这将导致 java.lang.LayerInstantiationException: Package <package_name> in module <module_name1> is also defined in module <module_name2> 异常。
版本冲突 (Version Conflicts): 一个模块依赖于一个库的特定版本，而另一个模块依赖于同一库的不同版本。这可能导致 java.lang.IllegalAccessError 或 java.lang.NoSuchMethodError 异常，具体取决于冲突的版本差异。
循环依赖 (Cyclic Dependencies): 模块 A 依赖于模块 B，而模块 B 又依赖于模块 A。JPMS 不允许循环依赖，因为这会导致模块初始化问题。
隐式依赖暴露 (Implicit Dependency Exposure): 自动模块暴露了所有类，这可能导致模块依赖于不应该依赖的内部类或 API。

三、jdeps 工具：依赖分析与冲突诊断

jdeps (Java Dependency Analysis Tool) 是 JDK 自带的一个命令行工具，用于分析 Java 类文件的依赖关系。它可以帮助我们识别模块化迁移中的潜在问题，例如隐式依赖、版本冲突和循环依赖。

基本用法:

jdeps <options> <input-files>

其中 <input-files> 可以是类文件、JAR 文件或目录。<options> 是一些控制 jdeps 行为的选项。

常用选项:

选项	描述
`-s`	打印依赖关系的摘要信息。
`-R`	递归分析依赖关系。
`--module-path <path>`	指定模块路径。
`--class-path <path>`	指定类路径。
`--multi-release <version>`	指定多版本 JAR 的版本。
`--require-module <module>`	仅分析依赖于指定模块的类。
`--list-deps`	列出所有依赖的模块。
`--generate-module-info <dir>`	生成模块描述符文件 (`module-info.java`) 的模板。
`--dot-output <dir>`	生成依赖关系的 Graphviz DOT 文件，用于可视化。
`--summary`	生成一个简单的依赖关系摘要。

分析自动模块的依赖关系:

假设我们有一个名为 legacy.jar 的非模块化 JAR 文件，我们想了解它的依赖关系：
```
jdeps -s legacy.jar
```
输出可能如下：
```
legacy.jar -> java.base
legacy.jar -> com.example.utils (自动模块)
legacy.jar -> org.apache.commons.lang3 (自动模块)
```
这表明 legacy.jar 依赖于 java.base 模块以及两个自动模块 com.example.utils 和 org.apache.commons.lang3。
识别潜在的冲突:

如果我们想知道 legacy.jar 具体依赖了 org.apache.commons.lang3 中的哪些类，可以使用 -R 选项进行递归分析：
```
jdeps -R legacy.jar
```
输出会列出 legacy.jar 中所有依赖的类，以及它们所依赖的模块或 JAR 文件。通过分析这些依赖关系，我们可以识别潜在的版本冲突或隐式依赖。例如，如果 legacy.jar 依赖于 org.apache.commons.lang3 的一个特定版本，而另一个模块依赖于另一个版本，那么就会发生版本冲突。

四、自动模块到显式模块的转换

将自动模块转换为显式模块是 JPMS 迁移的关键一步。这可以提高代码的清晰度、可维护性和安全性。

创建 module-info.java 文件:

首先，我们需要创建一个 module-info.java 文件，用于描述模块的名称、依赖关系和导出的包。
```
module com.example.utils {
    requires java.base; // 显式声明对 java.base 的依赖
    exports com.example.utils.api; // 导出 API 包
    //opens com.example.utils.internal to other.module; // 打开内部包供反射访问
}
```
- module <module_name>：定义模块的名称。
- requires <module_name>：声明对其他模块的依赖。
- exports <package_name>：导出包，允许其他模块访问其中的 public 类型。
- opens <package_name> to <module_name>：打开包，允许其他模块通过反射访问其中的所有类型（包括 private 类型）。
使用 jdeps 生成 module-info.java 模板:

jdeps 可以帮助我们生成 module-info.java 文件的初始模板。
```
jdeps --generate-module-info . legacy.jar
```
这将在当前目录下生成一个 module-info.java 文件，其中包含根据 legacy.jar 的依赖关系推断出的 requires 和 exports 声明。

注意: jdeps 生成的模板可能不完整或不准确，需要手动进行调整。
精简 requires 声明:

jdeps 生成的 requires 声明可能包含不必要的依赖。我们需要仔细检查这些声明，并删除那些实际上没有使用的依赖。这有助于减少模块的依赖关系，提高代码的清晰度。

示例:

假设 jdeps 生成了以下 requires 声明：
```
module com.example.utils {
    requires java.base;
    requires java.sql;
    requires java.xml;
}
```
如果我们确定 com.example.utils 实际上没有使用 java.sql 和 java.xml 中的任何类，我们可以删除这些 requires 声明：
```
module com.example.utils {
    requires java.base;
}
```
控制 API 的可见性:

模块化允许我们控制 API 的可见性，只导出必要的包。这可以提高代码的安全性，防止外部模块访问内部实现细节。

示例:

假设 com.example.utils 包含以下包：
- com.example.utils.api：包含公共 API。
- com.example.utils.internal：包含内部实现细节。
我们应该只导出 com.example.utils.api 包：
```
module com.example.utils {
    requires java.base;
    exports com.example.utils.api;
}
```
这样，外部模块只能访问 com.example.utils.api 中的 public 类型，而无法访问 com.example.utils.internal 中的任何类型。
处理反射访问:

如果模块需要通过反射访问其他模块的内部类型，可以使用 opens ... to 声明。

示例:

假设 com.example.utils 需要通过反射访问 org.example.service 模块的 org.example.service.internal 包中的类型：
```
module com.example.utils {
    requires java.base;
    exports com.example.utils.api;
    opens com.example.utils.internal to org.example.service; // 允许 org.example.service 反射访问 com.example.utils.internal
}
```
编译模块:

创建 module-info.java 文件后，我们需要使用 javac 命令编译模块。
```
javac -d <output_dir> <source_files> module-info.java
```
其中 <output_dir> 是输出目录，<source_files> 是 Java 源代码文件。
创建模块化 JAR 文件:

编译成功后，我们可以使用 jar 命令创建一个模块化 JAR 文件。
```
jar --create --file <module_name>.jar --module-version <version> -C <output_dir> .
```
其中 <module_name> 是模块的名称，<version> 是模块的版本，<output_dir> 是编译输出目录。

五、解决依赖冲突的策略

在模块化迁移过程中，不可避免地会遇到依赖冲突。以下是一些解决依赖冲突的策略：

统一版本: 尽可能使用同一库的相同版本。这可以通过升级或降级某些库的版本来实现。

排除依赖: 如果两个模块依赖于同一库的不同版本，但其中一个模块实际上并不需要该库的特定版本，可以排除该模块的依赖。
Maven:

<dependency>
    <groupId>com.example</groupId>
    <artifactId>module-a</artifactId>
    <version>1.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Gradle:

dependencies {
    implementation('com.example:module-a:1.0') {
        exclude group: 'org.apache.commons', module: 'commons-lang3'
    }
}

使用模块路径隔离: 如果无法统一版本或排除依赖，可以将冲突的库放在不同的模块路径中，并使用不同的模块加载器加载它们。这可以防止它们之间的冲突，但这会增加代码的复杂性。
拆分模块: 如果一个模块依赖于多个库，并且这些库之间存在冲突，可以将该模块拆分成多个更小的模块，每个模块只依赖于一部分库。
重构代码: 如果依赖冲突是由于代码设计不合理造成的，可以重构代码，减少模块之间的依赖关系。

六、最佳实践

从小处着手: 从较小的、依赖关系简单的模块开始迁移，逐步扩展到整个项目。
自动化测试: 在迁移过程中，进行充分的自动化测试，确保代码的正确性和兼容性。
持续集成: 将模块化迁移纳入持续集成流程，尽早发现和解决问题。
详细记录: 记录迁移过程中的所有步骤和遇到的问题，以便将来参考。

七、案例分析

假设我们有一个项目，其中包含两个模块：module-a 和 module-b。module-a 依赖于 org.apache.commons.lang3 的 3.0 版本，而 module-b 依赖于 org.apache.commons.lang3 的 4.0 版本。

module-a (requires [email protected])
module-b (requires [email protected])

使用 jdeps 分析依赖关系:
```
jdeps --module-path <module_path> --list-deps module-a.jar module-b.jar
```
这将列出 module-a 和 module-b 的所有依赖关系，包括 org.apache.commons.lang3 的不同版本。
尝试统一版本:

如果可能，尝试将 module-a 或 module-b 升级或降级到 org.apache.commons.lang3 的同一版本。
如果无法统一版本，则尝试排除依赖:

如果 module-a 或 module-b 实际上并不需要 org.apache.commons.lang3 的所有功能，可以尝试排除该模块的依赖。
如果仍然无法解决冲突，则使用模块路径隔离:

将 org.apache.commons.lang3 的 3.0 版本和 4.0 版本放在不同的目录中，并使用不同的模块路径加载 module-a 和 module-b。

八、实战代码示例

以下是一个简单的 module-info.java 文件示例，展示了如何声明依赖关系、导出包和处理反射访问：

module com.example.app {
    requires com.example.library; // 依赖于 com.example.library 模块
    requires java.sql; // 依赖于 java.sql 模块
    requires transitive org.slf4j; // 传递依赖于 org.slf4j 模块 (任何依赖 com.example.app 的模块都会自动依赖 org.slf4j)

    exports com.example.app.api; // 导出 API 包

    opens com.example.app.internal to com.example.library; // 允许 com.example.library 通过反射访问 internal 包
    uses com.example.app.spi.MyService; // 声明使用 SPI 接口

    provides com.example.app.spi.MyService with com.example.app.impl.MyServiceImpl; // 提供 SPI 接口的实现
}

九、总结

JPMS 模块化迁移是一项重要的任务，可以提高 Java 项目的安全性、可维护性和性能。理解依赖冲突的根源，熟练使用 jdeps 工具进行分析，并掌握自动模块到显式模块的转换方法，是成功完成迁移的关键。通过统一版本、排除依赖、模块路径隔离等策略，可以有效解决依赖冲突，确保项目的稳定性和兼容性。

十、模块化迁移的要点

JPMS模块化转型是复杂的过程，务必从小处着手逐步迁移，并通过自动化测试保证质量。
依赖冲突是常见问题，需要深入分析和合理解决，最终享受模块化带来的优势。
jdeps工具是强大的辅助工具，可以帮助开发者分析和诊断依赖关系。

JPMS 模块化迁移：依赖冲突分析与自动模块到显式模块转换指南

发表回复 取消回复

发表回复取消回复