Eclipse Is Learning New Protocols

The Eclipse IDE is a mature and modular platform for all kinds of software tools. It is used by millions of engineers and developers getting their work done every day. Reaching this state of maturity has been a huge effort for the Eclipse community and took more than 15 years. The immense care for code quality, pluggability, and API stability has always been one of the main reasons for me to leverage Eclipse technology in many projects.

The World Has Changed

While the Eclipse Platform grew naturally over the years through its extensible plug-in model, it still requires a set of technologies that constrains how an extension is developed.

At the basis, there is the requirement for Java, which seems to be fine as Java is still one of the most popular programming languages in the world. But of course, it is problematic if you want to reuse an Eclipse technology that is implemented in another language. Furthermore, it is unnatural to require Java, if you are developing programming language support for another language, such as C/C++.

An even bigger problem is the UI technology. Over the past few years there have been many discussions in the Eclipse community about how to get over the limitations of the Standard Widget Toolkit (SWT) or to move to a modern UI technology. With the arrival of e4 Eclipse got support for styling UIs with CSS. Since that is incomplete due to technical limitations in CSS, there have been efforts to replace SWT or at least the rendering underneath with other technologies, such as JavaFX or OpenGL. Even Eclipse RAP is an attempt to preserve what we have by porting SWT to a modern UI technology (web).

While these efforts would solve a few issues, they still require us writing our code against the aged SWT API and concepts. If you are building a product, the UI is probably the last place where you want to make compromises.

Other movements in the community realized that sticking to SWT would possibly be problematic in the long run and started writing new IDEs from scratch. Eclipse Che and Eclipse Orion are both IDEs running in the browser and are implemented using web technology. While this clean slate approach gives you the most flexibility, it also means you need to rewrite everything, or at least the parts that you still consider important.

To be honest, SWT has done a fairly good job over time, but it didn't catch up with the alternative technologies. Today I can only recommend that everyone has a look at web technologies for building UIs. Frameworks like React or Angular 2 provide new, exciting programming models for developing beautiful user interfaces. Electron even lets users build desktop applications with web technologies, and through a browser widget, it’s possible to embed web components in Eclipse RCP applications, too.

… And It Changes Faster

The Eclipse Community, as well as all other IDE vendors, are having a hard time keeping track of the latest developments. Especially in the web technology space, we see new languages and frameworks popping up every other Monday, and it is almost impossible to build a plug-in for them before it is outdated again. To build Eclipse tool support for a language or framework, often we need to reimplement a certain amount of semantics in the plug-in, which means duplicating code and information in the plug-in that is already present in the technology itself. As a result, tool support will always lag behind if we cannot find a sustainable way that lets the language and framework developers themselves care about it.

Protocols Are Here to Help

Microsoft is aware of these advancements, too. Their latest cross-platform development tool, Visual Studio Code (VS Code), is designed in a way that allows users to reuse existing code written in any language. The idea is to use platform-independent protocols to communicate with external processes. With such a separation you have a clear interaction layer, that separates two components from each other in distinct ways. It not only allows the implementation of a VS Code extension in any programming language, but it also lets users use those extensions in other UIs or IDEs, as long as they understand the same protocol.

The separation of extensions in external processes has other benefits, too. For instance, in VS Code a plug-in cannot tear down the whole editor. It is also impossible to block the rendering thread through such an extension.

VS Code has defined two such protocols so far, a debug protocol to interact with running processes and a language server protocol (LSP) to interact with components that can provide language-specific services such as completion, refactorings and so on.

The Language Server Protocol @ Eclipse

In April my team was working on a product based on Eclipse Che. For that project, we needed to enhance Che with tool support for a language implemented in Eclipse Xtext. Since Xtext already supported the Eclipse IDE, Intellij IDEA, and several web editors at that time it had grown a big fat with all those platforms and adding support for yet another editor seemed wrong. Instead, I was looking for a more sustainable way to make Xtext future-proof without the need to add and maintain new editor platforms every six months.

A ubiquitous protocol, like VS Code's LSP, would solve this issue, especially when it is popular enough that the editor vendors would support it natively. Given the credibility and impressive track-record of the team behind VS Code (they worked on several IDEs before, including the Eclipse IDE) and the backup of Microsoft, it seemed like a good idea to push this forward.

So I discussed with the Che developers to see if they were interested in supporting the LSP and built a proof-of-concept for them. Luckily, they were very open and interested and took it over to fully implement it. Today, Eclipse Che 5.0 comes bundled with support for several additional programming languages based on the LSP.

At the around same time, Red Hat and IBM joined forces to work on a JDT-based language server, which you can already find in the VS Code's extension marketplace. With that, they leveraged the hard work that was put into JDT and use it in other IDEs and editors. For instance, just back in November, IBM presented a prototype at EclipseCon Europe that showed Eclipse Orion using the JDT language server.

The Eclipse LSP4E project aims at bringing language servers to the Eclipse IDE. Language support for C#, JSON Schema, and much more, will soon be connected to our favorite IDE through this.

Finally, with Eclipse Xtext 2.11 supporting the LSP, we now have a mature language development framework that lets you build language servers quickly. In parallel to the LSP support, we have split-up Xtext into smaller modules and the new Xtext-core module only contains the platform-independent code to implement a language server.

Beyond all these efforts, we have the Eclipse LSP4J project, which defines Java types and signatures of the LSP. It is used by the various Eclipse technology efforts listed above and by other language servers implemented in Java.

Conclusion

The adoption of the LSP is a huge win-win for many efforts within the Eclipse community. On one side, it allows using the rich language support infrastructures from projects like JDT and Xtext in other tools and on the other side, it provides an easy way for the Eclipse IDE to support new languages and frameworks in the future.

Furthermore, web technologies have become the most promising UI technology for both desktop and web applications. Vendors that have chosen Eclipse RCP as a basis in the past will more likely resort to a web-based alternative in the future. Using platform-independent protocols will allow us to keep using core Eclipse technologies in these new exciting environments.

The LSP has only started to shake up a couple of Eclipse technologies giving new perspectives for future developments. I’m certain there will be even more projects joining in on this effort in 2017. So stay tuned or better engage!