Es muss nicht immer Eclipse sein

DSLs mit Xtext für IntelliJ IDEA

Stefan Oehme

© Shutterstock/Suchota

Xtext hat sich im Eclipse-Umfeld als das Standardwerkzeug für die Entwicklung domänenspezifischer Sprachen durchgesetzt. Doch so mancher Entwickler bevorzugt IntelliJ IDEA und muss sich dort bisher ohne ein vergleichbares Framework durchschlagen. Doch nicht mehr lange.

Schon seit geraumer Zeit berichten uns Nutzer von Xtext, es sei schwierig, Xtext in einem gemischten Team zu etablieren. Die User der IntelliJ-IDEA-Entwicklungsumgebung lehnen verständlicherweise ein Werkzeug ab, das in ihrer IDE nicht unterstützt wird. Andere mussten Eclipse als IDE ihrer Wahl auf Grund äußerer Zwänge aufgeben, zum Beispiel als Google Android Studio zur neuen Standard-IDE für Android-Entwicklung erklärte. Damit mussten sie auch die liebgewonnene Sprache Xtend zurücklassen. Das ist eine Situation, die wir vom Xtext-Team nicht länger auf sich beruhen lassen wollten. Daher entschlossen wir uns, Xtext für IntelliJ zu portieren.

Einer der großen Vorteile von Xtext ist die Kombination aus bequemen Standardimplementierungen und voller Konfigurierbarkeit für alle Aspekte einer Sprache. Dies wollen wir auch unseren IntelliJ-Nutzern bieten. GUI-unabhängige Konzepte wie Scoping, Validierung (Abb. 1) und der Codegenerator sollen nur einmal implementiert und auf allen Plattformen wiederverwendet werden können. Doch bereits bei diesen scheinbar plattformunabhängigen Aspekten wurden einige wichtige Unterschiede zwischen Eclipse und IntelliJ sichtbar.

Abb. 1: Validierungsregeln können plattformunabhängig implementiert werden

Abb. 1: Validierungsregeln können plattformunabhängig implementiert werden

IntelliJ hat ein eigenes Modellierungsframework, das zwingend zur Integration in die IDE benutzt werden muss. Xtext hingegen setzt für seine APIs auf das Eclipse Modeling Framework (EMF). Diese beiden Modelle müssen vom Parser erzeugt und bei späteren Änderungen synchron gehalten werden. Ein nicht zu verachtender Mehraufwand, auf dessen Optimierung wir viel Zeit verwendet haben. Des Weiteren arbeitet IntelliJ hochgradig parallel. Dienste wie Validierung, Syntax-Highlighting und der Structural View greifen gleichzeitig auf das Modell zu. Die Navigation von EMF-Modellen kann jedoch Seiteneffekte haben und muss deshalb sorgfältig synchronisiert werden.

Einen Autobuild wie in Eclipse gibt es in IntelliJ ebenfalls nicht. Innerhalb der IDE werden Dateien nur indiziert. Codegeneratoren und Compiler laufen in einem externen Prozess und werden nur auf Knopfdruck oder vor dem Ausführen einer Anwendung gestartet. Dies ist eine große Hürde für Xbase-basierte Sprachen, die Java-Code generieren, gegen den dann andere Java-Klassen linken können. Gleichzeitig verweigern viele IntelliJ-Dienste die Arbeit mit Java-Elementen, die nicht aus einer Java-Datei stammen. Ein „Synthetisieren“ von Java-Elementen erwies sich als erfolglos. Daher entschlossen wir uns letztlich, einen kontinuierlichen Generatorprozess innerhalb der IDE zu implementieren. Als positiver Nebeneffekt entstand so ein Eclipse-unabhängiger, inkrementeller Generator, der bald auch im Gradle-Build-System Verwendung finden wird.

Neben Parser, Generator und der Integration in die Indexinfrastruktur sind auch bereits viele Editorfeatures vorhanden. Lexer-basiertes Syntax-Highlighting, Autovervollständigung von Schlüsselwörtern und Referenzen (Abb. 2), Navigation sowie einfache Rename Refactorings bilden die Grundlage für bequemes Editieren. Die Validierungsregeln der Sprache werden genau wie in Eclipse ausgeführt (Abb. 1) und entsprechende Markierungen erzeugt. Auch einen Structural View für den schnellen Überblick über den Dateiinhalt gibt es bereits.

Abb. 2: Dank wiederverwendetem Scoping funktioniert auch Autovervollständigung ohne Mehraufwand

Abb. 2: Dank wiederverwendetem Scoping funktioniert auch Autovervollständigung ohne Mehraufwand

Andere Dienste wie semantisches Highlighting, Formatierung, Intentions (vgl. Quick Assist und Quick Fix in Eclipse) sowie Template-Proposals werden in späteren Versionen folgen. Aktuell stehen Stabilität und Performanz im Zentrum unserer Bemühungen. Im Herbst dieses Jahres soll eine erste stabile Version veröffentlicht werden.

Für Experimentierfreudige gibt es bereits eine Betaversion, die von der Xtext-Milestone-Updateseite installiert werden kann. Der New-Xtext-Project-Dialog (Abb. 3) wurde umfangreich erweitert und bietet nun die Integration für verschiedene Plattformen an. Nach dem Anlegen der Projekte öffnet sich wie gewohnt der Grammatikeditor. Mit Run As | Generate Xtext Artifacts generieren wir die Infrastruktur für unsere Sprache, inklusive der IntelliJ-spezifischen Dienste.

Abb. 3: Der neue Wizard macht den Einstieg kinderleicht

Abb. 3: Der neue Wizard macht den Einstieg kinderleicht

Nun gilt es nur noch, IntelliJ samt installierter Sprache zu starten. Um diesen Prozess so einfach wie möglich zu halten, haben wir ein Gradle-Plug-in entwickelt. Dieses lädt automatisch IntelliJ in der richtigen Version herunter, fügt dessen Bibliotheken dem Klassenpfad hinzu und kann das fertige Produkt starten und auch testen. Der hierzu nötige Build-Task namens runIdea kann entweder über die Kommandozeile oder mit Eclipse Buildship aufgerufen werden.

Im Laufe der nächsten Monate sollen die Fortschritte in einigen weiteren Betaversionen vorgestellt werden. Wir freuen uns über reges Feedback im Xtext-Forum.

Aufmacherbild: Abstract multicolored background. Colorful radial blur von Shutterstock / Urheberrecht: Suchota

Verwandte Themen:

Geschrieben von
Stefan Oehme
Stefan Oehme
Stefan Oehme ist Core Developer bei Gradle. Twitter: @StefanOehme
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: