The language server protocol will revolutionize how you code

The next generation Spring Boot tooling has been completely refactored to be based on the language server protocol (LSP). The tooling covers things like code assist for the Spring Boot property file, support for Cloud Foundry manifest files as well as Spring Boot support for Java files with typical features such as validation, content-assist and quick-fixes.

Beyond IDEs

This new generation of Spring tools, Spring Tools 4, will be fully unveiled at the SpringOne Platform conference later this year. Traditionally Spring tooling was written in Java as Eclipse plugins and could not be reused in other developer environments. The language server protocol enables Spring tooling to go beyond Eclipse and provide similarly great user experiences for Atom and Visual Studio Code, and likely any platform which implement language server clients. The list of clients supporting LSP is growing fast, even with Vi and emacs featuring it on their road-maps. In fact, the notable exception is IntelliJ. The market leader already has a well established language extension framework and the resources to keep up with language changes. It will be intriguing to see when and if they jump on the bandwagon and acknowledge the users banging the door down.

Every Programming Language that Matters

On the server side the number of protocol implementations is growing fast. There were 27 implementations back in June, my current count stands at 46. LSP easily makes sense for newer modern languages such as Typescript and Go, not to mention any domain-specific language. When it comes to languages with great IDE support such as Java, LSP is a big step back in functionality. However this could change quickly as the pace of Java releases quickens. Even for C/C++, LSP presents a chance to start afresh with a new approach.

LSP: The Good, Bad & Ugly

At EclipseCon Europe, Martin Lippert spoke about Pivotal’s journey to get Spring tooling to this stage and the good, bad and ugly of language server protocols. Here are some of the highlights of his insights.

Good: Write once, run everywhere

It is a no-brainer for toolsmiths to switch to something which enables them to creating tooling just once and make it readily available across different tools.

• building lightweight tooling (separation of client/server)
• the freedom of starting fresh
• building the tooling once and reusing it across various environments
• isolated testing
• writing tools in the language most suited to the job

Bad: More features, better integration?

LSP covers many language features but is not feature-rich. Syntax highlighting is not included though readily handled by Textmate grammars. Other features such as advanced refactoring should fall within the remit of LSP so hopefully this will only  be a matter of time.

Additionally there is no communication between language servers. If the Spring language tooling provides completions for Java in a property file, will it be able to reuse an existing Java LSP or does it have to launch its own and redo all the indexing and parsing work?  As things scale this will be interesting to see how interactions between language servers can best be handled.

Ugly: More protocol please

The protocol itself isn’t quite enough of a protocol and still leaves room for interpretation. Which means the promise of client-agnostic language servers doesn’t fully exist yet. Currently each client behaves differently. For example each client has its own way to start a server and define an extension. Additionally every client is different, which for now means feature flags per client to work around issues, for example, for magic indentation on multi-line code completion (VS Code client indents using its own rules, Atom defers to the language server). Having more standardization on client implementation specifics and things like a client registry would make all the difference here.

Language Server Protocol is the future of language tooling

What Martin’s talk and the Spring tooling underlines is that there is no longer much debate about whether LSP is the future of language tooling. Now the conversation has shifted to what’s missing and how do we improve it. Developer communities and toolsmiths are restructuring to work together, be more effective and as a result revolutionize the landscape of our language tooling options.