Java language server fails in JrtFileSystem.walkModuleImage() with 1.10.0

[knutae]

Java language server fails when opening a project with the following error/stacktrace:

[Error - 5:16:03 PM] Sep 1, 2022, 5:16:03 PM Initialization failed Cannot invoke "org.eclipse.jdt.internal.compiler.util.JrtFileSystem.walkModuleImage(org.eclipse.jdt.internal.compiler.util.JRTUtil$JrtFileVisitor, int)" because the return value of "org.eclipse.jdt.internal.compiler.util.JRTUtil.getJrtSystem(java.io.File, String)" is null java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.internal.compiler.util.JrtFileSystem.walkModuleImage(org.eclipse.jdt.internal.compiler.util.JRTUtil$JrtFileVisitor, int)" because the return value of "org.eclipse.jdt.internal.compiler.util.JRTUtil.getJrtSystem(java.io.File, String)" is null at org.eclipse.jdt.internal.compiler.util.JRTUtil.walkModuleImage(JRTUtil.java:242) at org.eclipse.jdt.internal.core.JavaProject.loadModulesInJimage(JavaProject.java:983) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:782) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:1103) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:1048) at org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots(JavaProject.java:1025) at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:538) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:266) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:597) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:328) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:314) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:269) at org.eclipse.jdt.internal.core.JavaProject.getPackageFragmentRoots(JavaProject.java:2384) at org.eclipse.jdt.internal.core.JavaProject.getPackageFragments(JavaProject.java:2408) at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.cleanupResources(ProjectsManager.java:278) at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:107) at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:244) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Downgrading the extension to the previous version (1.9.0) fixed the issue.

Environment

• Operating System: Ubuntu 22.04, but also seen by coworkers using MacOS
• JDK version: OpenJDK Runtime Environment Zulu17.28+13-CA (build 17+35-LTS)
• Visual Studio Code version: 1.70.2
• Java extension version: 1.10.0

Steps To Reproduce

1. Upgrade to the newest vscode-java release
2. Open an existing Java project

I don't know if it happens for all java projects, our is pretty complex and I unfortunately cannot share it.

Current Result

Opening an existing java project fails (it logs errors as described above and never finishes).

Expected Result

Opening java projects that worked in 1.9.0 should work with the latest version.

[helgeholm]

Reproduced on same environment, but versions Ubuntu 20.04, Visual Studio Code 1.71.0.

[snjeza]

2. Open an existing Java project

@knutae @deestan

• could you attach a project example reproducing the error?
• could you attach $JAVA_HOME}/release?

[testforstephen]

This duplicates with https://github.com/microsoft/vscode-java-debug/issues/1212#issuecomment-1248951918. It's a regression in upstream jdt.core https://github.com/eclipse-jdt/eclipse.jdt.core/issues/405.

Root Cause: Your JDK installation misses release file, that leads Java extension to throw NPE when reading the release file.

Workaround: Reinstall your JDK, or manually create a release file as follows in your jdk home and please replace JAVA_VERSION with your actual JDK version.

JAVA_VERSION="11.0.14"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.ldap jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"

Follow up question: Last but not least, we want to know if it is rare for JDK builds to not contain "release" files. So can you tell us the affected JDK distribution and version? Where can we get it from?

[knutae]

I can confirm that adding a release file fixes the issue. Thanks!

Short story: we use a custom script on top of bazel for installing the JDK, so this is probably not a common error.

Long story: Our build uses bazel, and we set up the eclipse project to use the same java version as bazel via a script. There is some magic here that I don't quite understand, but we include all target files from the @bazel_tools//tools/jdk:remotejdk_17 rule, which ends up with a working JDK folder (OpenJDK Zulu 17), except that the release file is missing. Would probably need to dig deeper into the bazel rules to understand why the release file is not included. As far as I can see it is included in the bundles used by bazel, see https://github.com/bazelbuild/bazel/blob/master/distdir_deps.bzl

[testforstephen]

@knutae thank you for sharing the use case.