vscode-java fails to build project with pom-type dependency

I am attempting to follow https://www.graalvm.org/latest/reference-manual/python/ in VSCode, but the Java Language Support for VSCode appears to be having some difficulty. Namely, it thinks the project cannot be built, while ./gradlew build succeeds just fine.

Environment

Operating System: macOS 13.6.1 (22G313)
JDK version:
openjdk 21.0.2 2024-01-16
OpenJDK Runtime Environment Homebrew (build 21.0.2)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
Visual Studio Code version: 1.87.2 (Universal)
Java extension version: v1.28.1
Gradle 8.5

Steps To Reproduce

git clone https://github.com/kalaracey/graalpy-vscode-issue.git
Open graalpy-vscode-issue in VSCode
Wait for the automatic "Opening Java Projects" to finish

Java Language Server log

Current Result

VSCode's Problems tab has two problems:

Archive for required library: '/Users/kal/.gradle/caches/modules-2/files-2.1/org.graalvm.polyglot/python-community/23.1.2/2534a71914ae30007251d1f91f67bb5b5b3431d/python-community-23.1.2.pom' in project 'app' cannot be read or is not a valid ZIP file
The project cannot be built until build path errors are resolved

Expected Result

No problems, given that ./gradlew build succeeds.

Additional Informations

/Users/kal/.gradle/caches/modules-2/files-2.1/org.graalvm.polyglot/python-community/23.1.2/2534a71914ae30007251d1f91f67bb5b5b3431d/python-community-23.1.2.pom is the only file in its directory.

Outputs from various VSCode tasks:

FWIW, I noticed that when I Java: Configure Java Runtime, the type of project app is "Unmanaged folder", and not "Gradle" as I would have expected, but I don't know how to change that. Not sure if that's related.

Poking around /Users/kal/.gradle/caches/modules-2/files-2.1, I noticed something peculiar about org.graalvm.polyglot/python-community: it only includes a pom file, and no jars, unlike other dependencies.

I noticed that in the Maven setup for embedded GraalPy (see also here), <type>pom</type> is specified, i.e. the python-community is a "pom-type" dependency.

Searching for [jdt "pom dependency"] on Google reveals [jira] [Closed] (MCOMPILER-544) ZipException: zip END header not found on POM dependency with Eclipse compiler:

ZipException: zip END header not found on POM dependency with Eclipse compiler

There is an impedance matching issue between Maven Compiler Plugin, plexus-compiler-eclipse, and eclipse.jdt.core. m-c-p adds POM dependency's POM file to classpath, which makes it through plexus-compiler-eclipse to JDT and that prints an exception ZipException: zip END header not found. Arguably, m-c-p should not be adding non-JAR, non-wildcard-directory path to classpath for the compiler.

The issue seems to have been tracked in apache/maven-compiler-plugin#198 and codehaus-plexus/plexus-compiler#302.

It looks like the issue was reported to the Eclipse JDT project (eclipse-jdt/eclipse.jdt.core#1274) but they closed the issue without a fix, and the fix was made in the Maven Compiler Plugin (see link in previous comment). IIUC, that would mean that a fix similar to apache/maven-compiler-plugin#198 would be needed in vscode-java.

As mitigation, I wonder if there is a way to get vscode-java to ignore certain dependencies, like the pom-type python-community dependency.

There is another Eclipse JDT issue related to the Zip problem that is still open: eclipse-jdt/eclipse.jdt.core#1578

Ok I have found a partial mitigation but it is not complete. I changed

    implementation("org.graalvm.polyglot:python:23.1.2")

in build.gradle.kts to

    implementation("org.graalvm.polyglot:python:23.1.2") {
        exclude(group = "org.graalvm.polyglot", module = "python-community")
    }

Running ./gradlew run still works (it prints "Hello Python!") but there are now some scary looking errors that indicate possible trouble with anything more complicated than a Hello World program:

[python::PythonContext] WARNING: could not determine Graal.Python's core path - you may need to pass --python.CoreHome.
[python::PythonContext] WARNING: could not determine Graal.Python's sys prefix path - you may need to pass --python.SysPrefix.
[python::PythonContext] WARNING: could not determine Graal.Python's standard library path. You need to pass --python.StdLibHome if you want to use the standard library.
[python::PythonContext] WARNING: could not determine Graal.Python's C API library path. You need to pass --python.CAPI if you want to use the C extension modules.
[python::PythonContext] WARNING: could not determine Graal.Python's C API library path. You need to pass --python.CAPI if you want to use the C extension modules.
[python::PythonContext] WARNING: could not determine Graal.Python's JNI library. You need to pass --python.JNILibrary if you want to run, for example, binary HPy extension modules.
[python::PythonContext] WARNING: could not determine Graal.Python's C API library path. You need to pass --python.CAPI if you want to use the C extension modules.
[python::PythonContext] WARNING: could not determine Graal.Python's C API library path. You need to pass --python.CAPI if you want to use the C extension modules.
[python::PythonContext] WARNING: could not determine Graal.Python's JNI library. You need to pass --python.JNILibrary if you want to run, for example, binary HPy extension modules.

Adding /Users/kal/.gradle/caches/modules-2/files-2.1/org.graalvm.polyglot/python-community/23.1.2/2534a71914ae30007251d1f91f67bb5b5b3431d/python-community-23.1.2.pom to java.project.referencedLibraries.exclude has no effect.

Ok here might be a better mitigation. It seems like the pom dependencies are just placeholders to pull in other, real dependencies. So I inspected the dependencies of

/Users/kal/.gradle/caches/modules-2/files-2.1/org.graalvm.polyglot/python/23.1.2/85f926b2f5d99d5753d2ec925a1051b94ed0dff5/python-23.1.2.pom
/Users/kal/.gradle/caches/modules-2/files-2.1/org.graalvm.polyglot/python-community/23.1.2/2534a71914ae30007251d1f91f67bb5b5b3431d/python-community-23.1.2.pom

and determined which ones looked like they were necessary. In build.gradle.kts I replaced

    implementation("org.graalvm.polyglot:python:23.1.2")

with

    implementation("org.graalvm.python:python-language:23.1.2")
    implementation("org.graalvm.python:python-resources:23.1.2")
    implementation("org.graalvm.truffle:truffle-runtime:23.1.2")

and the entries in the Problems pane that I reported appear to have gone away, and there is no discernible difference in the output of ./gradlew run.

It would still be great if the underlying problem of adding these pom-only dependencies to the class path (IIUC) could be fixed.

Interestingly, vscode-java does not appear to suffer from this issue when using the example GraalPy Maven project (which can be set up with a single command), indicating the issue may be related to Gradle or how vscode-java is using Gradle.

Also having the issue, with a different file though.

Same issue with org.graalvm.polyglot:js-community.

Downgrading to version 1.53.0 fixes the issue.

@cristatus

Hi Team, please install the prerelease to verify this issue
@cristatus @idandam @kalaracey

@wenytang-ms

@wenytang-ms I just tested the specified pre-release version, vscjava.vscode-gradle 3.17.2026060902, together with redhat.java 1.54.0, and the issue still occurs.

Based on my testing, the problem appears to be coming from JDT Core rather than vscode-gradle. I do not see the issue when using redhat.java 1.53.0 with the same vscode-gradle version.

I also tried switching to redhat.java 1.55.2026060409, and the issue is still reproducible. So far, redhat.java 1.53.0 is the only version that works correctly.

Here is the relevant log:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-09 11:57:46.496
!MESSAGE Workspace initialized in 44128ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-09 11:57:46.508
!MESSAGE >> initialization job finished

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-09 11:57:46.659
!MESSAGE >> build jobs finished

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-09 11:57:46.659
!MESSAGE >> registerWatchers'

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-09 11:57:46.669
!MESSAGE >> registerFeature 'workspace/didChangeWatchedFiles'

!ENTRY org.eclipse.jdt.core 4 4 2026-06-09 11:58:18.113
!MESSAGE Invalid ZIP archive: /home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom
!STACK 0
java.util.zip.ZipException: zip END header not found
	at java.base/java.util.zip.ZipFile$Source.findEND(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.initCEN(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.get(Unknown Source)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
	at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2987)
	at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2922)
	at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:259)
	at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren(JarPackageFragmentRoot.java:129)
	at org.eclipse.jdt.internal.core.PackageFragmentRoot.buildStructure(PackageFragmentRoot.java:172)
	at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:250)
	at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:571)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:294)
	at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:280)
	at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:235)
	at org.eclipse.jdt.internal.core.PackageFragmentRoot.getSourceModuleDescription(PackageFragmentRoot.java:912)
	at org.eclipse.jdt.internal.core.PackageFragmentRoot.getModuleDescription(PackageFragmentRoot.java:905)
	at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getModuleDescription(JarPackageFragmentRoot.java:316)
	at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.computeModuleFor(JavaSearchNameEnvironment.java:604)
	at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.mapToClassPathLocation(JavaSearchNameEnvironment.java:302)
	at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.computeClasspathLocations(JavaSearchNameEnvironment.java:215)
	at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.computeClasspathLocations(JavaSearchNameEnvironment.java:187)
	at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.<init>(JavaSearchNameEnvironment.java:95)
	at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.resolveDocument(SourceIndexer.java:191)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.resolveDocument(JavaSearchParticipant.java:125)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexResolvedDocument(IndexManager.java:684)
	at org.eclipse.jdt.internal.core.search.indexing.IndexManager$2.execute(IndexManager.java:1288)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.indexerLoop(JobManager.java:541)
	at java.base/java.lang.Thread.run(Unknown Source)

@wenytang-ms

@wenytang-ms I found another difference between the working and non-working versions.

With redhat.java 1.54.0 (and newer), one of the modules contains the following entry in its .classpath file:

<classpathentry kind="lib" path="/home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom"/>

However, when using redhat.java 1.53.0, I don't see any similar .pom entries in the generated .classpath files. This might provide a clue as to where the regression was introduced.

@cristatus

@cristatus
I don't think this one is coming from vscode-gradle. The entry you found is a bare lib entry:

Our build-server importer always stamps its library entries with a gradle.buildServer="true" attribute (plus groupId/artifactId/version), and since #1871 it skips .pom artifacts entirely and rebuilds the whole classpath on re-import. A bare .pom entry isn't something we produce. That also fits what you saw: the issue tracks the redhat.java version (1.53 ok, 1.54+ bad), not vscode-gradle — pointing at the eclipse.jdt.core indexer regression (#1578).

Can you double-check two things?

java.gradle.buildServer.enabled is on (default).
Run "Java: Clean Java Language Server Workspace", re-import, then reopen .classpath.

If the .pom is gone (or only shows up with a gradle.buildServer attribute), the fix is working. If it's still a bare entry / the project shows as "Unmanaged folder", that's the jdt.core/Buildship side. And if you ever see a .pom entry with the gradle.buildServer attribute, paste it here and I'll dig back in. Thanks!

@wenytang-ms

@wenytang-ms Thanks for the details.

I can confirm that java.gradle.buildServer.enabled is enabled. I also ran "Java: Clean Java Language Server Workspace" several times while testing different versions/combinations of the vscode gradle and java extensions.

The issue is still reproducible. I still see this in the JDT log:

!ENTRY org.eclipse.jdt.core 4 4 2026-06-09 11:58:18.113
!MESSAGE Invalid ZIP archive: /home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom
!STACK 0

And the generated .classpath still contains:

<classpathentry kind="lib" path="/home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom"/>

This is still a bare .pom entry and I don't see any gradle.buildServer="true" attribute or the groupId/artifactId/version attributes you mentioned.

So based on what you described, it looks like this entry is not coming from the build-server importer. It seems more likely related to the JDT/Buildship side.

Let me know if there is anything else I can check or provide.

@cristatus

@cristatus Could you run a couple of quick checks so we can pin down where that entry is coming from?

Open the .classpath of the module that has the bad .pom entry, and search it for gradle.buildServer. Do any entries in that file have a gradle.buildServer="true" attribute?

If none do → the build server isn't actually managing this project (it's falling back to Buildship), and that's the trail to follow.
If others do but the .pom one doesn't → that's on us, let me know and I'll dig back in.

Run Java: Configure Java Runtime and tell me whether this project shows up as "Gradle" or "Unmanaged folder".
Check the "Build Server for Gradle" output channel for any import errors/warnings around the time of sync.

That'll tell us for sure which side is writing the entry.

@wenytang-ms

@wenytang-ms I checked again with the newer versions, including the latest pre-release 1.55.2026060409.

There are no gradle.buildServer="true" attributes anywhere in the .classpath file. The .pom entry is written as:

<classpathentry kind="lib" path="/home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom"/>

For comparison, with redhat.java 1.53.0, the same entry includes the Gradle attributes:

<classpathentry kind="lib" path="/home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom">
  <attributes>
    <attribute name="gradle.buildServer" value="true"/>
    <attribute name="groupId" value="org.graalvm.js"/>
    <attribute name="artifactId" value="js"/>
    <attribute name="version" value="25.0.3"/>
  </attributes>
</classpathentry>

For the runtime check, I’m not completely sure I’m looking in the exact place you meant, but the project appears to be imported as a Gradle project. In Libraries, I see entries like:

/home/cristatus/.gradle/caches/modules-2/files-2.1/org.graalvm.js/js/25.0.3/c7979ead22b71d8ca7188168724606f213668544/js-25.0.3.pom
Gradle: jul-to-slf4j-2.0.18.jar
Gradle: jcl-over-slf4j-2.0.18.jar
Gradle: log4j-over-slf4j-2.0.18.jar
Gradle: logback-classic-1.5.32.jar
...

The Gradle Projects view is also populated, and I can expand the Dependencies node and see the project dependencies there.

For the Build Server for Gradle output channel, I don’t see any warnings or errors around the time of synchronization.

@wenytang-ms

@wenytang-ms I also noticed these entries in the .classpath:

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21/"/>
<classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>

So even though the build server is enabled, it looks like Buildship may be involved in writing or contributing to the classpath somehow.

@cristatus

@cristatus Great data — that actually cracks it. Two things:

This project is being managed by Buildship, not our build server. The tell-tale signs all line up: the .classpath has org.eclipse.buildship.core.gradleclasspathcontainer, the .pom entry is bare (our importer always stamps its entries with gradle.buildServer="true"), and the "Build Server for Gradle" channel shows no sync activity. Our importer deliberately steps aside when a folder already has a Buildship-imported Gradle project, so for this workspace it isn't even running — Buildship is the one writing that bare .pom. The actual crash is the eclipse.jdt.core 1.54+ indexer treating a non-jar classpath entry as a zip (ZipException), i.e. ecj spams the console with irrelevant zip exceptions eclipse-jdt/eclipse.jdt.core#1578. In 1.53 that same .pom was harmless (and back then it carried our gradle.buildServer stamp because the build server was managing it).
The .pom skip fix isn't in a released build yet — it's only on develop, not in any tagged release. And even with it, it wouldn't kick in here until the build server actually takes over this project instead of Buildship.

Could you do one clean run to confirm? Close the window, delete the project's .project, .classpath, .settings/ and .gradle/ (e.g. git clean -xfd), reopen, then run Java: Clean Java Language Server Workspace and let it re-import. Then check .classpath again:

No more Buildship container / no bare .pom → confirmed: it was stale Buildship state + the jdt.core regression.
Still a Buildship container + bare .pom → then the build server isn't taking over when it should, and that part is on us — let me know and I'll dig in.

Thanks for sticking with this!

Root cause: the crash is eclipse.jdt.core's indexer opening a non-jar (.pom) classpath entry as a zip and throwing ZipException. Any .pom-type dependency on the classpath triggers it, no matter which importer added it. jdt.core has declined to handle this before (eclipse-jdt/eclipse.jdt.core#1274, closed as won't-fix; #1578 still open with no fix planned), so the entry just needs to not be on the classpath in the first place.

Where it's coming from in your case: this project is managed by Buildship, not our build server — the .pom entry is bare (our importer always stamps its entries with gradle.buildServer="true") and the .classpath has org.eclipse.buildship.core.gradleclasspathcontainer. Our build server importer steps aside when a folder already has a Buildship-imported Gradle project, so it isn't running here; Buildship is what's writing that bare .pom. (In 1.53 the same entry had our stamp because the build server was managing it then, and jdt.core 1.53 tolerated the .pom.)

On our side: the build server importer no longer puts .pom artifacts on the classpath (microsoft/vscode-gradle#1871, on develop, shipping in an upcoming release). So when the build server manages the project, the entry won't be added. For a Buildship-managed project the same skip would need to happen on the Buildship/jdt.ls import path.

@wenytang-ms

@wenytang-ms I'm not using Eclipse, and those .classpath/.settings files are not in the project directory. They're generated under VS Code's JDT workspace (User/workspaceStorage/.../redhat.java/jdt_ws/...) and appear to be managed by the VS Code Java/Gradle extensions.

What's confusing me is that if I switch back to vscode-java 1.53.0 and run Clean Java Language Server Workspace, the regenerated .classpath contains entries with gradle.buildServer="true". It also still contains a .pom entry, but I don't see any indexing errors in that case.

With vscode-java 1.54.0+, I instead end up with the Buildship-style metadata and then hit the indexing errors. So I am wondering why is Buildship taking over at all in 1.54.0+ if the build server is supposed to manage the import?

@cristatus

@cristatus
Following up — quick note on how the importer is chosen, since it explains the version dependency.

Importers run by order; the first whose applies() succeeds and isResolved() returns true wins:

build server — order 200
Buildship — order 300

So the build server always tries first. Buildship only takes over when the build server yields — i.e. its import sets isResolved=false and the loop falls through to 300. That happens when:

the BSP server doesn't start → Failed to start Gradle Build Server, use BuildShip instead
it can't fetch targets → Failed to get build targets from Gradle Build Server. If another Gradle process is running, please stop it and retry.
a stale Buildship project already exists under the root (build server's applies() steps aside)

When the build server manages the project it skips .pom and stamps entries with gradle.buildServer="true"; the bare .pom is Buildship's, and jdt.core 1.54+ now chokes on it (eclipse-jdt/eclipse.jdt.core#1578).

I went through the jdt.ls Gradle-import changes between 1.53 and 1.54 — none change this build-server→Buildship priority. So 1.54 isn't deliberately handing the project to Buildship; it's hitting one of the fallbacks above (likely BSP failing to start/return targets given the heavy GraalVM deps).

To capture which one, the import has to actually run again — note it's cached, so just reloading after an upgrade won't re-log it. Could you:

Run Java: Clean Java Language Server Workspace and let it fully re-import, then
Open the log right after at …/User/workspaceStorage//redhat.java/jdt_ws/.metadata/.log (check .bak_*.log too if it rotated), and share any ... use BuildShip instead / Failed to get build targets ... lines plus the Importers: ... line.

That'll pin the exact trigger.

@wenytang-ms

@wenytang-ms I followed the steps you suggested (ran Java: Clean Java Language Server Workspace and let the project fully re-import), but I couldn't find any of the log entries you mentioned (... use BuildShip instead, Failed to get build targets ..., or the Importers: ... line).

I'm attaching anonymized logs from both scenarios instead:

error.log – captured when the issue occurs.
success.log – captured when the import succeeds (using vscode-java 1.53.0).

Hopefully comparing the two helps identify the trigger. Let me know if there's any other specific logging I should enable or capture.

error.log

success.log

@cristatus

@cristatus Thanks, the logs nailed it. Two things:

Why Buildship (not the build server) is managing it: this is a multi-root workspace (I see separate import cycles for project-one and project-two). The build server importer currently bails on multi-root (getRootPaths().size() != 1), so it steps aside and Buildship takes over — in both 1.53 and 1.54+. That part isn't the regression (and is why you don't see any ... use BuildShip instead lines).

The actual trigger (error.log, repeated):

The specified initialization script '.../globalStorage/redhat.java/1.53.0/config_linux/.../gradle/init/init.gradle' does not exist.

You're running 1.55, but Buildship is invoking a Gradle init script from the 1.53.0 folder, which no longer exists. That path is version-pinned and gets persisted in each project's .settings/org.eclipse.buildship.core.prefs. After upgrading off 1.53.0 the script is gone → Buildship's Gradle sync fails (BuildException: Could not run phased build action) → the classpath isn't cleanly rebuilt and the raw .pom is left on it → jdt.core 1.54+ then throws the ZipException (#1578) indexing it. In 1.53.0 the path matched the running version, so sync succeeded and there was no .pom error.

Note Clean Java Language Server Workspace only clears jdt_ws — it doesn't touch the in-place .project/.classpath/.settings//.gradle/ in your actual project folders, so the stale 1.53.0 path survives.

@wenytang-ms

@wenytang-ms Thanks for the detailed explanation.

Just for additional context, I've already tried reproducing this in a completely clean environment: fresh VS Code user data, clean ~/.gradle, and a fresh installation of all extensions. Despite that, I'm still seeing the same error with vscode-java 1.54.0 and later.

Given that, it doesn't appear to be caused solely by a stale org.eclipse.buildship.core.prefs entry left over from an upgrade path. I'll try to prepare a minimal reproducible example that exhibits the same behavior and share it here.

@wenytang-ms

@wenytang-ms I’m attaching a minimal example project that reproduces the issue for me. Open the included vscode-java-3555.code-workspace file and the error should appear immediately after the workspace is loaded with vscode-java 1.54.0+.

Let me know if any additional diagnostics would be helpful.

vscode-java-3555.zip

@cristatus

@cristatus — correction to my last comment, and a clearer summary after reproducing this in a clean environment.

My "stale 1.53.0 init.gradle" explanation was off. I reproduced the crash in a clean setup (no leftover 1.53.0 state), so the missing init script isn't the trigger. Here's what actually happens:

Root cause (confirmed):

This is a multi-root workspace. Our build server importer currently bails on multi-root (getRootPaths().size() != 1), so it steps aside and Buildship manages the projects — on both 1.53 and 1.54+.
Buildship puts the pom-only dependency (org.graalvm.polyglot:js:25.0.3, which is <packaging>pom</packaging>) on the classpath as a bare .pom library entry.
eclipse.jdt.core 1.54+ opens any such library entry as a ZIP during indexing/AST resolution → ZipException: zip END header not found (ecj spams the console with irrelevant zip exceptions eclipse-jdt/eclipse.jdt.core#1578; Support lazy loading invisible project #1274 was closed won't-fix). 1.53 tolerated the same entry; 1.54+ does not — which is why this looks version-bound to redhat.java.

What works today:

Replace the pom-only dependency with its concrete artifacts (the actual jars org.graalvm.polyglot:js aggregates). A pom-only entry has no jar, so it should never be a JDT library entry. This is the only reliable fix on the current stack and doesn't depend on any unreleased change. Gradle still resolves the BOM at build time, so ./gradlew run is unaffected.
Temporary: pin redhat.java to 1.53.0.
Note: java.project.referencedLibraries.exclude does not apply to Gradle-derived classpaths, so it won't help here.

Upcoming fix: the build server importer now skips non-archive artifacts like .pom (microsoft/vscode-gradle#1871, on develop, not in any tagged release yet). Caveat: that only helps when the build server manages the project. For this multi-root workspace the build server still yields to Buildship, so #1871 alone won't change this exact case until either (a) the build server handles multi-root, or (b) the .pom skip also happens on the Buildship/jdt.ls import path.

@wenytang-ms

@wenytang-ms Thanks for the detailed investigation. That explanation makes things much clearer, especially the Buildship vs build server distinction and why this only shows up with JDT 1.54+.

I'll pin redhat.java to 1.53.0 for now and keep an eye on the upcoming fixes. Thanks again for taking the time to reproduce it in a clean environment and track down the actual root cause.

Navigation Menu

Repository navigation

vscode-java fails to build project with pom-type dependency #3555

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Informations

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

vscode-java fails to build project with pom-type dependency #3555

Description

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Informations

Activity

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

kalaracey commented on Mar 29, 2024

idandam commented on Jan 5, 2025

cristatus commented on Apr 29, 2026

cristatus commented on May 22, 2026

wenytang-ms commented on Jun 9, 2026

cristatus commented on Jun 9, 2026

cristatus commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

cristatus commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

cristatus commented on Jun 9, 2026

cristatus commented on Jun 9, 2026

wenytang-ms commented on Jun 10, 2026

wenytang-ms commented on Jun 10, 2026

cristatus commented on Jun 10, 2026

wenytang-ms commented on Jun 10, 2026

cristatus commented on Jun 10, 2026

wenytang-ms commented on Jun 11, 2026

cristatus commented on Jun 11, 2026

cristatus commented on Jun 11, 2026

wenytang-ms commented on Jun 12, 2026

cristatus commented on Jun 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions