Java 11项目中出现“JDK 9”相关错误的真相与修复指南-java教程-PHP中文网

Java 11项目中出现“JDK 9”相关错误的真相与修复指南

该错误并非环境配置错误，而是JMockit在Java 9+模块化（JPMS）环境下因JVM attach机制变更引发的运行时限制，需显式启用-Djdk.attach.allowAttachSelf或配置-javaagent才能正常工作。

该错误并非环境配置错误，而是jmockit在java 9+模块化（jpms）环境下因jvm attach机制变更引发的运行时限制，需显式启用`-djdk.attach.allowattachself`或配置`-javaagent`才能正常工作。

你看到的错误信息中反复出现的 “Running on JDK 9 requires…” 并非说明你的项目实际运行在Java 9——它是一个典型的语义泛化表达：JDK官方文档与第三方库（如JMockit）普遍用“JDK 9”代指 JDK 9 及更高版本（≥9），因为Java 9是Java平台模块系统（JPMS）和java.lang.instrument/com.sun.tools.attach行为变更的分水岭。

从堆栈可见，错误源头明确指向 jmockit-1.n.jar，且触发路径为JUnit Platform测试类处理器（JUnitPlatformTestClassProcessor），说明问题发生在测试执行阶段，而非编译或IDE配置阶段。这与你在IntelliJ中看到的Project SDK、Module Language Level、External Libraries等设置完全无关——那些只影响编译与代码提示，而该错误属于JVM启动参数缺失导致的运行时拒绝服务。

? 根本原因：JPMS对动态attach的严格限制

Java 9起，出于安全强化，默认禁止JVM通过com.sun.tools.attach API对自己（self-attach）或祖先进程进行动态代理注入。而JMockit高度依赖此机制实现无侵入式Mock（如@Mocked、@Injectable）。因此，即使你使用的是Java 11或Java 17，只要未显式授权，就会抛出该IllegalStateException。

✅ 正确理解：JDK 9 = JDK ≥ 9，不是版本误配，而是功能启用开关未打开。

✅ 两种标准解决方案（任选其一）

方案一：添加JVM系统属性（推荐，轻量易维护）

在IntelliJ中为测试配置添加JVM选项：

打开 Run → Edit Configurations…
左侧选择你的测试配置（如JUnit或Test）
在 VM options 输入框中添加：
```
-Djdk.attach.allowAttachSelf=true
```
点击Apply → OK，重新运行测试。

? 优势：无需修改构建脚本，适用于本地调试；对Gradle/Maven构建无侵入。

方案二：显式声明Java Agent（适合CI/统一管控）

若项目已集成JMockit依赖，需确保-javaagent路径正确，并在所有运行环境中生效：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

Gradle（build.gradle）中配置：

test {
    jvmArgs = ['-javaagent:' + System.getProperty('user.home') + '/.m2/repository/org/jmockit/jmockit/1.49/jmockit-1.49.jar']
    // 或更健壮的写法（自动解析依赖路径）：
    // jvmArgs = ['-javaagent:' + configurations.testRuntimeClasspath.files.find { it.name.contains('jmockit') }.absolutePath]
}

Maven（pom.xml）中配置：

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-surefire-plugin</artifactid><version>3.0.0-M10</version><configuration><argline>-javaagent:${settings.localRepository}/org/jmockit/jmockit/1.49/jmockit-1.49.jar</argline></configuration></plugin>

⚠️ 注意：jmockit-1.49.jar路径需与你实际引入的版本一致；建议使用mvn dependency:copy-dependencies确认本地仓库路径。

? 常见误区与避坑提醒

❌ 不要试图降级JDK至8——既违背现代Java工程实践，也无法解决根本问题（JMockit 1.x本身已不兼容JDK 8的旧attach逻辑）；
❌ 不要修改module-info.java或加--add-opens——此错误与模块导出无关，而是JVM底层attach权限控制；
❌ 不要在gradle.properties中设org.gradle.jvmargs来全局添加-Djdk.attach...——该参数仅作用于Gradle Daemon JVM，而非测试子进程；
✅ 推荐长期演进：评估迁移到JUnit 5 Mocking Extensions或Mockito-inline，它们原生适配JPMS且无需Java Agent。

✅ 验证是否修复

成功添加配置后，再次运行测试，错误应消失，且JMockit功能（如@Mocked List<string></string>）可正常工作。你可在测试中加入简单断言验证：

@Test
public void testJMockitWorks() {
    new Expectations() {{
        mockedList.size(); result = 42;
    }};
    assertEquals(42, mockedList.size()); // 应通过
}

记住：这不是一个“可以忽略的警告”，而是阻断测试执行的硬性失败。但它的修复成本极低——只需一行JVM参数。理解其背后的JPMS设计哲学，比机械地复制粘贴解决方案更有价值。