[BUG] IllegalAccessException: module java.base does not open java.lang to unnamed module

[ToshiNamura]

I've been solving the testing problem through your extension for two days, and I've been getting this error:

org.gradle.api.GradleException: Could not inject synthetic classes.
 at org.gradle.initialization.DefaultLegacyTypesSupport.injectEmptyInterfacesIntoClassLoader([DefaultLegacyTypesSupport.java:108](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.testfixtures.internal.ProjectBuilderImpl.getGlobalServices([ProjectBuilderImpl.java:269](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.testfixtures.internal.ProjectBuilderImpl.createProject([ProjectBuilderImpl.java:162](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.testfixtures.ProjectBuilder.build([ProjectBuilder.java:121](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at net.furfurmc.gradle.minedeployer.tests.tasks.MineDeployTaskTest.pluginRegistersATask([MineDeployTaskTest.java:14](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @1a451d4d
 at org.gradle.internal.classloader.ClassLoaderUtils$AbstractClassLoaderLookuper.invoke([ClassLoaderUtils.java:156](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.internal.classloader.ClassLoaderUtils$LookupClassDefiner.defineClass([ClassLoaderUtils.java:212](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.internal.classloader.ClassLoaderUtils.define([ClassLoaderUtils.java:82](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.initialization.DefaultLegacyTypesSupport.injectEmptyInterfacesIntoClassLoader([DefaultLegacyTypesSupport.java:105](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 ... 4 more
Caused by: java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @1a451d4d
 at java.base/java.lang.invoke.MethodHandles.privateLookupIn([MethodHandles.java:287](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.internal.classloader.ClassLoaderUtils$AbstractClassLoaderLookuper.getLookupForClassLoader([ClassLoaderUtils.java:165](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 at org.gradle.internal.classloader.ClassLoaderUtils$AbstractClassLoaderLookuper.invoke([ClassLoaderUtils.java:152](vscode-file://vscode-app/e:/Users/Micro/AppData/Local/Programs/Microsoft%20VS%20Code/fcf604774b/resources/app/out/vs/code/electron-browser/workbench/workbench.html))
 ... 7 more

With this code:

@Test
void pluginRegistersATask()
{
    // Create a test project and apply the plugin
    Project project = ProjectBuilder.builder().build();
    project.getPlugins().apply("org.example.filesizediff");

    // Verify the result
    assertNotNull(project.getTasks().findByName("fileSizeDiff"));
}

At the same time, if you run the test using the command: ./gradlew test --no-daemon, then everything runs fine.

It turned out that the problem was in the java command line arguments, I added the following parameters to the extension and it solved the problem:

"java.test.config": {
    "vmArgs": [
        "--add-opens=java.base/java.lang=ALL-UNNAMED",
        "--add-opens=java.base/java.util=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.reflect=ALL-UNNAMED"
    ]
}

This bypass does not solve the problem, as unnamed java code may change from version to version.

[github-actions]

Hi @ToshiNamura, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

• The only reliable fix today is to launch your tests JVM with the required module opens. For example, in your VS Code settings.json:

"java.test.config": {
  "vmArgs": [
    "--add-opens=java.base/java.lang=ALL-UNNAMED",
    "--add-opens=java.base/java.util=ALL-UNNAMED",
    "--add-opens=java.base/java.lang.reflect=ALL-UNNAMED"
  ]
}

Or define a test launch in .vscode/launch.json with the same vmArgs.

• This mirrors similar module‐access issues seen when the test runner reflects into JDK internals:

• GitHub Issue microsoft/vscode-java-test#1514 — fixes an IllegalAccessError by adding --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED to the test JVM.

Other references with low confidence

• Problem The method methodName(ParamType) in the type ClassName is not applicable for the arguments () in lightweight syntax only mode: shows how the Java extension itself is started with --add-opens=java.base/java.util=ALL-UNNAMED and --add-opens=java.base/java.lang=ALL-UNNAMED. redhat-developer/vscode-java#1931

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

[chagong]

Thanks for the detailed report and for confirming the vmArgs workaround. This happens because the default Java Test Runner profile launches JUnit directly in a standalone test JVM, so it does not inherit Gradle’s Test task environment or Gradle’s JVM/module-access setup; that is why ./gradlew test --no-daemon works while the default VS Code test profile needs explicit --add-opens.

For Gradle plugin tests using org.gradle.testfixtures.ProjectBuilder, please use the Delegate Test to Gradle profile, or keep the required java.test.config.vmArgs when running through the default Java Test Runner profile. We should not add these java.base opens globally for all Java test launches, but we can keep this issue open to improve the diagnostic/guidance for this Gradle-specific case.

[wenytang-ms]

Following up from the Gradle side — @chagong's diagnosis is exactly right. To make it actionable:

How to use it: in the Testing view, click the ⌄ dropdown next to the run button and pick "Delegate Test to Gradle" (there's a Debug variant too). This runs your tests through Gradle's real test task — the same environment as ./gradlew test — so the --add-opens that ProjectBuilder needs are applied by Gradle itself, and you don't have to pin them by hand (which, as you noted, drifts across JDK/Gradle versions).

Manual vmArgs remains a valid stopgap on the default profile. On the Gradle side we're looking at making this delegate path easier to discover; you can follow along at microsoft/vscode-gradle#1890.