Run LemMinX-Maven LS in the same Java process?

[HannesWell]

@mickaelistria you mentioned that it is possible to launch the Language-Server in the same Java process:
https://www.eclipse.org/lists/platform-dev/msg03696.html

I wonder if that would be beneficial for M2E as well? On my Windows-Computer M2E occasionally fails to connect to the LS-server or ends with time-out errors. I have not yet investigated that further, but could the connection become more robust when the LS-server runs in the same VM?

[laeubi]

See

• Autocompletion is ultra-slow eclipse/lemminx-maven#295
• Editor is very laggy for certain actions eclipse/lemminx-maven#288

The lemminx Editor makes it really hard to edit pom files and copy+paste with shortcuts is simply unusable as it is completely random what part is copied/inserted ... So if we can improve this by runin it it inline that would be good, still I would expect that connecting to "localhost" would be equally fast if we are not transferring hundreds of megabytes of data ...

[mickaelistria]

I wonder if that would be beneficial for M2E as well?

That's how we 1st tried this language-server integration story, but it had tons of drawbacks for very low functional value:

• First, LemMinX-Maven is an extension of LemMinX, so the deployment of LemMinX-Maven in Eclipse IDE has to be compatible with how LemMinX. LemMinX is currently embedded as a uber-jar
• By changing how we run/deploy language servers compared to vanilla deployment, then we diverge from the tested scenarios and are vulnerable to some issues that would be specific to our deployment. This is even more obvious with OSGi that changes some classloading strategies; trying to load a LS that does classpath inspection to run it in OSGi is likely to fail.
• By taking ownership on the deployment, then we also are vulnerable to dependency incompatibilities that would only surface only in our deplyment
• It's actually more work to maintain a different deployment than to embed the vanilla one

So IMO, it's really not a sustainable path to follow.

On my Windows-Computer M2E occasionally fails to connect to the LS-server or ends with time-out errors. I have not yet investigated that further, but could the connection become more robust when the LS-server runs in the same VM?

This is usually not the result of a connection issue, but some bug in the underlying language server that becomes stuck and doesn't answer.

So if we can improve this by runin it it inline that would be good

The connection doesn't change anything visible indeed. The issue you've mentioned are internal to lemminx-maven and would still happen if the LS was started in any different deployment.

[laeubi]

So IMO, it's really not a sustainable path to follow.

You can embed an OSGi Framework inside a running one to get a (mostly) isolated environment, and such an uber-jar can actually be a OSGi bundle that has nothing more than an activator that starts the "main" and open the TCP port as if this where an own process. So I think all those drawbacks are more a matter of how one actually embeds the thing.

The issue you've mentioned are internal to lemminx-maven and would still happen if the LS was started in any different deployment.

It would be good if I can enable some kind of logging to capture useful information, so embedding might improve at least the ability to use the same error log and tracing facilities than the running host.

[HannesWell]

* [Autocompletion is ultra-slow eclipse/lemminx-maven#295](https://github.com/eclipse/lemminx-maven/issues/295)

* [Editor is very laggy for certain actions eclipse/lemminx-maven#288](https://github.com/eclipse/lemminx-maven/issues/288)

I regularly encounter similar issues.

I'm not familiar with the details but what Christoph suggested is similar to what I had in mind to, why not simply run the entire language server in the same VM? Maybe this gives better error messages and simplifies debugging?

In general the whole language server and Editor story is a bit fragment to me and I'm not sure I fully understand it.
We have

• lsp4j the 'java-implementation of the language server'?
• LemMinX the XML language definition/implementation for the LS?
• LemMinX-Maven a Maven/pom.xml extension for LemMinX?

All that runs in the LS-Server VM at the moment?
And lsp4e exists to connect Eclipse with a running Language-server and runs in the Eclipse-VM?

And is wildwebdeveloper also involved? At least M2E has dependencies on that and IIRC it is also in the area of editors.

Is there any document that describes the story as a whole to get a overview about that?

[mickaelistria]

why not simply run the entire language server in the same VM? Maybe this gives better error messages and simplifies debugging?

It's not "simply", it's not even "simpler" and it wouldn't bring better performance, nor better quality nor better maintainability over a separate process.
The error messages are simply not logged by lemminx-maven, it's not a deployment issue, it's just that errors are not caught and logged in the code. If you want lemminx-maven to log more, then just changing lemminx-maven and setting some logging options in Wild Web Developer should be enough.
To debug, it's already relatively easy, just set a value to org.eclipse.wildwebdeveloper.xml.internal.XMLLanguageServer.debugPort and attach a remote debugger and you're done.
Debugging a client and a server simultaneously when they're in the same process is trickier than when they're in different process, as some combinations of breakpoints can cause deadlocks or similar issues.

Wild Web Developer provides the XML Language Server (LemMinX) integration, building the process. LemMinX is extensible, lemminx-maven is 1 extension. m2e does declare the extension for lemminx to wild web developer.
LSP4J does the transport (talk on stream) and message management (provide model of objects that are then turned to request/response/notifications according to the LSP spec). LSP4E gets the connection (streams) to the LS from an extension such as Wild Web Developer and then orchestrate how messages coming from LSP4J are sent/received/handled in the IDE according to the LSP specification.

But really, the beauty here is that the deployment doesn't really matter and we can go for the simplest (a process) and get the same final quality as if we had a very smart deployment.
If there are bugs, they're either in the language server or LSP4E; and whatever deployment make them equally complicated to troubleshot.

[HannesWell]

OK we then don't gain anything by running the server in the same VM.

Thank you for your elaboration and I will try to debug the issues if I encounter them the next time and can then hopefully provide some useful information.

[HannesWell]

With the recent discussion in #848, I think it is worth to think about this again as a way to improve the integration of the LSP in m2e and to reduce doubled resource usages.

@mickaelistria IIRC in the Eclipse IDE 2023-06 Webinar you mentioned that the the JDT-LS is running in the same process as the IDE, which allows to tighten the integration between JDT and the LS by share states? Wouldn't the benefits for JDT-LS also apply to m2e?

[mickaelistria]

JDT LS is a headless Eclipse RCP application (it's actually JDT-Core and deps + 1 extra bundle), it's OSGi-ready in 1st place and runs well in the same OSGi container and other Eclipse plugins. It actually easier to run it in the same process OSGi container than to run it in different process.
LemMinX is a standalone Java application, which is not tested to run under OSGi and OSGi is not its first deployment form. Its extensibility happens with classpath addition, which need to be set before the process is starting. The lifecycle and packaging are much more different.
So while running in the same process could be interesting, there is not much to compare wth JDT-LS.