本文详解如何在 JDK 17+ 环境中通过正确配置 Maven Surefire 和 Compiler 插件，解决因模块封装导致的 InaccessibleObjectException 测试失败问题，确保 --add-opens JVM 参数被可靠传递至测试执行进程。

本文详解如何在 jdk 17+ 环境中通过正确配置 maven surefire 和 compiler 插件，解决因模块封装导致的 `inaccessibleobjectexception` 测试失败问题，确保 `--add-opens` jvm 参数被可靠传递至测试执行进程。

从 JDK 9 引入模块系统（JEP 261）起，Java 对反射访问施加了严格限制；升级到 JDK 17 后，java.base 等核心模块默认不再向未命名模块（如传统 classpath 应用）开放内部包。因此，当测试代码（尤其是使用 Mockito、JUnit 5 反射机制或某些 ORM/序列化库）尝试访问 java.lang.Object.clone() 或 java.util.concurrent 中受保护成员时，便会抛出：

java.lang.reflect.InaccessibleObjectException: 
Unable to make protected native java.lang.Object java.lang.Object.clone() 
throws java.lang.CloneNotSupportedException accessible: 
module java.base does not "opens java.lang" to unnamed module

虽然在 IntelliJ 中可通过测试运行配置手动添加 --add-opens 参数临时绕过，但该设置仅作用于 IDE 运行环境，对 Maven 构建完全无效。关键在于：Maven Surefire 插件必须显式将这些 JVM 参数注入测试 fork 进程，且需与编译阶段协同——否则编译器可能因缺少模块权限而无法生成兼容字节码。

✅ 正确配置 Surefire 插件（核心修复）

<argline></argline> 必须作为 <configuration></configuration> 的直接子元素，并使用多行格式清晰声明所有 --add-opens 项（避免单行拼接导致空格解析异常）。同时建议移除冗余配置（如默认生效的 <includes></includes>），并确保插件版本 ≥ 3.0.0（推荐 3.1.2+）：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.1.2</version>
  <configuration>
    <skipTests>${skip.surefire.integration.tests}</skipTests>
    <forkCount>10</forkCount>
    <reuseForks>false</reuseForks>
    <argLine>
      --add-opens java.base/java.lang=ALL-UNNAMED
      --add-opens java.base/java.lang.reflect=ALL-UNNAMED
      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
      --add-opens java.base/java.util=ALL-UNNAMED
      <!-- 如需其他包（如 java.time、java.net），按相同格式追加 -->
      --add-opens java.base/java.time=ALL-UNNAMED
    </argLine>
  </configuration>
</plugin>

⚠️ 注意：<argline></argline> 内容会完全覆盖 Surefire 默认参数，因此若需保留 -Dfile.encoding=UTF-8 等通用选项，应一并写入。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

✅ 同步配置 Compiler 插件（预防性加固）

仅配置 Surefire 可能不够——若项目使用注解处理器（如 Lombok）、或依赖反射生成的字节码（如某些代理框架），编译阶段同样需要模块开放权限。此时需在 maven-compiler-plugin 中通过 <compilerargs></compilerargs> 传入等效参数：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.11.0</version>
  <configuration>
    <source>17</source>
    <target>17</target>
    <compilerArgs>
      <arg>--add-opens</arg>
      <arg>java.base/java.lang=ALL-UNNAMED</arg>
      <arg>--add-opens</arg>
      <arg>java.base/java.lang.reflect=ALL-UNNAMED</arg>
      <arg>--add-opens</arg>
      <arg>java.base/java.util.concurrent=ALL-UNNAMED</arg>
      <arg>--add-opens</arg>
      <arg>java.base/java.util=ALL-UNNAMED</arg>
    </compilerArgs>
  </configuration>
</plugin>

? 提示：<compilerargs></compilerargs> 使用 <arg></arg> 标签分项声明，确保每个 --add-opens 及其值作为独立参数传递给 javac，避免 shell 解析错误。

? 高级建议与排查要点

• 验证参数是否生效：运行 mvn test -X 查看 Surefire 日志，搜索 Running with Java version 和 argLine 输出，确认参数已注入。
• 模块化项目（module-info.java）：若项目已定义模块，应改用 requires + opens/exports 声明替代 --add-opens，例如：

  module my.app {
      requires java.base;
      opens java.lang to org.junit.jupiter.api;
      opens java.util to org.mockito;
  }

• 依赖升级优先：部分旧版测试库（如 Mockito Mockito 5+、JUnit 5.10+，它们已内置模块适配逻辑。
• 避免过度开放：生产环境慎用 ALL-UNNAMED，可精确指定目标模块名（如 --add-opens java.base/java.lang=org.mockito），提升安全性。

完成上述配置后，执行 mvn clean test 即可成功运行测试。此方案兼顾构建可重现性与跨环境一致性，是 JDK 17+ 迁移中处理模块反射限制的标准实践。