Error-Prone 在 Maven 项目中的 JPMS 模块系统集成问题解析

问题背景

Error-Prone 作为 Java 编译时静态分析工具，在现代 Java 开发中扮演着重要角色。然而，当开发者尝试在 Maven 项目中结合 Java 平台模块系统(JPMS)使用 Error-Prone 时，经常会遇到模块访问权限问题。本文将以一个典型场景为例，深入分析问题原因并提供解决方案。

典型错误现象

开发者在使用 Maven 构建项目时，可能会遇到如下错误信息：

java.lang.IllegalAccessError: class com.google.errorprone.BaseErrorProneJavaCompiler 
(in unnamed module @0x1f15e689) cannot access class com.sun.tools.javac.api.BasicJavacTask 
(in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.api to unnamed module @0x1f15e689

这个错误表明 Error-Prone 编译器无法访问 JDK 编译器内部 API，因为 JPMS 默认限制了这些内部 API 的访问权限。

问题根源分析

1. 模块系统限制：Java 9 引入的模块系统加强了对内部 API 的访问控制，jdk.compiler 模块没有向未命名模块(unnamed module)开放必要的包。

2. Maven 构建特性：Maven 编译器插件默认在同一个 JVM 进程中运行，导致无法动态修改模块访问权限。

3. Error-Prone 实现依赖：Error-Prone 需要访问 JDK 编译器的内部 API 来实现其功能，这与 JPMS 的强封装性产生了冲突。

解决方案详解

方案一：使用 Maven 编译器插件的 fork 模式

在 Maven 编译器插件配置中启用 fork 模式，并添加必要的模块导出参数：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.13.0</version>
  <configuration>
    <fork>true</fork> <!-- 关键：启用 fork 模式 -->
    <compilerArgs>
      <arg>-XDcompilePolicy=simple</arg>
      <arg>-Xplugin:ErrorProne</arg>
      <!-- 以下是必需的模块访问权限配置 -->
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
      <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
      <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
      <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
    </compilerArgs>
  </configuration>
</plugin>

方案二：使用 .mvn/jvm.config 全局配置

在项目根目录下创建 .mvn/jvm.config 文件，添加以下内容：

--add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED

技术要点解析

1. fork 模式的重要性：Maven 编译器插件默认在同一个 JVM 进程中运行，无法修改已经启动的 JVM 模块配置。启用 fork 模式后，会启动新的 JVM 进程，此时可以传递模块系统参数。

2. add-exports vs add-opens：

   • --add-exports：允许其他模块访问指定包中的公共类型
   • --add-opens：允许其他模块通过反射访问指定包中的所有类型（包括非公共类型）

3. Error-Prone 的特殊需求：Error-Prone 需要访问 JDK 编译器的内部 API 来实现代码分析和转换功能，这与常规应用程序开发不同，需要特殊的模块系统配置。

常见问题排查

1. 配置无效：确保使用的是 fork 模式，否则模块参数不会被应用。

2. 测试编译失败：当主代码不是模块化代码时，测试编译可能会失败。可以尝试：

   • 为主代码添加 module-info.java
   • 或者禁用模块路径：<useModulePath>false</useModulePath>

3. 参数格式错误：确保参数格式正确，特别是 -J 前缀和 = 符号的使用。

最佳实践建议

1. 统一配置管理：对于多模块项目，建议在父 POM 的 pluginManagement 中统一配置 Error-Prone 和模块参数。

2. 版本兼容性：确保使用的 Error-Prone 版本与 JDK 版本兼容，较新的 Error-Prone 版本通常会更好地支持新 JDK 特性。

3. 渐进式迁移：对于大型项目，可以先在部分模块启用 Error-Prone，逐步扩展到整个项目。

通过以上分析和解决方案，开发者可以顺利地在 Maven 项目中结合 JPMS 使用 Error-Prone，享受其强大的静态分析能力，同时遵循现代 Java 模块化开发的规范。