Repository navigation
[BUG] IllegalAccessException: module java.base does not open java.lang to unnamed module #1878
Description
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.
Activity
github-actions commentedon Jun 19, 2026
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:
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:
--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMEDto 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-UNNAMEDand--add-opens=java.base/java.lang=ALL-UNNAMED. redhat-developer/vscode-java#1931The 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 commentedon Jun 22, 2026
Thanks for the detailed report and for confirming the
vmArgsworkaround. This happens because the default Java Test Runner profile launches JUnit directly in a standalone test JVM, so it does not inherit Gradle’sTesttask environment or Gradle’s JVM/module-access setup; that is why./gradlew test --no-daemonworks while the default VS Code test profile needs explicit--add-opens.For Gradle plugin tests using
org.gradle.testfixtures.ProjectBuilder, please use theDelegate Test to Gradleprofile, or keep the requiredjava.test.config.vmArgswhen running through the default Java Test Runner profile. We should not add thesejava.baseopens 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 commentedon Jul 7, 2026
Following up from the Gradle side — Changyong Gong (@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 realtesttask — the same environment as./gradlew test— so the--add-opensthatProjectBuilderneeds 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
vmArgsremains 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.