"There is already a command line for it, why can't my favorite editor support this language?" As a developer, you're probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.
Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result, developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.
IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed --- for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.
As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.
Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.
We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best --- we think this results in better IDEs and editors.
Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.
Today, we announced that we are working together with Microsoft and CodeEnvy to create a new open protocol for language services. Our plan is to adopt and enhance the language server protocol used by Visual Studio Code to become a common way to enhance editors and IDEs.
The protocol is based on JSON-RPC 2.0, and defines a series of calls and data structures for implementing common language functionality on IDEs and editors. The calls on the protocol can either require a response or be a notification as supported by JSON-RPC. They can also be initiated from both IDE or the language server. For example the PublishDiagnostics notification is initiated by server to typically report compile results to IDE.
The protocol does not depend on a transport layer such as HTTP, which proves to be a big advantage because it allows the server implementations to be used not only on desktop IDEs and editors but allows them to be used by browser based IDEs such as Eclipse Che via a simple transport change.
Our implementation of a Java language server --- which was demoed in the DevNation General Session --- is also available as an open source project. Although I consider the implementation to be a prototype, it already provides some of the essential features for language tooling.
The server uses projects such as Eclipse JDT and M2Eclipse to implement these features, hence it can be considered a headless mini Eclipse IDE. The implementation currently implements a transport that uses named pipes on windows and Unix domain sockets on Linux and MacOS. We have plans to create a framework and introduce more transports that can be used to build servers and clients running on Java VM.
The work on both the Java language server implementation and the enhancements on the language server protocol is just getting started, and we welcome anyone who would like to be involved. Please don't be shy --- visit us at GitHub projects for language server protocol and the Java language server to find out ways that you can contribute!
For additional information and articles on .NET Core visit our .NET Core web page for more on this topic.
Last updated: May 8, 2024