Repository navigation
Open
Description
This appears to be related to eclipse-jdt/eclipse.jdt.core#3298. I'm not sure when this changed but as of the update released yesterday I am now getting the following error in my logs any time I try to work on my Minecraft mod projects (e.g. glektarssza/minecraft-gtnh-customizer):
!ENTRY org.eclipse.jdt.core.manipulation 4 0 2025-10-29 09:43:37.638
!MESSAGE Error in JDT Core during AST creation
!STACK 0
java.lang.IllegalStateException: Missing system library
at org.eclipse.jdt.core.dom.ASTParser.checkForSystemLibrary(ASTParser.java:311)
at org.eclipse.jdt.core.dom.ASTParser.getClasspath(ASTParser.java:269)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateASTCached(ASTParser.java:1395)
at org.eclipse.jdt.core.dom.ASTParser.lambda$1(ASTParser.java:1274)
at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5709)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1274)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:918)
at org.eclipse.jdt.core.manipulation.CoreASTProvider$1.run(CoreASTProvider.java:294)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.core.manipulation.CoreASTProvider.createAST(CoreASTProvider.java:286)
at org.eclipse.jdt.core.manipulation.CoreASTProvider.getAST(CoreASTProvider.java:199)
at org.eclipse.jdt.ls.core.internal.JDTUtils.getAst(JDTUtils.java:1953)
at org.eclipse.jdt.ls.core.internal.handlers.SemanticTokensHandler.full(SemanticTokensHandler.java:45)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$57(JDTLanguageServer.java:1205)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:667)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:504)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2019)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
To replicate the issue:
- Ensure you have Git LFS installed properly (see this comment on redhat-developer/vscode-java#4218 for why).
- Clone the repository.
- Install the extensions outlined in the
Enabled Extensions Informationsection below. - Copy the appropriate template VSCode settings from
./templates/vscode/from inside the repository above into your./.vscode/settings.jsonfile inside the repository above. - Replace the Java paths inside the copied templates to a version of Java 21.
- Ensure your
JAVA_HOMEenvironment variable is set to a version of Java 17. - Run
./gradlew setupDecompWorkspaceinside the repository above. - Run
./gradlew buildinside the repository above. - Run
./gradlew eclipseinside the repository above. - Try to get autocompletion in any file.
- Observe the issue.
Activity
fbricon commentedon Oct 30, 2025
It works for me. Although I had to run
./gradlew eclipseafter project import.The
.classpathgenerated by the gradle build server during import doesn't contain any jar dependency:That causes plenty of compilation errors due to missing types. So once the project has been imported in vscode, then you can run
./gradlew eclipse, which generates a working.classpath(although targeted at buildship)after that I got no compilation errors, completion works as expected.
@glektarssza check your .classpath contains
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/"/>You can try to run the
Java: Clean Java Language Server Workspacecommand, but make sure you rerun.gradlew eclipseafter that.In theory, you shouldn't have to, but I think there's a bug in the gradle build server that fails to generates the proper
.classpathcontaining dependencies. You should open a ticket in https://github.com/microsoft/vscode-gradle/issues for that (cc @testforstephen @chagong)glektarssza commentedon Oct 30, 2025
Thank you for the investigation, @fbricon!
I did mention in my reproduction steps (step 9) that running
./gradlew eclipseis required. This is because of the way the toolchain for this project is set up which is, somewhat unfortunately, out of my hands. Minecraft modding is a bit of a special beast, especially on older versions like the one I'm working on here.My
.classpathdoes, indeed, contain the aforementioned entry.Even with this entry present I still don't get any auto-completions. See the following video demonstrating the issue.
vscode_java_bug.mp4
Interestingly enough, if I change the
org.eclipse.jdt.core.compiler.compliancesetting in.settings/org.eclipse.jdt.core.prefsI do start getting auto-completions again. So I'm not sure this is a Gradle issue, actually. See the following video again for a demonstration of this.vscode_java_bug_2.mp4
This particular compliance and target arrangement is being used because the project uses Jabel to compile Java 9+ syntax when targeting Java 8 targets, thus giving access to modern compiler features while still maintaining compatibility with the version of Java the particular version of Minecraft being modded runs on.
glektarssza commentedon Jan 20, 2026
Just following up on this; adding the following to my build setup (in a file called
addon.gradle, as required by the build process I'm working with) does resolve the issue largely.So it does seem that it's a combination of two factors. The encoding being not set consistently (which is not related to this issue) and the compliance being set to something other than 1.8. Given I have a work around for the time being I'm pretty good to keep moving along but it's far from ideal. I'm honestly not sure where the precise issue lies at this point but I'm suspecting the LSP (jdtls) right now personally.