Repository navigation
JDTLS spawns redundant per-module processes in Java monorepos, causing OOM #11368
Description
Summary
In Java monorepos (e.g. Gradle multi-module projects), opencode spawns a separate jdtls process per submodule that the agent visits. Each process uses ~200-300MB of RSS, so a session where the agent explores 5 submodules accumulates ~1.2GB of jdtls processes. Across multiple terminal sessions this quickly leads to OOM.
Root cause
The JDTLS root function uses NearestRoot(["pom.xml", "build.gradle", "build.gradle.kts", ".project", ".classpath"]) (server.ts:1132). This walks up from the file being edited and returns the nearest directory containing a build file.
In a monorepo, every submodule has its own build.gradle or pom.xml, so each submodule the agent touches resolves to a different root. Since LSP client deduplication keys on root + serverID (index.ts:231), each unique root spawns a new jdtls process.
This is unnecessary — jdtls natively supports multi-module projects. Pointing it at the monorepo root (where settings.gradle or gradlew lives) lets it discover and handle all submodules with a single process.
Observed behavior
On a Gradle monorepo with ~100 submodules, 2 terminal sessions accumulated 5 jdtls processes:
PID 6789 → cwd: entry/foo
PID 9070 → cwd: entry/bar/qux
PID 13287 → cwd: entry/bar/corge
PID 13292 → cwd: entry/foo (duplicate, different session)
PID 17572 → cwd: entry/baz
Each has a unique -data temp dir and ~200-300MB RSS.
Expected behavior
A single jdtls process rooted at the monorepo root, regardless of how many submodules the agent visits.
Suggested fix
Give JDTLS the same root-finding strategy that KotlinLS already uses (server.ts:1234-1245) — prefer settings.gradle / settings.gradle.kts / gradlew (monorepo root markers) before falling back to build.gradle / pom.xml:
root: async (file) => {
const settingsRoot = await NearestRoot(["settings.gradle.kts", "settings.gradle"])(file)
if (settingsRoot) return settingsRoot
const wrapperRoot = await NearestRoot(["gradlew", "gradlew.bat"])(file)
if (wrapperRoot) return wrapperRoot
return NearestRoot(["build.gradle.kts", "build.gradle", "pom.xml", ".project", ".classpath"])(file)
},Related
Related to #7227 (LSP spawning for external directories) — both issues stem from the same pattern of spawning redundant LSP servers when a single instance would suffice.
Environment
- opencode v1.1.43 (Homebrew)
- macOS, Java 21
Activity
ainslec commentedon Feb 1, 2026
Having what looks like the same issue, multiple java processes, in my case 7 of about 1.6GB each. Leading to OOM exceptions on my machine when editing a single Java project on a PC with nothing else loaded apart from a browser with 5 tabs (with 32GB RAM).
akumaburn commentedon Feb 26, 2026
Same issue, ran out of 128GB of ram pretty fast, this is a major bug.
thijslemmens commentedon Mar 3, 2026
I worked around this by writing a wrapper script for jdtls. I use this as the java lsp instead of the OOTB. I can share if people are interested.
fabians-px commentedon Mar 3, 2026
@thijslemmens absolutely!
thijslemmens commentedon Mar 3, 2026
@fabians-px
jdtls-gradle
jdtls
opencode.json
{ ... "lsp": { "jdtls": { "disabled": true }, "java": { "command": ["jdtls-gradle"], "extensions": [".java"] } } }You need to install jdtls manually. I used https://www.eclipse.org/downloads/download.php?file=/jdtls/milestones/1.57.0/jdt-language-server-1.57.0-202602261110.tar.gz
jiayaoO3O commentedon Mar 6, 2026
@thijslemmens For Maven projects, is there a way to identify the root directory? README.md?
thijslemmens commentedon Mar 6, 2026
Not using maven. I think to do it properly, you have to parse pom files. A workaround could be that you place your own marker file in the root.