how to marry serena with other language LSPs?

[charger89]

I have claude's jdtls-lsp plugin installed together with the external LSP server.

How to marry this use together with Serena? Would the external LSP server and the claude plugin need to be uninstalled? Would it still be possible to continue using eclipse.jdt.ls for just java, and fall back to Serena-backed LSP for other languages? Would there any reason to even prefer the claude plugin+jdtls-lsp over Serena's Java support? What about other language -- would Serena's built-in LSP offer the same feature set/performance as the language-specific counterparts?

[MLuc24]

There's nothing to marry, because for Java they're the same language server. Serena ships src/solidlsp/language_servers/eclipse_jdtls.py — it drives eclipse.jdt.ls, the same project you installed externally.

It doesn't go looking for a system install either. It downloads and pins its own copy, with hashes:

releases (JRE bundle, Lombok jar, Equinox launcher all have versioned filenames inside
the VSIX), so we pin them per-version alongside SHA256 — bumping the VSIX version means
bumping these too.

JDTLS_MIN_JDK_VERSION = 21

So to take your questions in order — no, you don't need to uninstall anything. Serena spawns its own JDTLS process from its own pinned artifacts, and the plugin spawns its. They don't share state, config, or a socket, so there's no conflict to resolve. And yes, you can keep using the plugin for Java while Serena handles other languages; nothing forces Serena to be the only symbol provider in the editor.

The one real cost of running both on a Java project is that you get two JDTLS instances indexing the same workspace. That's two JVMs and two copies of the project model in memory, which on a large codebase is noticeable — not a correctness problem, just wasteful. If you find yourself using Serena's Java tools anyway, dropping the separate plugin is the easy saving.

On whether to prefer one: since the engine is identical, the difference is only in what sits on top. The plugin exposes LSP operations fairly directly; Serena wraps the same server in symbol-level tools aimed at agent use. Neither has better Java understanding than the other, because the understanding is JDTLS's.

Your last question is the one where the answer varies by language, though. Serena's language_servers/ directory is a per-language set — eclipse_jdtls.py, kotlin_language_server.py, basedpyright_server.py, bash_language_server.py and so on — so in each case it's running the same standard server the ecosystem uses, not a homegrown substitute. Where the experience differs between languages, it's because those upstream servers differ in maturity, not because Serena's layer is thinner for some of them.