[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)

[FilipBeckmann]

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 full Importing 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 javaHome path in DefaultDaemonContext:

Extension version	Active days	Daemons	Max/day
1.55.0 (2026-06-29 … 09-04)	29	37	2
1.56.0 (from 2026-09-04)	2	259	204

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 -Xmx1024M and idleTimeout=10800000 (3 h), so they accumulate faster than they finish.

Logged at every one of the initializations (170 ×):

!MESSAGE org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Unhandled method workspace/executeClientCommand
	at org.eclipse.jdt.ls.core.internal.JavaClientConnection.executeClientCommand(JavaClientConnection.java:89)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.synchronizeBundles(JDTLanguageServer.java:464)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer$2.run(JDTLanguageServer.java:324)
Caused by: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Unhandled method workspace/executeClientCommand
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:214)

To Reproduce

I have not found reliable reproduction steps (see Additional Information). What led to the escalated case:

1. Let vscode-java auto-update from 1.55.0 to 1.56.0
2. Open a multi-project Gradle workspace (Gradle 8.11.1, 4 projects).
3. Work normally. The language server entered the re-initialization loop on its own.
4. Watch ~/.gradle/daemon/<version>/ — one new daemon-*.out.log appears roughly every 20 seconds.

Repeated VS Code restarts do not trigger it; each restart produces a single initialization.

Environment

• Operating System: Windows 11 Pro 26200
• JDK version: bundled JRE 21.0.12.1 (Eclipse Adoptium)
• Visual Studio Code version: 1.136.1
• Java extension version: 1.56.0 (JDT LS 1.61.0.202609021834)

Additional Information

• vscjava.vscode-gradle 3.18.0 was not updated on that day
• Restarting VS Code did not help; only gradle --stop cleared the processes.
• ☝️ The loop still fires on every VS Code start (2026-09-07: 55 re-initializations, peaking at 16 daemons in one minute), but now stops by itself after ~20 minutes instead of running for an hour, so the load is no longer noticeable.
• ☹️ I cannot reproduce the escalated case on demand. Nothing changed in between — same versions, no fix released.

[wenytang-ms]

@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.

[FilipBeckmann]

Thanks 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 javaExtensions bundles here:

• vmware.vscode-spring-boot 2.3.0
• vscjava.vscode-gradle 3.18.0
• vscjava.vscode-java-debug 0.59.0
• vscjava.vscode-java-dependency 0.27.6
• vscjava.vscode-java-test 0.46.0
• vscjava.vscode-maven 0.45.3

Also installed: vscjava.vscode-java-upgrade 2.1.2, vscjava.migrate-java-to-azure 1.23.0, marlon407.code-groovy 0.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-workspace file.

Maybe this helps.

[wenytang-ms]

@FilipBeckmann Thanks for the additional details—we understand that you can’t share the proprietary project. The extension list, settings, and .code-workspace setup 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.