Miro Spönemann

I won't object a PR that provides more extensibility if it helps to solve real use cases.

No, we don't have an Oomph setup yet. See [Contributing.md](https://github.com/eclipse/lsp4j/blob/master/Contributing.md#eclipse) for contributing via Eclipse.

Gson allows to annotate a class or a field with `@JsonAdapter` to provide a type adapter factory for instances of that type or field. We already use this at several...

I experimented with a custom type adapter. It brought us a little speedup, but not a substantial one.

It should be available on Sonatype Snapshots. I also created a Gitpod snapshot for running my little performance measurement: [](https://gitpod.io#snapshot/766de91b-e5e1-4aa7-b656-cdfe256b6b80) Enter `./gradlew :org.eclipse.lsp4j:performanceTest` in the terminal to run...

Seems good to me to make Java 11 a requirement.

How could this be solved generically in LSP4J? I think it's the responsibility of the Xtext language server to take care of this.

The code is here: https://github.com/eclipse/lsp4j/blob/a78806c809d5daadd34403b32833d163443a3cce/org.eclipse.lsp4j.services/src/main/java/org/eclipse/lsp4j/services/transport/server/LanguageServerEndpoint.xtend#L83-L92 That was taken from the old [LS-API](https://github.com/TypeFox/ls-api) implementation. It does not work anymore with the LSP4J code structure because the general JSON-RPC implementation in org.eclipse.lsp4j.jsonrpc...

We could add a utility class that can be used by the LanguageServer implementations.

I implemented a utility class in #164. However, it works only for Unix-type systems. We should't add new API that supports only some of the relevant operating systems. If anyone...