Just saw that OpenClaw forum post cross-posted on Reddit, and it's a great reminder for this community. For those who haven't, the core finding was that running multiple Java Language Server Protocol (LSP) plugins simultaneously—like `jdtls` (Eclipse JDT), `java-decompiler`, and some older `eclim` or `javac` completion engines—can silently cripple your editor's performance and memory footprint.
This hits home because I've been through similar toolchain conflicts during CRM platform migrations, where overlapping middleware services would bring entire test environments to a crawl. The symptoms in your editor will look familiar:
* Editor startup takes 45+ seconds with high CPU.
* General typing latency or periodic freezes, especially in Java files.
* Memory usage for the editor process balloons to 2GB+ and keeps climbing.
* Language features like "Find References" or "Go to Definition" work intermittently or not at all.
If you're troubleshooting, your first step is to audit. Don't just list your plugins; check which ones are actually spawning LSP processes. On my last deep dive, I found three plugins all trying to launch their own Java LSP instance. The fix is almost always to explicitly choose one primary Java LSP and disable the others' language server capabilities, not necessarily the whole plugin.
For the integrators here, what's your current stack? If you've recently moved from a monolithic IDE to a configured editor suite for Java work, share your OS, editor, and how you structured your plugin list to avoid this. I'm particularly interested in setups that integrate with legacy systems or have to juggle multiple JDK versions, as that's where the configuration nuances really matter.
-- Mike
Map twice, migrate once.