If you're a regular on this blog, you're probably well aware of Red Hat's efforts in improving the Eclipse IDE and of the rise of Language Servers Protocol to develop common developer tools. Red Hat fully jumped on this opportunity to better factorize and share language-specific logic which is very likely to benefit to multiple editors, IDEs and languages at once. It also better separates the concerns of what an editor or IDE is supposed to do (text edition, integration with SCM, debug and deployment workflows...) with the target language itself. With this approach, a single language server can enable language features to multiple development tools at once, and a single development tool can be made more generic to support new languages for free, just by binding to the language server through the protocol. [caption id="" align="aligncenter" width="583"]
Basic interaction diagram (from LSP documenation - from https://github.com/Microsoft/language-server-protocol )[/caption] This summer, some of us took part of a hackathon dedicated to Language Server Protocol and one of the main realizations was the Java Language Server based on the great Eclipse JDT, and it's VSCode extension packaging which already reached a high popularity on the VSCode marketplace. This hackathon was also an opportunity to bootstrap the support of the Language Server protocol in the Eclipse IDE. Let's get deeper into this last integration and what great things it implies for the Eclipse IDE. Most operations supported by the Language Server Protocol do already map correctly to language-agnostic Eclipse IDE concepts: Commands, Navigator, Outline, Document, Problems markers... The Eclipse IDE and its strong and relevant legacy can almost trivially integrate most LSP operations and already has the UI elements and workflows to properly interact with them. However, as we were working on how to improve support for new languages (that we made a theme of the future Eclipse 4.7 release), we realized that there was a room where Eclipse IDE wasn't really easy to extend: the editor itself. Indeed, rather than fully relying on extensibility as usual in the Eclipse Platform, the editors were assuming that every language required to have its own editor subclass, introducing new UI artifacts and requiring a lot of boilerplate to initiate a language edition support. We had to provide something better, and we did: in the last milestone, we delivered what we called a Generic and Extensible Editor in the Eclipse Platform. This editor is meant to serve all possible programming languages, and will receive specific extensions for syntax highlighting, code completion/intellisense, hover documentation... according to the language that's being used. Compared to the usual subclassing approach, this more "composition-oriented" architecture has allowed to very quickly write multiple example editors in a very short timeframe. A key item of this editor is that it's not introducing any new class nor framework, it's just reusing the usual JFace classes every editor is using, and allow you to "plug" them into the editor. Sopot Cela and myself had the opportunity to present and demonstrate this at EclipseCon Europe, here are the slides:
From there, we had a decent generic and extensible editor in the Eclipse Platform, the natural next step was to plug some of the features of from the Language Server Protocol (mainly hover documentation and completion, that were not generic in the Eclipse Platform before this change) as extensions to the extensible editor. Work is currently happening in a GitHub repository, which receives contributions from multiple people and organizations. The integration with language servers happen to work pretty well: Eclipse Platform already had most of the necessary logic, and the Eclipse LSP4J Java API we're using for the communication conforming to the protocol is pretty nice to use and leverages Java's asynchronous CompletableFuture is a quite efficient way. Here you can see it in action: https://www.youtube.com/watch?v=t-2XAgXvU3g&feature=youtu.be This integration in Eclipse IDE is going to move to Eclipse.org very soon, under the name Eclipse LSP4E, and is very likely to be used to support new languages for the Eclipse Oxygen release (June 2017). Some of the most noticeable language that already have Language Server conforming to the LSP are C#, Rust, Go, OCaml... The full list is actually visible at https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations . So this is definitely a big time for the Eclipse IDE: the Generic and Extensible editor has improved the productivity and simplicity (then time to market) of creating support for new languages, and the upcoming LSP4E project will allow to "leech" the language servers to provide most edition tools. We're convinced that this will really allow the Eclipse IDE to have better support for more and more languages faster. What an exciting release Oxygen is going to be! (Note that both the Generic Editor and the Language Server integration could actually work with Neon, so maybe you'll even see language support popping by before June...) [caption id="" align="aligncenter" width="452"] Current Eclipse IDE "Oxygen" splash screen proposal[/caption]
