Apache NetBeans version
Apache NetBeans 25 (observed on RELEASE300, still present on RELEASE310)
Bug description
Summary: When one LanguageServerProvider is registered for multiple MIME types with a class-level @MimeLookup.Registration / layer class registration, LSPBindings starts one language-server process per MIME type instead of reusing the running server, because its server-reuse map is keyed by provider instance — and a class registration places a separate .instance in each mime folder, each instantiated independently.
Measured effect (in a NetBeans-Platform-based IDE using ide/lsp.client, with providers registered for both text/javascript and text/typescript):
- two
typescript-language-server processes for a single mixed JS/TS project,
- two
deno lsp processes for one deno workspace,
- two
ngserver processes in an Angular project with a component (.ts) and its template open.
Each extra process is a full tsserver-class JVM/node footprint per project, silently.
Mechanism (from reading the RELEASE300/310 LSPBindings source/bytecode): buildBindings files a started server under every declared mime only when the same provider instance is presented for each mime folder. With a class-level registration, the second mime folder resolves a different instance of the same provider class, misses the reuse map, and a second server process is spawned. Shutdown being GC-driven (LSPReference + keep-alive) means both processes then live for the session.
Workaround we ship: converting every multi-mime provider registration to a static singleton factory method (methodvalue registration), so every mime folder resolves the same object. That fixes it completely — A/B measured 2 processes → 1 — but the requirement is undocumented and very easy to violate (we re-introduced it once via a three-mime CSS provider before gating registrations structurally).
Steps to reproduce
- Register one
LanguageServerProvider class for two mimes (e.g. text/javascript and text/typescript) with a plain class-level registration.
- Open one file of each mime from the same project.
- Observe two identical language-server processes for the project (e.g.
pgrep -fl typescript-language-server).
Expected behavior
One server process per project for a provider declared on multiple mimes — or, failing that, a documented requirement that multi-mime providers must be registered as singletons.
Suggested fix directions: key the reuse map by provider class (or by the provider's declared mime set), or have MimeLookup resolution for LanguageServerProvider treated as singleton-per-class in LSPBindings. Happy to provide more detail or test against a patch — we carry a structural test (registrations == getMimeTypes(), no class-instance backdoor) that could inform one upstream.
Context
Found while building NMOX Studio (Apache-2.0, NetBeans-Platform based): https://github.com/NMOX/NMOX-Studio — details in our engineering ledger entry 83 (docs/engineering/tech-debt.md).
Apache NetBeans version
Apache NetBeans 25 (observed on RELEASE300, still present on RELEASE310)
Bug description
Summary: When one
LanguageServerProvideris registered for multiple MIME types with a class-level@MimeLookup.Registration/ layer class registration,LSPBindingsstarts one language-server process per MIME type instead of reusing the running server, because its server-reuse map is keyed by provider instance — and a class registration places a separate.instancein each mime folder, each instantiated independently.Measured effect (in a NetBeans-Platform-based IDE using ide/lsp.client, with providers registered for both
text/javascriptandtext/typescript):typescript-language-serverprocesses for a single mixed JS/TS project,deno lspprocesses for one deno workspace,ngserverprocesses in an Angular project with a component (.ts) and its template open.Each extra process is a full tsserver-class JVM/node footprint per project, silently.
Mechanism (from reading the RELEASE300/310
LSPBindingssource/bytecode):buildBindingsfiles a started server under every declared mime only when the same provider instance is presented for each mime folder. With a class-level registration, the second mime folder resolves a different instance of the same provider class, misses the reuse map, and a second server process is spawned. Shutdown being GC-driven (LSPReference+ keep-alive) means both processes then live for the session.Workaround we ship: converting every multi-mime provider registration to a static singleton factory method (
methodvalueregistration), so every mime folder resolves the same object. That fixes it completely — A/B measured 2 processes → 1 — but the requirement is undocumented and very easy to violate (we re-introduced it once via a three-mime CSS provider before gating registrations structurally).Steps to reproduce
LanguageServerProviderclass for two mimes (e.g.text/javascriptandtext/typescript) with a plain class-level registration.pgrep -fl typescript-language-server).Expected behavior
One server process per project for a provider declared on multiple mimes — or, failing that, a documented requirement that multi-mime providers must be registered as singletons.
Suggested fix directions: key the reuse map by provider class (or by the provider's declared mime set), or have
MimeLookupresolution forLanguageServerProvidertreated as singleton-per-class inLSPBindings. Happy to provide more detail or test against a patch — we carry a structural test (registrations == getMimeTypes(), no class-instance backdoor) that could inform one upstream.Context
Found while building NMOX Studio (Apache-2.0, NetBeans-Platform based): https://github.com/NMOX/NMOX-Studio — details in our engineering ledger entry 83 (docs/engineering/tech-debt.md).