Refactor Eclipse-specific tooling into language servers

In this talk we discuss your experiences replacing existing tooling with a language server based implementation and the challenges that we faced along the way.

In the past, we implemented tooling for Spring and related projects as plugins for Eclipse. Those plugins used the API of the underlying platform and integrated deeply with in the Eclipse IDE to provide a unique experience when working with Spring applications in Eclipse. The good part of that story was the unique and deeply integrated developer experience within the Eclipse IDE. The bad part of this story was that our tooling was specific for Eclipse and we weren’t able to re-use it (or even parts of it) for different environments, like other IDEs, cloud IDEs, or command-line tools. The architecture around the language server protocol promised to solve this limitation and we decided the give it a try. We re-implemented the editing support for Cloud Foundry manifest files (including syntax highlighting, content-assist, quick-fixes, smart editing, and dynamic connections to cloud environments) as a language server and tried to replace the old implementation that we had in Eclipse with the new language-server-based one. The challenge was to replace the old implementation without the user noticing any difference - and provide the same awesome user experience in VS Code (or and other clients) by re-using the exactly same language server.

The talk summarizes the experiences and gives advice how to refactor existing Eclipse plugins in tools based on the language server protocol.

Speaker(s):
Martin Lippert (Pivotal)