Decoupling Language and Editor - The Impact of the Language Server

Protocol on Textual Domain-Speciﬁc Languages

Hendrik B

under

itemis AG, Bonn, Germany

Keywords:

Textual Domain-Speciﬁc Languages, Model-Driven Development, Language Server Protocol, Case Study.

Abstract:

Model-Driven Software Development using Domain-Speciﬁc Languages (DSL) has been widely adopted

throughout research and industry. The language workbenches required to efﬁciently build Domain-Speciﬁc

Languages and the associated editor support are often deeply integrated into a speciﬁc Integrated Development

Environment (IDE). Thereby, the chosen Domain-Speciﬁc Language workbench predicts the IDE required to

use the DSL. Yet, this IDE might not be the best choice for further implementing, testing, and debugging the

generated code. A case study was conducted to analyze how the Language Server Protocol could be utilized

to decouple the DSL implementation from a speciﬁc editor integrated into an IDE. First, the Language Server

Protocol capabilities are exempliﬁed by building editor support for an Entity-DSL that is integrated into two

different IDEs. Second, a SWOT analysis is carried out to identify strengths and weaknesses as well as oppor-

tunities and threats for Domain-Speciﬁc Languages utilizing the Language Server Protocol. The case study’s

results indicate that the Language Server Protocol enables efﬁcient multi-editor integration. Further, the results

of the SWOT analysis imply potential beneﬁts for cross-functional teams specifying a shared domain model.

1 INTRODUCTION

Model-Driven software development focuses on the

abstract, formal description of domain models, that

declaratively describe real-world concepts. Model-to-

model and model-to-text transformations interpret the

domain models and eventually create source code and

conﬁguration ﬁles that constitute the executable soft-

ware system (Sendall and Kozaczynski, 2003). Tex-

tual Domain-Speciﬁc Languages are used to specify

domain models using a textual concrete syntax. In

contrast to general purpose programming languages

such as Java, textual Domain-Speciﬁc Languages are

tailored to a narrow problem area for which they of-

fer concise and semantically rich notations (Hudak,

1997). Due to sophisticated editors that offer lan-

guage smarts, such as code completion, goto deﬁni-

tion, and validations, modelers create domain models

efﬁciently and correctly.

In order to implement a Domain-Speciﬁc Lan-

guage with an associated editor, language work-

benches, such as MPS (Campagne, 2016), MontiCore

(Krahn et al., 2014), or Spoofax (Kats and Visser,

2010) can be utilized. Yet, the mentioned language

workbenches are deeply integrated into speciﬁc In-

tegrated Development Environments, such as Intel-

liJ (JetBrains, 2018) or Eclipse (Vogel and Beaton,

2013). While the deep integration enables semi-

automatic, efﬁcient creation of language editors, it

also causes a tool lock-in by interweaving the DSL

editor with a speciﬁc IDE (V

olter, 2013).

Yet, the IDE used for implementing, testing and

debugging a software system should not be deter-

mined by the DSLs language workbench. Although

most IDEs have support for the most popular pro-

gramming languages, they usually have very mature

support for a few speciﬁc programming languages.

For example, the Eclipse IDE offers sophisticated ed-

itor support for Java (Arnold et al., 2005) and C++

(Stroustrup, 2000), while Visual Studio Code (Mi-

crosoft, 2018) has a focus on JavaScript (Mikkonen

and Taivalsaari, 2007) and TypeScript (Bierman et al.,

2014) editors. Further, the IDE integrated editor as

well as testing and debugging support is differently

mature. While Eclipse and IntelliJ both provide IDE

features for Android development, IntelliJ offers a

more stable and feature rich editor. Therefore, pre-

deﬁning the IDE by the DSLs language workbench

can be disadvantageous for toolsmiths and tool users.

The latter are either forced to use two separate

but specialized IDEs or one consolidated but not ideal

IDE. Both approaches decrease developer productiv-

Bünder, H.

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages.

DOI: 10.5220/0007556301290140

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 129-140

ISBN: 978-989-758-358-2

129

ity. The ﬁrst by requiring a constant tool switch that

causes slower and more error-prone responses (Mon-

sell, 2003). The second, by not using the best tool

available for tasks like testing and debugging.

For toolsmiths there is often no economically rea-

sonable alternative to focusing on one IDE, because

supporting multiple editors causes tremendous effort.

Editor integration as well as computation of features,

such as code completion or validations, have to be im-

plemented for each IDE. Therefore, toolsmiths often

decide to provide support for only one editor or IDE.

While the use of IDEs as primary environment

comforts people with IT background, the large num-

ber of buttons, menus, and views often confuses non-

technical users. Therefore, implementing support for

only one editor not only causes the problems men-

tioned above but also excludes a group of potential

users. All available language workbenches are fo-

cused on creating mature tooling for arbitrary DSLs,

however, only for one speciﬁc IDE to integrate with.

The Language Server Protocol (LSP) which was

intentionally built to separate the language smarts of

general purpose programming languages from the ed-

itor integration, was recently adopted by the Xtext

language workbench. Thereby, textual DSLs based on

Xtext should be able to utilize all features of the Lan-

guage Server Protocol. A case study was conducted

to build an Entity-DSL that was integrated into two

different IDEs. Language smarts and the two editor

integrations are based on the Language Server Pro-

tocol. In addition, the case study includes a SWOT

analysis carried out to identify the impact of the LSP

on textual Domain-Speciﬁc Languages in general.

After analyzing related work Section 3 elaborates

on architecture, features and limitations of the Lan-

guage Server Protocol. In section 4 the Entity-DSL

implemented in the context of the case study is de-

scribed. Next, we outline the results of the SWOT

analysis conducted to identify the potential impact of

the LSP on textual domain speciﬁc languages. Fi-

nally, the results of the case study are discussed.

2 RELATED WORK

According to Tomassetti (Tomassetti, 2017a), an ex-

ternal Domain-Speciﬁc Language in contrast to an in-

ternal Domain-Speciﬁc Language has tool support. In

order to build such tool support, there are different

language workbenches available, that ease the cre-

ation of abstract syntax, parser, editor, and generators

(Fowler, 2005). Language workbenches like Monti-

Core or MPS generatively create DSL tools to be in-

tegrated into Eclipse or IntelliJ, respectively. Xtext

and Spoofax are two language workbenches that sup-

port Eclipse as well as IntelliJ integration. However,

since both are primarily focused on Eclipse, the Intel-

liJ support is rather experimental for Spoofax (Kats

and Visser, 2010) and lacking contributors for Xtext

(Xtext, 2018).

In addition to language workbenches targeting

speciﬁc IDEs, there is a variety of language work-

benches that produce web-based editors. Popoola et.

al. summarize such approaches as Modeling as a

Service (MaaS) (Popoola et al., 2017). They iden-

tify two categories of MaaS, namely client-server and

cloud-based. AToMPM, ModelBus, and DSLForge

represent modeling platforms from the ﬁrst category,

that in some way require an installation on a lo-

cal server. In contrast, GenMyModel, WebGME,

CLOOCA, MORSE, and MDEForge require no in-

stallation and are accessible completely over the web.

While all approaches enable browser-based editing of

models, none of the approaches supports native inte-

gration into IDEs, such as Eclipse or IntelliJ.

The Language Server Protocol as introduced by

Microsoft, RedHat, and Codeenvy in 2016 ﬁlls this

gap (Microsoft, 2018). It aims at separating the com-

putation of language editor features, such as code

completion and validations, from the actual editor in-

tegration. Originally, invented to integrate different

programming languages into different IDEs and ed-

itors, there is also an implementation for the Xtext

language workbench. According to the list of Lan-

guage Server implementations (Microsoft, 2018a),

Xtext is by now the only language workbench sup-

porting the LSP. While Rodriguez-Echeverria et. al.

(Rodriguez-Echeverria et al., 2018) have already pro-

posed a Language Server Protocol infrastructure for

graphical modeling, little attention has been paid to

the impact of the LSP on textual modeling.

3 LANGUAGE SERVER

PROTOCOL

The number of programming languages is steadily in-

creasing over the last decades. While new program-

ming languages, such as Go (Go, 2018) or Swift (Ap-

ple, 2018), are gaining market shares (TIOBE, 2018),

old programming languages, such as Cobol or For-

tran, are staying as the basis of many legacy sys-

tems (Reuters, 2018). In addition, the number of in-

tegrated development environments is increasing as

well. Since most IDEs support a variety of program-

ming languages, IDE developers face the problem of

keeping up with ongoing programming language evo-

lution. At the same time language providers are inter-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

130

Figure 1: Interprocess communication during routine editing session (Microsoft, 2018).

ested in providing as many IDE integrations as possi-

ble to serve a broad audience. Consequently, integrat-

ing every language in every IDE leads to a m-times-n

complexity.

The Language Server Protocol addresses this issue

by separating the language-speciﬁc smarts from the

integration into an editor. Features such as code com-

pletion, goto deﬁnition and refactoring are computed

in a language-speciﬁc server process. The Language

Server implementation itself can be implemented in

any programming language. Yet, there are Soft-

ware Development Kits (SDKs) encapsulating low-

level communication as speciﬁed by the LSP for pro-

gramming languages such as JavaScript or Java (Mi-

crosoft, 2018a). The server process communicates

over a standardized protocol with a client process that

integrates the language smarts into an IDE. The es-

sential parts of the Language Server Protocol are the

features speciﬁed by the protocol that client or server

implement. By decoupling the language implementa-

tion from the editor integration the complexity for in-

tegrating all programming languages into all existing

IDEs goes down to m-plus-n (Sourcegraph, 2018).

Since being introduced in 2016 more than 50 lan-

guage servers for languages such as Java, TypeScript,

and Cobol have been implemented. Moreover, there

are editor integrations for more than 10 IDEs in-

cluding widely adopted IntelliJ, Eclipse, and VSCode

(Sourcegraph, 2018). Since textual DSLs are pro-

gramming languages for a narrow set of problems

olter, 2013), the LSP can be utilized to decouple

language smarts from the editor for any DSL. How-

ever, by now Xtext is the only language workbench

that includes LSP support.

3.1 Architecture of the Language

Server Protocol

The Language Server Protocol is implemented by a

server and a client process. The interprocess com-

munication is deﬁned by a protocol specifying the

available capabilities (Microsoft, 2018). The proto-

col is based on the stateless and lightweight remote-

procedure call protocol JSON-RPC. The transport ag-

nostic protocol uses JSON as data format (JSON-RPC

Working Group, 2018). Although JSON-RPC is de-

signed for remote procedure calls over a network,

server and client process not necessarily need to be

on different physical machines. In fact, most Lan-

guage Server implementations run two separate pro-

cesses, but on the same physical machine (Tomassetti,

2017b).

Figure 1 shows a routine editing session. On the

left-hand side, the Development Tool is shown and on

the right-hand side, the Language Server implemen-

tation is presented. The communication that is repre-

sented by the arrows between the Development Tool

and Language Server utilizes the Language Server

Protocol for remote procedure calls. The editing ses-

sion starts in the Development Tool where the user

opens a document. The Development Tool notiﬁes the

Language Server that a document has been opened.

Next, the user edits the document which is again for-

warded to the server (textDocument/didChange). The

server now analyses the changes within the document

and sends detected errors and warnings back to the

Development Tool.

The following use case starts with the user execut-

ing a “Goto deﬁnition”, e.g. to jump to the declaration

of a variable. The Development Tool sends a request

to the Language Server giving the current cursor po-

sition within the document. Next, the position of the

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages

131

variable declaration is computed and returned to the

Development Tool. The Development Tool integra-

tion is now in charge of opening the correct document

and placing the cursor in the returned position. Fi-

nally, the user closes the document and the server is

notiﬁed again. From here on the truth about the con-

tent of the ﬁles is persisted on the ﬁle system (Bumer

et al., 2017).

The sample communication shows that the proto-

col is based on documents and positions within them.

Thereby, the protocol itself is independent of a spe-

ciﬁc programming language. However, it is currently

limited to text ﬁles. Consequently, binary ﬁle for-

mats are not supported. In addition to programming

languages, there is a variety of Language Server im-

plementations for conﬁguration languages, such as

YAML (YAML, 2018) or XML (Microsoft, 2018a).

Xtext is currently the only textual DSL workbench

that supports the LSP. Therefore, languages imple-

mented with Xtext can utilize the features of the Lan-

guage Server Protocol .

3.2 Language Server Protocol Features

The Language Server Protocol currently in version

3.6 separates messages into header and content part.

The ﬁrst speciﬁes content length and content type

and is required for every message. The second con-

tains the actual content of the message. Within the

content of a message JSON-RPC 2.0 is used to de-

scribe requests, responses, and notiﬁcations. While

request messages always require a response message,

notiﬁcations do not (Microsoft, 2018b). In total the

current LSP version deﬁnes more than 40 message

types organized in ﬁve operational categories, namely

general, window, client, workspace, and document

(Rodriguez-Echeverria et al., 2018). The data for-

mat of the messages is JSON (JSON-RPC Working

Group, 2018).

Since not every language as well as not ev-

ery editor supports all features from the protocol,

both use Capabilities to announce the fea-

tures they support. During the initial request

to the Language Server, the client provides its

supported Capabilities. With the LSP 3.6 the

Capabilities consist of ClientCapabilities,

TextdocumentClientCapabilities, and

WorkspaceClientCapabilities. The latter de-

scribe features the editor supports on the workspace

level, such as operations to create, delete or re-

name resources. TextdocumentCapabilities

contain the support for text hovers or type

deﬁnitions. The ClientCapabilities

group TextdocumentCapabilities and

WorkspaceClientCapabilities. Additionally,

they add ExperimentalCapabilities which are

capabilities currently under development by a speciﬁc

language or editor implementation.

In general, the Language Server ignores unknown

Capabilities and interprets missing Capabilities

as not being supported by the client. The Language

Server itself answers to an initialization process by

returning the Capabilities offered to provide lan-

guage smarts (Microsoft, 2018c).

The focus of the protocol is on the language fea-

tures implemented by the Language Server. While

there is a large and steadily increasing num-

ber of language features included in the protocol,

the community-driven LSP-site (Sourcegraph, 2018)

cites “Code Completion”, “Hover”, “Goto Deﬁni-

tions”, “Workspace Symbols”, “Find References”,

and “Diagnostics” as key features of a Language

Server implementation.

Code Completion. The code completion request

is sent to the server including the current document

and the cursor position within the document. The

Language Server computes completion items at the

given position and returns them to the Development

Tool. The client process is in charge of forward-

ing the completion proposals to the respective context

menu within the editor from which the user can select

the appropriate element. In case the computation of

completions is expensive, the completion can be rep-

resented by a handler. As soon as the user selects

the completion from the context menu, the handler

executes another request to the Language Server to

compute the full completion text. From the Language

Server implementations listed at (Sourcegraph, 2018)

nearly 90 percent support the code completion fea-

ture.

Figure 2: Theia Editor Integration - Hover Feature.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

132

Hover. By sending a hover request to the server

additional information to be shown in a hover menu

is computed. Figure 2 illustrates the default hover

menu integrated into the Theia IDE. The hover menu

opened in line 16 contains the documentation of the

Address entity that is referenced as type of the at-

tribute address within the Employee entity. Addi-

tionally, text formatting including line-breaks, lists or

indentations is supported by the hover menu feature.

Around 88 percent of the listed Language Server im-

plementations provide a hover capability.

Goto Deﬁnitions. The Goto Deﬁnition request re-

turns the position within a document where the given

symbol is deﬁned. Since LSP version 3.6.0 “Goto

Type Request” and “Goto Implementation Request”

have been added. While the ﬁrst returns the position

where a given type is speciﬁed, the second returns the

implementation location of a given symbol. The Goto

Deﬁnition feature is supported by 83 percent of the

listed Language Server implementations.

Workspace Symbols. The Workspace Symbol re-

quest takes a query string and reveals all matching

symbols within the workspace. Out of the 58 Lan-

guage Server implementations only 35 implement the

workspace symbol request.

Find-References. Based on the current cursor

position within the document, the ﬁnd-references re-

quest returns a project-wide list of locations. Each

of the locations references the symbol at the current

cursor position. The ﬁnd-references request is imple-

mented by nearly 63 percent of the listed Language

Server implementations.

Diagnostics. The Language Server is responsible

for handling diagnostics. Depending on the kind of

project, diagnostics might be handled per ﬁle or for a

complete project. After the diagnostics, such as errors

and warnings, are computed, the server sends them to

the client. The client always replaces all diagnostics

so that no merge on the client side is required. There-

fore, a diagnostics notiﬁcation with an empty list of

diagnostics is interpreted as no errors or warnings oc-

curred. 78 percent of the Language Server implemen-

tations support the diagnostics feature.

Besides the capabilities mentioned above, there

are more advanced features such as code lens or sig-

nature help included in the Language Server Protocol

(Microsoft, 2018b).

3.3 Limitations

The LSP provides a protocol for inter-process com-

munication between a language-speciﬁc server and an

editor speciﬁc client process. While the lightweight

protocol enables the separation of concerns and re-

duces the integration complexity, it also has some in-

herent limitations.

First, the LSP currently assumes that client and

server process have access to a shared ﬁle system.

Consequently, client and server run on the same phys-

ical machine. Not only is the naming of server and

client misleading, sharing a physical machine hinders

scalability and fail-over mechanisms of the stateless

server process. However, there are extensions to the

Language Server Protocol, such as the Files Exten-

sion that enables the Language Server to work with-

out a shared ﬁle system (Sourcegraph, 2016).

Second, the Language Server currently assumes

one Language Server serves exactly one Development

Tool (Microsoft, 2018b). In combination with run-

ning on a single physical machine, editing many dif-

ferent types of ﬁles at the same time, e.g. a Xtext

DSL, a Java program, and a XML conﬁguration ﬁle

leads to three language servers running on a single

computer. Further, every Language Server is built as

a stand-alone application that does not communicate

with other language servers. In contrast to native in-

tegrations, common tasks, such as parsing XML ﬁles,

have to be implemented within each Language Server.

Thirdly, the Language Server Protocol currently

focuses on editing the text documents of a program-

ming, conﬁguration or Domain-Speciﬁc Language.

Yet, there is no inherent support for running, testing

or debugging the speciﬁed programs. Hence, the ed-

itor might beneﬁt from the decoupling achieved by

applying the Language Server Protocol , but features

mentioned above are still IDE-speciﬁc implementa-

tions. However, for the purpose of debugging the

Debugging Server Protocol has been announced, that

provides debugging support to be integrated into dif-

ferent editors(Kichwas Coders, 2018). Thereby, en-

abling IDE independent debugging support through a

standardized protocol that is similar to the LSP.

Fourthly, the Language Server Protocol has some

shortcomings compared to native IDE integrations.

Comparing the features available when editing a DSL

natively integrated into the Eclipse IDE, there is so-

phisticated support for type hierarchies or project- and

ﬁle-creation wizard (Vogel and Milinkovich, 2015).

The gain of easy integration into multiple editors

comes at the cost of losing some advanced features

available in native integrations.

4 BUILDING AN ENTITY-DSL

WITH THE LSP

In order to exemplify the capabilities of the Language

Server Protocol a case study was conducted. An

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages

133

Entity-DSL leveraging the LSP was implemented to

investigate the necessary tasks to integrate with differ-

ent IDEs. The Entity-DSL Language Server supports

the key language features as stated by the community-

driven LSP-site (Sourcegraph, 2018). To exemplify

the integration in different editors, a Language Server

client extension for Theia and Eclipse was imple-

mented.

Figure 3 shows the editor within the Theia IDE,

and Figure 4 displays the same language integrated

into the Eclipse IDE. In both cases the same ”Com-

pany.dsl” ﬁle is edited. While the completion pro-

posal shown by both ﬁgures is computed by the Lan-

guage Server process, the keyword highlighting was

implemented speciﬁcally for each editor integration.

Figure 3: Theia Editor Integration.

Figure 4: Eclipse Editor Integration.

The following subsections elaborate on imple-

menting the Language Server parts to compute Entity-

DSL smarts, as well as the client integration for Theia

and Eclipse.

4.1 The Entity-DSL Language Server

Implementation

Listing 1 shows an Xtext grammar in an EBNF-

like format deﬁning the Entity-DSL including enti-

ties with properties and operations. The Entity-DSL

is a simpliﬁcation of a typical textual DSL used in

real world projects to specify data models and oper-

ations. The root grammar element is the Model that

can hold an arbitrary number of Entity objects. Each

Entity can extend another Entity and contains an

unordered list of Property and Operation objects.

While a Property has a name and a type attribute,

an Operation consists of a name, an optional list of

Parameters and a returntype. Types can either

reference an Entity or a Primitive type, such as

string, number, or boolean.

Mo de l :

en tit ie s += Entit y *;

En tity :

' e nt ity' nam e = ID (' e xt end s' s up e rT yp e = Ent it y ) ?

' {'

fe atu re s += Fea tu re *

' }' ;

Fe atu re :

Pr ope rt y | Op era ti on ;

Pr ope rt y :

na me = I D ' :' t ype = Ty pe ;

Op e ra tio n :

' op' nam e = ID

' (' ( p ar am s += p ar a me te r (' ,' pa ra ms += p ar ame te r ) *)?' )'

(' :' r e tu rnt yp e = Ty pe ) ? ;

Pa r am ete r :

na me = I D type = [ Type ];

Ty pe :

{ P ri m it iv e } name = P rim it ive | E nti tyR efe re n ce ;

Ent ity Ref er e nc e :

{ E nti tyR efe ren ce } ent ity Def ini tio n =[ Entity ];

Pr i mi tiv e :

' n um ber' | ' strin g' | ' bo ol ea n';

Listing 1: Grammar Rules for the Entity-DSL.

Based on the EBNF-like grammar, the Xtext language

workbench creates the required source code to parse

and link text ﬁles according to the speciﬁed gram-

mar. The generated language server classes use the

Language Server Protocol for Java (LSP4J) frame-

work (Eclipse, 2018c) to create messages in accor-

dance with the Language Server Protocol. LSP4J

encapsulates the low-level JSON communication and

deﬁnes a Java API that offers all features of the Lan-

guage Server Protocol (Miro Spnemann, 2018). Since

the Xtext language workbench generates the required

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

134

classes for the key language features, the default Lan-

guage Server implementation needs no further cus-

tomization. Yet, it supports the features explained in

Section 3.2.

4.2 Building a Client-extension for the

Theia Editor

Theia is a cloud and desktop IDE that integrates many

different languages based on the Language Server

Protocol. It separates the graphical user interface

from the backend processes. While the frontend ei-

ther runs in a browser or as a desktop application, the

backend process is executed locally or remotely, e.g.

on a cloud-based infrastructure (Theia.org, 2018).

In order to introduce editor support for the Entity-

DSL in Theia a backend extension is required that

conﬁgures the Language Server. Since Theia uses de-

pendency injection (Fowler, 2004) the required back-

end extension can be injected as shown by List-

ing 2. The EntityDslContribution extends the

BaseLanguageServerContribution from Theia’s

LSP-speciﬁc framework classes. As shown by List-

ing 2, the Language Server can either run as local

sub-process or remotely using web-socket communi-

cation (Fette and Melnikov, 2011). The details for

establishing the connections are encapsulated in Lan-

guage Server client speciﬁc libraries.

@in je cta ble ()

cl as s E n ti t yD s lCo ntr ibu t io n ex ten ds

Bas e La n gua geS e rv e rCo n tr i but ion {

st ar t ( cli ent Con nec tio n : I Co n ne cti on ) : v oi d {

let soc ke tPo rt = g et Po rt () ;

if ( soc ke t Po rt ) {

th is . c onn ect T oR e mo t eS e rve r ( cli en tCo nn ec tio n ,

soc ke tPo rt )

} e ls e {

th is . c onn ect T oL o ca l Se r ve r ( c l ie n tC o nn e ct ion )

}

Listing 2: Registering a Language Server Extension in

Theia.

By registering a backend extension, the Theia editor

is ready to interpret the Entity DSL. Yet, the high-

lighting of keywords and comments is handled by

Theia’s frontend process. Therefore, an additional

frontend extension is added to support syntax high-

lighting. In addition, the frontend extension spec-

iﬁes the ﬁle sufﬁx for which the Language Server

should be used. Listing 3 shows the part of the fron-

tend extension where the “globPattern” method of

the EntityDslClientContribution is overwritten

to specify the ﬁle extension the Language Server is

bound to.

@in je cta ble ()

ex port cl as s E n ti t yDs l Cl i en t Con t ri b ut i on

ex ten ds B ase Lan g ua g eCl i en t Con tri b ut i on

{

pr o te cte d ge t glo bPa tt e rn s () {

re tu rn [' ** /* . d sl' ];

}

Listing 3: Binding the “.dsl” ﬁle extension to the Language

Server.

Based on the backend and frontend extension the

Theia IDE can interpret Entity-DSL models as shown

by Figure 3.

4.3 Building a Client-extension for the

Eclipse IDE

The Xtext language workbench makes heavy use of

the Eclipse IDE for providing sophisticated, natively

integrated editor support for its DSLs. However, in-

stead of utilizing this native integration it will be

shown how the Entity-DSL can be integrated into the

Eclipse IDE using the Language Server for Eclipse

(LSP4E) framework (Eclipse, 2018b).

The integrated development environment Eclipse

has an extensible plugin architecture (Vogel and

Beaton, 2013). The IDE capabilities are ex-

tended by providing Eclipse plugins for speciﬁc pur-

poses. Consequently, to enable LSP-based sup-

port for the Entity-DSL an Eclipse-Plugin is pro-

vided. The Entity-DSL plugin extends the LSP4E

Plugin using well-deﬁned extension points (Gamma

and Beck, 2004). The LSP4E plugin offers the

DSL-agnostic ”org.eclipse.lsp4e.languageServer” ex-

tension point. As shown by Listing 4, the

Entity-DSL plugins provides an extension in the

class EntityDslLanguageServerClass. While the

LSP4E plugin ensures that the Entity-DSL extension

is called at the correct time, the Entity-DSL plugin

handles the language-speciﬁc implementation.

< ext en sio n

po in t = " or g . e cl ipse . l sp 4e . l ang ua g eS e rv e r " >

< se rver

id = " or g . e cl ipse . l sp 4e . l an gua ge s . d sl "

cl as s = " or g . e cl ipse . l sp 4e . l an gua ge s . d sl .

Ent ity D sl L an g uag eSe r ve r "

la be l = " En tity - DS L La n gu ag e S er ver " >

</ serve r > </ e xt ens io n >

Listing 4: Registering a Language Server Extension in

Eclipse.

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages

135

Listing 5 shows the implementa-

tion of the EntityDslLanguageServer

that extends the LSP4E framework class

ProcessStreamConnectionProvider. As

soon as an editor for the “.dsl” ﬁle is opened

a Language Server is started as sub-process.

The createLauncherCommand method returns a

command to start a Language Server process as

sub-process. Afterwards, the working directory for

the Language Server is computed.

pu bl ic cl as s E n ti t yD s lLa ngu a ge S er v er ext en ds

Pro c es s Str e am C onn ect i on P rov i de r {

pu bl ic M yD s lL a ng u age Ser ver () {

set Co mma nds ( c r ea t eL a un c her Com man d () ) ;

set Wor kin g Di r ec t or y ( w ork ing Dir ect ory () );

}

Listing 5: Entity-DSL Extension.

In addition, there is a

ProcessOverSocketStreamConnectionProvider

class in the LSP4E plugin that can be extended in case

the connection to the server should be handled by

web-socket communication. Thereby, the connection

could be established to an already running Language

Server.

pu bl ic cl as s E n ti t yPr e se n ta t ion R ec o nci ler e xt en ds

Pre sen t at i on R eco nci l er {

pr iva te Set < Strin g > k ey wo rds = new H as hSet < >(

Ar ra ys . a sL is t ( n ew S tr in g [ ] {

" e nt it y " , " op " , " s tring " , " number " ," boo le an " ,"op "

}) ) ;

}

Listing 6: Keyword Deﬁnition for Syntax Highlighting.

To ensure correct highlighting for the Eclipse IDE

editor the PresentationReconciler needs to be

extended. The EntityPresentationReconciler

speciﬁes syntax highlighting for keywords and com-

ments of the Entity-DSL. Listing 6 shows the deﬁ-

nition of all keywords of the Entity-DSL to be high-

lighted.

Introducing Language-Server-based support for

the Entity-DSL in Theia and Eclipse is similar on a

conceptual level. Both integrations require a speciﬁc

implementation to support syntax highlighting. Fur-

ther, both extensions have to take care of starting the

Language Server. Yet, the two integrations have a lot

of differences in the details, such as architecture, pro-

gramming language, and API.

4.4 Results for Implementing the

Entity-DSL

In order to indicate the effort required for creating

a DSL with LSP support, we measured the time re-

quired to implement and integrate the Entity-DSL.

Building and integrating the Entity-DSL into Theia

and Eclipse can be divided into three major tasks.

First, the Language Server Implementation was done

using the Xtext language workbench. Since the Lan-

guage Server was generated based on the Xtext gram-

mar ﬁle, the ﬁrst runnable version was done in about

two hours.

Table 1: Effort for implementing the Entity-DSL.

Time

Task (in minutes)

Language Server Implementation 127

Theia Editor Integration 414

Eclipse Editor Integration 317

Second, the Theia integration was implemented

requiring more manual implementation. Since fron-

tend and backend extension had to be implemented,

the overall effort for a ﬁrst running version of the

editor integration took about 7 hours. Thirdly, the

Eclipse integration was implemented in a little bit

more than 5 hours, due to the experience gained when

writing the Theia extension.

For all three parts the implementation was only

possible in such a short amount of time, because there

are SDKs available that encapsulate low-level com-

munication including marshaling and demarshaling.

5 IMPACT ON TEXTUAL

DOMAIN-SPECIFIC

LANGUAGES

In addition to implementing the Entity-DSL a SWOT

analysis was carried out as part of the case study to get

a holistic view on the impact of the Language Server

Protocol on textual Domain-Speciﬁc Languages. The

analysis of strengths, weaknesses, opportunities, and

threats is used in a business context regularly for

strategic planning (Helms and Nixon, 2010). Af-

ter analyzing the internal strengths and weaknesses

of the Language Server Protocol the external oppor-

tunities and threats are examined. The analysis re-

veals the strengths that beneﬁt the spread of the Lan-

guage Server Protocol and thereby the impact on tex-

tual DSLs. Additionally, it identiﬁes weaknesses and

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

136

threats that need to be removed or mitigated, respec-

tively.

5.1 SWOT Analysis

Strengths. The Language Server Protocol provides

a standardized protocol for inter-process communi-

cation between a Development Tool and a Language

Server. Thereby, the language smarts required to

compute editing operations for source code, conﬁgu-

ration ﬁles, and textual Domain-Speciﬁc Languages

only have to be implemented once. Consequently,

support for new programming languages or textual

DSLs can be introduced into different IDEs and ed-

itors quickly.

Since the protocol is based on the JSON-RPC

standard, the data is represented by the lightweight

JavaScript Object Notation format. Thereby, the pay-

load between server and client is reduced to a min-

imum. Although LSP is currently used mainly with

two processes running on the same physical machine,

the efﬁcient data exchange format forms an important

prerequisite for communicating over a network. Ad-

ditionally, the delays due to data exchange are mini-

mized leading to better user experience when editing

text documents.

While the Language Server Protocol speciﬁes a

set of language capabilities that a client or a server

can implement, it also allows for custom capabilities.

Using custom capabilities enables toolsmiths to im-

plement language or editor speciﬁc features. Yet, the

editor integration has to be built manually. Thereby,

custom protocol features might not be supported by

all editors or languages. Nevertheless, language ex-

tensions that appear to be reasonable for the majority

of programming languages may be added to the pro-

tocol.

Especially for DSLs, the tool users are not al-

ways developers. Instead, team members with a

business background want to engage in creating

domain-speciﬁc models, e.g., to specify insurance

contracts or banking products (V

olter, 2013). The

ability to integrate LSP-based editors seamlessly into

browser-based applications lowers the barrier for non-

technical experts. By accessing and editing the DSL

through a browser-based interface, installation and

distribution efforts are minimized. At the same time,

web editors may not be as confusing as integrated de-

velopment environments from a non-technical user’s

perspective.

Weaknesses. The LSP is implemented under the

assumption that there is one Language Server per

tool. While this is appropriate for a single language

approach it has some shortcomings regarding multi-

language approaches and cross-language referencing.

Since a Language Server is started for every kind

of language on the same physical machine (s. Sec-

tion 3.3) as the editor, the choice of a programming

language to implement the Language Server becomes

signiﬁcant. If the Language Server is implemented in

Java, then a Java Virtual Machine (JVM) is started for

every language. Assuming an average memory con-

sumption of 1 GB per JVM and editing a DSL, a Java

program, and a XML ﬁle at a time, 3 GB memory

is allocated. Depending on the size and complexity

of the projects and the computers used, this can re-

sult in poor user experience. However, since the pro-

gramming language used to implement the Language

Server is independent of the programming language

of the Development Tool, toolsmith are free to use

languages with a smaller memory footprint, such as

JavaScript.

Additionally, language servers are currently im-

plemented to be independent. While this enables

separated life-cycles of servers, it also forces each

language implementation to re-implement potentially

reusable concepts of other languages. If a DSL, for

example, references Java classes on the classpath, it

has to implement the access to the classpath and the

classes on it. In contrast, a native IDE integration,

e.g., in Eclipse, allows the DSL implementation to re-

use functionality from other plugins, such as the Java

Development Tools (JDT) plugin (Eclipse, 2018a).

As Section 4 has shown, each editor integration

requires its own speciﬁc extension. Therefore, the

language provider still needs to specify which edi-

tors to support. Consequently, the knowledge about

how to provide extensions for Eclipse, Theia, etc. is

still required. Further, since every integration is a lit-

tle bit different, they all have to be tested to guar-

antee the same user experience, e.g., keywords be-

ing highlighted or code completion proposals being

sorted correctly.

The Language Server is currently limited to sup-

port programming languages and thereby textual

DSLs that are programming languages for a speciﬁc

problem domain. However, frameworks like Intel-

liJ’s Meta Programming System (MPS) offer a pow-

erful language workbench for implementing editors

for projectional editing of DSLs (Fowler, 2005). In

addition, graphical notations are often beneﬁcial to

present a quick overview of complex relations. Both

are not supported by the Language Server Proto-

col. Thereby, excluding a large number of powerful

Domain-Speciﬁc Language implementations.

Opportunities. Domain-speciﬁc languages are

widely adopted through research and industry. Ma-

ture language workbenches such as Xtext enable fast

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages

137

creation of Domain-Speciﬁc Languages. However,

the DSL usage is often bound to one speciﬁc IDE.

At the same time, software developers demand more

freedom when choosing their IDE. In multi-layered

software architectures a variety of programming lan-

guages are utilized that are edited best with different

IDEs. For example, the Javascript code for the fron-

tend might be edited best with the Theia IDE, while

the Java backend code is edited best with the Eclipse

IDE. Yet, a holistic DSL aims to describe parts of both

architectural layers, e.g., to provide consistency be-

tween backend and frontend.

The Language Server Protocol solves the prob-

lem of writing speciﬁc extensions or plugins for ev-

ery potential editor and thereby enables a fast spread

of the DSL. Given an industry that constantly adds

new DSLs and editors, the Language Server Protocol

creates the opportunity to provide a Domain-Speciﬁc

Language in an environment that the user is most fa-

miliar with.

By introducing abstract Domain-Speciﬁc Lan-

guages, non-technical team members are enabled to

engage in the process of describing a software system

on a technology agnostic level. Yet, DSLs integrated

into heavyweight IDEs cause a lot of distraction. The

graphical user interface is often perceived by non-

technical users to be overloaded with menus, buttons,

and views. Further, additional software has to be in-

stalled and maintained to use the DSL. Besides being

integrated into client-based IDEs a Language Server

client extension can also be built for web-based ed-

itors such as Monaco (Microsoft, 2018). By edit-

ing DSLs through a browser-based editor that does

not require any additional installations or new tools

to learn, the entry barrier for non-technical users is

lowered. Consequently, each team member can work

on a shared ubiquitous domain model from his or her

preferred editor environment. Further, the develop-

ment activities of non-technical and technical team

members are closely integrated. They not only use

the same Domain-Speciﬁc Language to specify a soft-

ware system, but they are also allowed to use the ed-

itor of their choice. Thereby, the domain-model can

be created through two differently skilled stakehold-

ers from their favorite editing environment.

Threats. While there is currently no comparable

alternative to decoupling the language smarts from

the editor integration, the threats do not lie in other

technologies but rather in semantically rich program-

ming languages. Further, multi-notational DSLs that

integrate forms, tables, graphs and text pose a real

threat.

New programming languages, such as Scala, D, or

Go are more expressive than programming languages

such as Java or C. Additionally, frameworks provide

high-level APIs that ease the development of complex

processes. More expressive languages and framework

diminish the need for low-level textual DSLs, e.g. to

describe entities or service interfaces, since the ad-

vantage gained from transformation and generation

is small. Consequently, Domain-Speciﬁc Languages

must provide higher levels of abstraction to create

beneﬁts.

In addition, multi-notation support, e.g. for ta-

bles, charts or formulas becomes more important. Al-

though, projectional DSLs built with language work-

benches such as MPS are bound to a speciﬁc IDE,

they are a valuable alternative to parser-based DSLs.

If the Language Server Protocol is not enhanced to

also handle projectional editor based languages, a

growing market share of DSLs is out of reach.

While current projectional DSL workbenches do

not offer web editor support, there are browser-based

multi-notation language workbenches. WebGME

(Mar

oti et al., 2014), for example, enables the cre-

ation of Domain-Speciﬁc Languages through a web-

client. Especially, for high-level, graphical notations

WebGME is an alternative to parser-based languages

built with the LSP.

6 DISCUSSION

The case study has shown that Entity-DSL language

and editor can be separated easily by using the Lan-

guage Server Protocol. At the same time, the inte-

gration into multiple different Development Tools is

possible. Section 4.4 indicates that the creation of the

Language Server itself is relatively fast, due to the

high ratio of generated source code. Although each

editor integration has its own programming language

and API, basic concepts are the same. Therefore, the

implementation of the second editor integration into

Eclipse was slightly faster than the Theia integration.

Further, the SWOT analysis revealed that the LSP

is concerned with the right problems in an industry

where the number of DSLs and Development Tools is

increasing steadily. However, by focusing on textual

DSLs valid and powerful alternatives such as graph-

ical or projectional DSLs are not covered. Neverthe-

less, since the Xtext language workbench supports the

LSP, the number of DSLs utilizing the protocol will

increase in the future.

The Language Server Protocol has already had

an impact on Domain-Speciﬁc Languages. First, the

widely used Xtext language workbench has already

adopted the LSP. Further, the language workbench

automatically creates support for the main language

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

138

features as listed by the community-driven LSP-site

(Sourcegraph, 2018). Thereby, the Language Server

Protocol has deﬁned the capabilities a language must

have to comply with the minimal editor-support “stan-

dard”. Second, the LSP contains features that are cur-

rently not supported by the Eclipse native integration,

e.g., the signature help feature. Since this capability

can be included in DSLs built with the Xtext work-

bench, the LSP has introduced new features. Thirdly,

DSLs built with the Language Server Protocol will

in the future be edited by a broader group of poten-

tial users, such as developers, business analysts, and

testers due to the relatively easy integration into mul-

tiple editors. Thereby, the LSP will foster the collab-

oration in cross-functional teams.

By enabling multi-editor integration, LSP-based

textual DSLs become a valid alternative to web-based

approaches. Domain-Speciﬁc Languages backed by

the Language Server protocol have the advantage

that they can be integrated into IDEs as well as into

browsers. Thereby, enabling all team members to

contribute to shared domain models from the editor

that best suits their needs. The technological lim-

itations, such as a shared physical machine and no

direct communication between language servers, are

outweighed by the advantages of decoupling language

smarts and editor integration.

7 CONCLUSIONS

The paper has shown how the LSP can be leveraged

to integrate one DSL in a variety of editors. Although

the integration into every additional editor came at the

cost of providing a new extension for the speciﬁc IDE,

the overall integration costs are far below implement-

ing an IDE-speciﬁc integration. Further, the SWOT

analysis has shown that the LSP has the potential to

provide textual DSLs to many different user groups

and thereby foster collaboration. However, focusing

solely on textual DSLs is also the largest disadvan-

tage, since it leaves out projectional and graphical ap-

proaches.

The impact of the Language Server Protocol on

textual Domain-speciﬁc languages is threefold. First,

the six main features as listed by Section 3.2 can be

seen as the minimum feature set that should be sup-

ported by any DSL editor. Second, the effort required

to support different IDEs and editors for any given

textual DSL is signiﬁcantly reduced by the Language

Server Protocol. Thirdly, by liberating the language

smarts from the editor integration users can specify

domain models without installing heavyweight IDE,

e.g. through a browser-based editor.

The fact that each Language Server is built to

serve one Development Tool and has no inherent con-

nection to other Language Servers introduces some

disadvantages. Additional research is required to an-

alyze whether the separation leads to consequent re-

implementation of basic features. Further, having one

Language Server per Development Tool on the same

physical machine should be investigated in industry

size projects to estimate the effect on the overall per-

formance.

The contribution of this paper based on the con-

ducted case study is two-fold: First, we showed how

to apply the LSP to implement an Entity-DSL and in-

tegrate its editor into the Theia and Eclipse IDE. Sec-

ond, a SWOT analysis identiﬁed internal strength and

weaknesses of the LSP and evaluated them against

current external conditions in form of opportunities

and threats. Based on the ﬁrst-hand experiences from

utilizing the LSP and the results of the SWOT analysis

the potential impact on textual DSLs was analyzed.

REFERENCES

Apple (2018). About swift.

Arnold, K., Gosling, J., and Holmes, D. (2005). The

Java programming language. Addison Wesley Pro-

fessional.

Bierman, G., Abadi, M., and Torgersen, M. (2014). Un-

derstanding typescript. In European Conference

on Object-Oriented Programming, pages 257–281.

Springer.

Bumer, D., Gamma, E., and McBrean, S. (2017). What is

the language server protocol (lsp).

Campagne, F. (March 2016). The MPS language work-

bench: Meta Programming System. campagnelab,

[New York, NY], third edition, version 1.5.1 edition.

Eclipse (2018a). Eclipse java development tools (jdt).

Eclipse (2018b). Eclipse lsp4e.

Eclipse (2018c). Eclipse lsp4j.

Fette, I. and Melnikov, A. (2011). The websocket protocol.

Technical report.

Fowler, M. (2004). Inversion of control containers and the

dependency injection pattern.

Fowler, M. (2005). Language workbenches: The killer-app

for domain speciﬁc languages.

Gamma, E. and Beck, K. (2004). Contributing to Eclipse:

principles, patterns, and plug-ins. Addison-Wesley

Professional.

Go (2018). The go programming language.

Helms, M. M. and Nixon, J. (2010). Exploring swot anal-

ysis where are we now?: A review of academic re-

search from the last decade. Journal of Strategy and

Management, 3(3):215–251.

Hudak, P. (1997). Domain-speciﬁc languages. Handbook

of programming languages, 3(39-60):21.

JetBrains (2018). Intellij idea.

Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Speciﬁc Languages

139

JSON-RPC Working Group (2018). Json-rpc 2.0 speciﬁca-

tion.

Kats, L. C. and Visser, E. (2010). The spoofax language

workbench: Rules for declarative speciﬁcation of lan-

guages and ides. In Proceedings of the ACM Interna-

tional Conference on Object Oriented Programming

Systems Languages and Applications, OOPSLA ’10,

pages 444–463, New York, NY, USA. ACM.

Kichwas Coders (2018). Debugging protocol vs. language

server protocol.

Krahn, H., Rumpe, B., and V

olkel, S. (2014). Efﬁcient edi-

tor generation for compositional dsls in eclipse. arXiv

preprint arXiv:1409.6625.

Mar

oti, M., Kecsk

es, T., Keresk

enyi, R., Broll, B.,

olgyesi, P., Jur

acz, L., Levendovszky, T., and

edeczi,

A. (2014). Next generation (meta) model-

ing: Web-and cloud-based collaborative tool infras-

tructure. MPM@ MoDELS, 1237:41–60.

Microsoft (2018). Code editing. redeﬁned.

Microsoft (2018a). Implementations - language servers.

Microsoft (2018b). Language server protocol speciﬁcation

- base protocol.

Microsoft (2018c). Language server protocol speciﬁcation

- initialize.

Microsoft (2018). Monaco editor - about.

Microsoft (2018). Overview - what is the language server

protocol.

Mikkonen, T. and Taivalsaari, A. (2007). Using javascript

as a real programming language.

Miro Spnemann (2018). The language server protocol in

java.

Monsell, S. (2003). Task switching. Trends in Cognitive

Sciences, 7(3):134 – 140.

Popoola, S., Carver, J., and Gray, J. (2017). Modeling as

a service: A survey of existing tools. In MODELS

(Satellite Events), pages 360–367.

Reuters (2018). Cobol blues.

Rodriguez-Echeverria, R., Izquierdo, J. L. C., Wimmer, M.,

and Cabot, J. (2018). Towards a language server pro-

tocol infrastructure for graphical modeling. In Pro-

ceedings of the 21th ACM/IEEE International Con-

ference on Model Driven Engineering Languages and

Systems, MODELS ’18, pages 370–380, New York,

NY, USA. ACM.

Sendall, S. and Kozaczynski, W. (2003). Model transfor-

mation: the heart and soul of model-driven software

development. IEEE Software, 20(5):42–45.

Sourcegraph (2016). Files extension to the lsp.

Sourcegraph (2018). Languageserver.org.

Stroustrup, B. (2000). The C++ programming language.

Pearson Education India.

Theia.org (2018). Theia - cloud and desktop ide.

TIOBE (2018). Tiobe index for november 2018.

Tomassetti, F. (2017a). The complete guide to (external)

domain-speciﬁc languages.

Tomassetti, G. (2017b). Why you should know the language

server protocol.

Vogel, L. and Beaton, W. (2013). Eclipse IDE: Java pro-

gramming, debugging, unit testing, task management

and Git version conrol with Eclipse. Vogella series.

Vogella, [Lexington, Ky], 3rd ed. edition.

Vogel, L. and Milinkovich, M. (2015). Eclipse Rich Client

Platform. vogella series. Lars Vogel.

olter, M. (2013). DSL engineering: Designing, imple-

menting and using domain-speciﬁc languages. Cre-

ateSpace Independent Publishing Platform, Lexing-

ton, KY.

Xtext (2018). Idea support.

YAML (2018). Yaml ain’t markup language.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

140