[lsp4e-dev] Documentation request: Using LSP4E or LSP4J with non-Java se

[Jörn Guy Süß <jgsuess@xxxxxxxxx>]

Hello!

We (codebots.com) would like to create a headless client in Java that responds to changes in different pre-existing language servers that are not implemented in Java. The client will be embedded in an Eclipse plugin that runs headless.

We are looking at this list of servers, and aim to instantiate many of them: https://langserver.org/#implementations-server

We are aware of the instructions to start a language server like lsp4j (https://github.com/eclipse/eclipse.jdt.ls#user-content-running-from-the-command-line), and of the need to Implement the Language Server interface (https://github.com/eclipse/lsp4j/blob/master/documentation/README.md#user-content-implement-your-language-server), but we have not found any guidance on how this should be done for an existing server.

Given that language servers are meant to be separate processes intended to abstract from underlying concrete languages semantics, we believe that the org.eclipse.lsp4j.services.LanguageServer implementation has to be responsible for starting the server and marshalling data for the server. But from the examples it is not obvious how an existing server needs to be exposed. All examples seem to assume that the server is implemented in the host language.

Our lack of understanding of existing servers is a blocker for us to adopt the technology. It would be great if there was documentation to describe how this is done.

Assuming reuse is possible, we are also interested in understanding which aspects of LSP4E we can reuse for our headless application, given that most exposed extension points are concerning UI events that probably require widgets to be present.

We are posting this question to the developers list, as we believe that this is an important question regarding existing documentation.

If the answer is that cross-languages reuse of LSP servers is not possible, then we feel this should be clearly stated, as this would imply a substantial limitation of the technology.

Best wishes,

Jörn Guy Süß