Repository navigation
[1.56.0] JDT LS re-initializes every ~20s and spawns a Gradle daemon each time (204 in one day vs. max 2/day under 1.55.0) #4501
Description
Activity
@FilipBeckmann Thanks for the detailed report. We created a small four-project Gradle 8.11.1 workspace with the reported Java and Gradle extension versions, but couldn't reproduce the issue.
Could you share a minimal sample project for us to test? We understand the issue is intermittent—a sample preserving the affected workspace structure and configuration would still be helpful, even without reliable reproduction steps.
Reacted by Filip BeckmannThanks for looking into it.
I can't share the project itself - it's a proprietary codebase. But I suspect the Gradle structure isn't the missing ingredient. The loop sits in
JDTLanguageServer.synchronizeBundles, which synchronizes JDT LS bundles contributed by other extensions.Six installed extensions contribute
javaExtensionsbundles here:vmware.vscode-spring-boot2.3.0vscjava.vscode-gradle3.18.0vscjava.vscode-java-debug0.59.0vscjava.vscode-java-dependency0.27.6vscjava.vscode-java-test0.46.0vscjava.vscode-maven0.45.3
Also installed:
vscjava.vscode-java-upgrade2.1.2,vscjava.migrate-java-to-azure1.23.0,marlon407.code-groovy0.2.1. Worth noting that eclipse-jdtls/eclipse.jdt.ls#2537, which carries this exact stack trace, was originally reported from the Spring tooling side.The complete Java-related configuration:
"java.import.gradle.enabled": true, "java.import.maven.enabled": false, "java.compile.nullAnalysis.mode": "automatic", "java.configuration.updateBuildConfiguration": "interactive", "java.semanticHighlighting.enabled": true
The workspace is opened through a
.code-workspacefile.Maybe this helps.
@FilipBeckmann Thanks for the additional details—we understand that you can’t share the proprietary project. The extension list, settings, and
.code-workspacesetup are helpful, and we’ll incorporate them into our sample environment.The bundle synchronization error is worth investigating. However, JDT LS catches and logs that exception, so the stack trace alone doesn’t establish what triggers the repeated initialization.
Could you share the Java extension’s client log, the JDT LS log, and the Extension Host log, ideally covering the period just before the loop starts and a few consecutive cycles? These would help us distinguish language-server restarts from extension-host reloads and narrow down the trigger.
Please redact any sensitive information before sharing; there’s no need to include source code.
The extension host does not reload - single pid for the whole window,
redhat.javaactivated once. So these are language-server restarts only.The loop starts here, first client-log entry after startup at 13:36:52:
[error] Language Support for Java client: couldn't create connection to server. Error: command 'sts.java.addClasspathListener' already exists at uf.registerCommand (…\resources\app\out\vs\workbench\api\node\extensionHostProcess.js) at t.ExecuteCommandFeature.register (<home>\.vscode\extensions\redhat.java-1.56.0-win32-x64\dist\extension.js) at t.ExecuteCommandFeature.initialize at c.initializeFeatures at c.doInitialize at async c.start at async t.startWithStdioFallbackExecuteCommandFeature.registerfails because a command from the previous, incompletely torn-down start is still registered.doInitializethen fails, the client restarts the server, and the same registration fails again ➡️ 678 times between 13:36:52 and 13:46:08. Since the extension host never reloads, the stale registration is never cleaned up, so the loop cannot recover on its own.Note the stack goes through
startWithStdioFallback.Attached: the Java extension client log for the session, redacted (user/machine/domain names, absolute paths, project and module names). One 68-line block of pre-existing compilation errors in our test sources was removed ➡️ unrelated to the loop, and it
contained internal class names.Sorry if, I am not that helpful. I am still at the beginning of getting used to development and this is my first bug report.
It seems like something from Spring Tools, perhaps that's the root cause?
On Spring Tools as root cause: the command in that first failure is indeed theirs, and the first
executeClientCommandfailure comes fromBootProjectTracker. But the version history argues against it being the cause:vmware.vscode-spring-boot2.3.0 has been installed unchanged since 2026-08-03 so five
weeks of normal use under vscode-java 1.55.0, no loop.- The loop appeared the day vscode-java updated to 1.56.0 and recurred on 1.56.0.
- Downgrading vscode-java to 1.55.0, with Spring Tools untouched, ended it.
@FilipBeckmann Thanks for the logs—they’re very helpful. We updated the startup fallback behavior in #4447, which shipped in 1.56.0. This change may be causing the issue you’re seeing, and we’ll dig deeper into it.
The 30-second startup fallback can leave the original pipe client running while starting a second stdio client, causing duplicate command registrations and endless initialization retries. As a workaround, set
"java.transport": "stdio"in VS Code settings and reload the window.@datho7561, could we revert redhat-developer/vscode-java#4447, since redhat-developer/vscode-java#4476 already brings in the upstream pipe-path fix that makes this workaround unnecessary?
Reacted by David Thompson and mozhuanzuojingThanks for the research and the Revert-Fix
🙋♂️
Description
A few hours after vscode-java updated itself to 1.56.0, the Computer hit 100% CPU/RAM with ~17 concurrent JVMs. They were Gradle daemons spawned by the language server.
The JDT log shows the server re-initializing in a loop: 169 ×
Initializing JDT Language Server (Standard)one every 20.2 s for an hour. Each cycle triggered a fullImporting Gradle project(s)and therefore a new daemon.Counting all daemon logs on this Computer (history back to 2025-09) and attributing them to the extension version via the
javaHomepath inDefaultDaemonContext:Same project, same Gradle version, same Computer. 1.55.0 ran for over two months and never produced more than 2 daemons on any day.
Daemons are launched with
-Xmx1024MandidleTimeout=10800000(3 h), so they accumulate faster than they finish.Logged at every one of the initializations (170 ×):
To Reproduce
I have not found reliable reproduction steps (see Additional Information). What led to the escalated case:
~/.gradle/daemon/<version>/— one newdaemon-*.out.logappears roughly every 20 seconds.Repeated VS Code restarts do not trigger it; each restart produces a single initialization.
Environment
1.61.0.202609021834)Additional Information
vscjava.vscode-gradle3.18.0 was not updated on that daygradle --stopcleared the processes.