Warum Sie in den allermeisten Fällen auf XML verzichten können

Goodbye XML – Befreiungsakt mit Xtext

Sven Efftinge und Sebastian Zarnekow

„Das machen wir am besten mit einer XML-Konfiguration?“ – wie oft hat dieser Satz wohl so oder in ähnlicher Form schon die Lippen eines Architekten oder Entwicklers verlassen. Und wem kann man daraus einen Vorwurf machen? Schließlich haben Spring, Maven, Ant und Co. seit Jahr und Tag vorgemacht, wie Softwaresysteme mithilfe externer Konfigurationen im XML-Format initialisiert, angepasst oder kompiliert werden. Java selbst bietet ja schließlich relativ wenige Möglichkeiten, Baumstrukturen übersichtlich zu definieren. Doch ist XML heute wirklich noch state-of-the-art? Sollte die umständliche aber generische Syntax nicht besser einer kompakten und leserlichen Schreibweise weichen? Oder lohnt sich der Aufwand für eine eigene Notation nicht?

Die neue Eclipse-Version 3.6 wurde im Juni dieses Jahres veröffentlicht, und mit von der Partie war das Xtext-Framework [1] für die Implementierung eigener Sprachen inklusive Eclipse-Integration. Um es gleich vorweg zu nehmen: Xtext eignet sich natürlich nicht nur zur Definition einfacher XML-artiger Strukturen. Wir sehen hier allerdings einen interessanten Anwendungsfall und wollen im vorliegenden Artikel die vielen Vorteile aufzeigen, die ein Einsatz einer DSL im Vergleich zur traditionellen XML-Alternative hat.

Die Maven POM als Versuchskaninchen

Anhand eines konkreten Beispiels lassen sich die unterschiedlichen Ansätze am besten vergleichen. Dazu wollen wir ein sehr kleines Subset der zentralen Projektbeschreibungsprache aus Maven [2] bemühen. Maven wird hauptsächlich verwendet, um Projekte zu bauen und Abhängigkeiten zu anderen Projekten und Bibliotheken zu verwalten. Im Zentrum von Maven werden dazu pro Projekt so genannte POMs (Project Object Model) gepflegt. Diese XML-Dateien enthalten neben dem Namen und der Version eines Projekts unzählige andere Eigenschaften. Dazu gehört die Liste der Autoren genauso wie die Liste der Abhängigkeiten. Für unseren Artikel verwenden wir die POM, die Maven beim Erzeugen eines neuen Projekts automatisch anlegt (Listing 1). Wie man sieht, enthält diese initiale POM neben unterschiedlichen Namensfragmenten auch Versionsinformationen und eine Abhängigkeit auf JUnit. Insgesamt werden hierfür 21 Zeilen XML-Konfiguration benötigt. Sehr große Anteile, z. B. die kryptische Deklaration der Namensräume und der Import des Schemas, sind technischer Natur und enthalten gar keine projektspezifischen Informationen.  

  <?xml version="1.0"?> 
  <project xmlns="http://maven.apache.org/POM/4.0.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
  http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
  <modelVersion>4.0.0</modelVersion> 
  <groupId>com.mycompany.app</groupId> 
  <artifactId>my-app</artifactId> 
  <packaging>jar</packaging> 
  <version>1.0-SNAPSHOT</version> 
  <name>Maven Quick Start Archetype</name> 
  <url>http://maven.apache.org</url> 
  <dependencies> 
  <dependency> 
  <groupId>junit</groupId> 
  <artifactId>junit</artifactId> 
  <version>3.8.1</version> 
  <scope>test</scope> 
  </dependency> 
  </dependencies> 
  </project>

 Die sehr generische und vor allem geschwätzige XML-Syntax hat zwar den kleinen Vorteil, dass jeder, der sie einmal erlernt hat, weiß, welche Konstrukte syntaktisch erlaubt sind. Allerdings bezieht sich das wirklich nur auf die so genannte konkrete Syntax, also darauf, dass es z. B. Elemente in spitzen Klammern gibt, die über Attribute oder Text verfügen und weitere Elemente enthalten. Die Sprache bzw. der XML-Dialekt selbst ist natürlich wesentlich komplexer und im Fall der Maven POM in einer über 2000 Zeilen langen XML Schema Definition (XSD) spezifiziert. Sie definiert beispielsweise, dass es unterhalb von project ein Element mit dem Namen groupId gibt und auch welche Werte hier wiederum erlaubt sind. Damit ist sie absolut proprietär. Zugegebenermaßen könnte man den POM-Dialekt selbst mit XML-Mitteln um einiges verbessern, aber in Anbetracht der Tatsache, dass täglich tausende von Programmierern auf der ganzen Welt mit dieser Sprache entwickeln, liegt die Idee einer benutzerfreundlicheren Sprache nahe.

Wie wäre es beispielsweise, wenn wir die Informationen statt in XML wie in Listing 2 angeben könnten? Der visuelle Raum, den diese Variante beansprucht, wurde im XML-Fall schon allein durch den Import des Schemas vollständig ausgeschöpft. Weiterhin sind wir hier alle überflüssigen Steuerzeichen losgeworden und haben bei den wichtigsten Attributen darauf verzichtet, jedes Mal den Attributnamen anzugeben. Das macht die Syntax viel leserlicher und kompakter. Stellen Sie sich vor, sie müssten in Java statt public class Foo {} immer auch die Namen der Eigenschaften mit angeben: visibility=public class name=Foo classBody={ }. Das würde die Lesbarkeit erheblich verschlechtern und den Code zusätzlich aufblähen. Intuitiv würde wahrscheinlich niemand auf die Idee kommen, auf diese Art eine Programmiersprache zu definieren. Nichtsdestotrotz verfolgt XML genau diesen Ansatz.

project "Maven Quick Start Archetype" (http://maven.apache.org)
id com.mycompany.app.myapp 1.0-SNAPSHOT
packaging jar
depends on junit.junit 3.8.1 for test 

Gute Defaults sind ein weiteres wichtiges Mittel, um eine Sprache von unnötigem Ballast zu befreien. Wenn die überwiegende Mehrheit der Projekte z. B. als jar gepackt wird, dann sollte man nur für die verbleibende Minderheit das packaging angeben müssen. Alle anderen werden dann per Default zu einem jar verschnürt.

Wir sehen also, dass eine spezifische Sprache mit eigener Syntax viele wichtige Vorteile gegenüber einer generischen XML-Sprache hat. Die entscheidende Frage ist, ob wir in der Lage sind, so eine Sprache zu bauen – und das mit sinnvollem Aufwand. Maven ist für diesen Aspekt eigentlich ein schlechtes Beispiel, da es enorm viele User besitzt. Summiert man die Zeit, die Entwickler mit dem Lesen und Editieren von pom.xml-Dateien verbracht haben und auch zukünftig verbringen werden, würde sich hierfür wahrscheinlich sogar ein handgeschriebener, in Assembler programmierter Parser lohnen. Tatsächlich ist die Definition der in Listing 2 abgebildeten Sprache aber einfacher und kürzer als die XML-Schema-Variante.

[ header = Seite 2: Compiler-Bauer? Das sind doch die von der Uni! ]

Compiler-Bauer? Das sind doch die von der Uni!

In Listing 3 sehen sie den Ausschnitt aus der originalen XML-Schema-Datei für Mavens POM, der notwendig ist, um die in Listing 1 gezeigte XML-Datei zu validieren. Demgegenüber zeigt Listing 4 die Xtext-Definition der in Listing 2 benutzten, stark vereinfachten Sprache. Wenn Sie XML und besonders XSD kennen, werden Sie sich im gekürzten Maven-Schema wahrscheinlich auf den ersten Blick ganz gut zurechtfinden. Die Xtext-Variante hingegen wird Ihnen höchstens vertraut vorkommen, wenn Sie in der Vorlesung „Compiler-Bau“ gut aufgepasst haben. Die theoretischen Untiefen, die Sie möglicherweise während dieser Veranstaltung kennengelernt haben, können Sie allerdings ruhigen Gewissens zur Seite legen.

  <?xml version="1.0"?> 
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" 
  targetNamespace="http://maven.apache.org/POM/4.0.0" 
  xmlns="http://maven.apache.org/POM/4.0.0"> 
  <xs:element name="project" type="Model"/> 
  <xs:complexType name="Model"> 
  <xs:all> 
  <xs:element name="modelVersion" minOccurs="0" type="xs:string"/> 
  <xs:element name="groupId" minOccurs="0" type="xs:string"/> 
  <xs:element name="artifactId" minOccurs="0" type="xs:string"/> 
  <xs:element name="packaging" minOccurs="0" type="xs:string" default="jar"/> 
  <xs:element name="name" minOccurs="0" type="xs:string"/> 
  <xs:element name="version" minOccurs="0" type="xs:string"/> 
  <xs:element name="url" minOccurs="0" type="xs:string"/> 
  <xs:element name="dependencies" minOccurs="0"> 
  <xs:complexType> 
  <xs:sequence> 
  <xs:element name="dependency" minOccurs="0" maxOccurs="unbounded" type="Dependency"/> 
  </xs:sequence> 
  </xs:complexType> 
  </xs:element> 
  </xs:all> 
  </xs:complexType> 
  <xs:complexType name="Dependency"> 
  <xs:all> 
  <xs:element name="groupId" minOccurs="0" type="xs:string"> 
  </xs:element> 
  <xs:element name="artifactId" minOccurs="0" type="xs:string"> 
  </xs:element> 
  <xs:element name="version" minOccurs="0" type="xs:string"> 
  </xs:element> 
  <xs:element name="scope" minOccurs="0" type="xs:string"> 
  </xs:element> 
  </xs:all> 
  </xs:complexType> 
  </xs:schema>

 

1.	grammar org.xtext.simplemaven.SimpleMaven with org.eclipse.xtext.common.Terminals 
2.	generate simpleMaven "http://www.xtext.org/simplemaven/SimpleMaven" 
3.	
4.	Project: 
5.	'project' (description=STRING url=PARENTHESIZED?)? 
6.	'id' name=QualifiedName version=Version 
7.	('packaging' kind=PackageKind)? 
8.	('depends on' dependencies+=Dependency 
9.	(‘,’ dependencies+=Dependency)+)?; 
10.	Dependency: 
11.	name=[Project|QualifiedName] version=Version ('for' scope=Scope)?; 
12.	enum Scope: 
13.	compile | provided | runtime | test | system; 
14.	enum PackageKind: 
15.	pom | jar | mavenPlugin="maven-plugin" | ejb | war | ear | rar | par; 
16.	QualifiedName: 
17.	ID ('.' ID)*; 
18.	Version: 
19.	INT ('.' INT ('.' INT)?)? '-SNAPSHOT'?; 
20.	terminal PARENTHESIZED: 
21.	'('->')'; 
22.	

Einen Parser zu programmieren, ist nicht trivial. Aber einen Parser-Generator mit einer funktionierenden Grammatik zu füttern, ist absolut keine Zauberei. Die Grammatiksprache in Xtext ist in sich selbst definiert, und das in nur 173 Zeilen. Im Gegensatz dazu fällt das XML Schema für Maven mit knapp 3000 Zeilen recht üppig aus. Wir wollen im Rahmen dieses Artikels nicht die ganze Xtext-Grammatiksprache erklären, jedoch auf die Menge und die Art der Informationen verweisen, die diese enthält.

Die XSD-Datei für unsere minimalen POMs ist mehr als doppelt so groß wie die Xtext-Grammatik und enthält lediglich Informationen über die Struktur der XML-Sprache. Diese Struktur wird üblicherweise die abstrakte Syntax genannt. In der Xtext-Grammatik wird zusätzlich auch die konkrete Syntax definiert, d. h. die konkrete textuelle Form, in der Konzepte der Sprache geschrieben werden sollen. Weiterhin können hier Literale für Datentypen, Enumerationen und sogar beliebige Querverweise deklariert werden. In unserer Xtext-basierten Maven-Sprache sind beispielsweise die Namen der Dependencies echte Querverweise auf Projektdeklarationen in anderen Dateien. Hat man sich im Namen einer Dependency vertippt (z. B. nunit statt junit), wird einem der Linker schon beim Laden der Datei sagen, dass die angegebene Dependency nicht existiert (Abb. 1). XML Schema unterstützt zwar auch eine einfache Form von Querverweisen, diese sind aber so stark limitiert, dass sie z. B. für den beschriebenen Fall gar nicht anwendbar wären.

Abb. 1: Echte Querverweise

Wir haben nun also die Sprache mit der kompakten Syntax definiert und festgestellt, dass das gar nicht so viel zu tippen war. Manch einer mag jetzt Folgendes denken: Ja, aber das Tolle an XML ist nicht nur, dass man keinen Parser bauen muss, sondern dass es aufgrund der generischen Syntax auch schon tausende tolle Werkzeuge gibt, die damit zusammenspielen. Darauf will man nicht verzichten, und eine IDE für die eigene Sprache zu entwickeln, ist viel zu aufwändig. Glücklicherweise ist das mit Xtext nicht nötig.

[ header = Seite 3: IDE per Fingerschnipp ]

IDE per Fingerschnipp

Die Laufzeitinfrastruktur von Xtext ist schon sehr fortschrittlich. Man bekommt nicht nur einen Parser, sondern auch getypte EMF-Klassen [3] (ähnlich, aber wesentlich besser als JAXB), einen Linker für Querverweise, einen Serialisierer (oder Unparser) und viele Dinge mehr. Darüber hinaus erlaubt die flexible, auf Google Guice[4] basierende Architektur, wirklich jeden Aspekt der Implementierung anzupassen oder sogar ganz auszutauschen.

Das Besondere an Xtext ist jedoch die umfassende Eclipse-Integration. Xtext benutzt die Informationen aus der Grammatik, um eine Entwicklungsumgebung an die Hand zu geben, die sich nicht nur nahtlos mit den Java Development Tools (JDT), also der Java IDE in Eclipse, integrieren lässt, sondern auch vom Funktionsumfang nahe an das große Vorbild herankommt. Von einem mächtigen Texteditor mit den aus Java gewohnten Funktionen, z. B. Syntax Coloring, Validierung, Autovervollständigung, Autoformatierung oder Outline Views, über IDE-Aspekte, wie globale Navigation, Indizierung, globale Suche und eine Integration in den Eclipse Incremental Builder, ist alles dabei, was eine moderne Entwicklungsumgebung ausmacht. Die Eclipse-abhängigen Teile sind zwar strikt von den Laufzeitkomponenten getrennt, können aber ebenfalls individuell angepasst und erweitert werden. Auch hier setzt Xtext auf die konsequente Verwendung von Dependency Injection mit Google Guice.

Verarbeitung der Daten

Sowohl für XML als auch für Xtext-basierte Sprachen existieren mannigfaltige Möglichkeiten, wie die abgelegten Informationen nach dem Editieren weiterverarbeitet werden können. Xtext spielt als Teil des Eclipse Modeling Project durch die Verwendung des allgegenwärtigen Modellierungsframeworks EMF von Haus aus mit zahlreichen anderen Eclipse-Technologien zusammen: sei es EMF Compare für das Ermitteln struktureller Unterschiede zwischen verschiedenen Versionen einer Datei, GMF für die grafische Bearbeitung oder ausgefeilte Templatesprachen wie Xpand[5] und Acceleo. Dadurch ist es sehr einfach möglich, Codegeneratoren, Interpreter oder Compiler beziehungsweise Transformationen zu implementieren. Für XML wiederum existiert mit XSLT eine mächtige Sprache für die Umwandlung der vorliegenden strukturierten Daten in andere XML-Dialekte, in HTML oder auch einfach nur in menschenlesbaren Text.

Um ein Gefühl für die jeweils verfügbaren Technologien zu vermitteln, haben wir mithilfe von XSLT aus der reduzierten pom.xml die Notation der Xtext POM erzeugt und nutzen Xpand als Templatesprache für den umgekehrten Weg (Listing 5 und 6).

Abb. 2: Der Xtext-Editor in Aktion

  <?xml version="1.0"?> 
  <xsl:stylesheet version="1.0" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
  <xsl:output method="text" /> 
  <xsl:template match="/project"> 
  <xsl:text>project "</xsl:text> 
  <xsl:value-of select="name" /> 
  <xsl:text>" (</xsl:text> 
  <xsl:value-of select="url" /> 
  <xsl:text>) 
  id </xsl:text> 
  <xsl:call-template name="fqnWithVersion"/> 
  <xsl:text> 
  packaging </xsl:text> 
  <xsl:value-of select="packaging" /> 
  <xsl:if test="dependencies/dependency"> 
  <xsl:text> 
  depends on </xsl:text> 
  <xsl:for-each select="dependencies/dependency"> 
  <xsl:call-template name="fqnWithVersion"/> 
  <xsl:text> for </xsl:text> 
  <xsl:value-of select="scope" /> 
  <xsl:if test="position()!=last()"> 
  <xsl:text>, 
  </xsl:text> 
  </xsl:if> 
  </xsl:for-each> 
  </xsl:if> 
  </xsl:template> 
  <xsl:template name="fqnWithVersion"> 
  <xsl:value-of select="groupId" /> 
  <xsl:text>.</xsl:text> 
  <xsl:value-of select="artifactId" /> 
  <xsl:text> </xsl:text> 
  <xsl:value-of select="version" /> 
  </xsl:template> 
  </xsl:stylesheet>

 

1.	«IMPORT org::xtext::simplemaven::simpleMaven» 
2.	«EXTENSION templates::Extensions» 
3.	«DEFINE main FOR Project-» 
4.	«FILE name+"-pom.xml"-» 
5.	<?xml version="1.0"?> 
6.	<project 
7.	xmlns="http://maven.apache.org/POM/4.0.0" 
8.	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
9.	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 maven-pom.xsd "> 
10.	<modelVersion>4.0.0</modelVersion> 
11.	<groupId>«groupId()»</groupId> 
12.	<artifactId>«artifactId()»</artifactId> 
13.	<packaging>«kind.name»</packaging> 
14.	<version>«version»</version> 
15.	<name>«description»</name> 
16.	<url>«url»</url> 
17.	«IF !dependencies.isEmpty» 
18.	<dependencies> 
19.	«FOREACH dependencies AS d» 
20.	<dependency> 
21.	<groupId>«groupId(d.name)»</groupId> 
22.	<artifactId>«groupId(d.name)»</artifactId> 
23.	<version>«d.version»</version> 
24.	<scope>«d.scope.name»</scope> 
25.	</dependency> 
26.	«ENDFOREACH» 
27.	</dependencies> 
28.	«ENDIF» 
29.	</project> 
30.	«ENDFILE-» 
31.	«ENDDEFINE» 
32.	
33.	Die zugehörigen Extensions: 
34.	
35.	import org::xtext::simplemaven::simpleMaven; 
36.	groupId(Project this) : 
37.	name.split(".").withoutLast().toString("."); 
38.	artifactId(Project this) : 
39.	name.split(".").last();  

Beim Vergleich der beiden Lösungen fällt auf, dass sie sich in der Länge scheinbar nicht wesentlich unterscheiden. Auf den zweiten Blick wird jedoch deutlich, dass das Template für die Xpand-basierte Umsetzung fast genau so wenige (oder eher viele) Zeilen hat, wie die dadurch generierte XML-Datei. Die Konstrukte der Templatesprache selbst verursachen nur geringes Rauschen in der Abbildungsvorschrift.

Ganz anders sieht es im XSLT-Template aus. Da auch XSLT ein XML-Format ist, gibt es wieder sehr viele öffnende und schließende Elemente, die von der eigentlich transportierten Information und damit von den Regeln ablenken, die auf die Eingaben anzuwenden sind. Obwohl wir nur wenige Zeilen in unserer sehr kompakten Notation erzeugen wollen, ist dies auf den ersten Blick nur schwer zu erfassen. Die vielen XSLT-Syntaxelemente lenken von den statischen Informationen ab, die sich in der generierten Zieldatei wiederfinden. Der Vorteil, den wir für die Xtext-basierte POM gegenüber dem XML-Format identifiziert haben, lässt sich eins zu eins auf den Vergleich von Xpand mit XSLT übertragen. Wieder gilt, dass die spezialisierte Syntax der Templatesprache dem generischen Charakter von XML überlegen ist. [ header = Seite 4: Die Sonnenseiten von XML ]

Es zeigt sich abermals, dass eine Sprache, die genau einen Problembereich adressiert und im Erscheinungsbild möglichst frei von syntaktischen Einschränkungen ist, deutlich leichter geschrieben und vor allem gelesen und verstanden werden kann. Wenn bei der Entwicklung der Sprache auch noch ein moderner Editor für die spezialisierte DSL mitgeliefert wird und mächtige Tools für die Weiterverarbeitung der Daten bereitstehen, gibt es kaum noch einen Grund, auf XML zu setzen.

Die Sonnenseiten von XML

XML ist natürlich nicht in jeder Situation eine schlechte Wahl. Die Faustregel, kein XML zu verwenden, sobald Menschen diese Dateien lesen oder editieren müssen, passt im Prinzip schon ganz gut. Wir möchten aber fairerweise zwei Eigenschaften nennen, die XML durchaus attraktiv machen können:

  1. XSD wird interpretiert: Mit Xtext müssen Sie nach einer Änderung in der Grammatik die Implementierung des Parsers neu generieren und auch den Editor neu deployen bzw. die Testumgebung neu starten. Bei der Entwicklung sind die Turnaround-Zeiten mittlerweile wirklich nahe an einem interpretativen Modus – aber eben nicht ganz. Ohne Neustart oder erneute Kompilierung die Sprache zu verändern, hat gerade in der Prototypphase durchaus seinen Reiz.
  2. XML Parser gibt es für jede Plattform: Xtext generiert eine Implementierung für die JVM, d. h. solange Sie eine Sprache nutzen, die auf der JVM ausgeführt wird, gibt es kein Problem. Wenn Sie allerdings in C, C++ oder auf der .NET-Plattform Modelle einer Xtext-Sprache laden möchten, sieht es nicht gut für Sie aus.

Falls Sie einen dieser Punkte für sich als entscheidendes Kriterium ansehen, sollten Sie vielleicht auch noch andere Alternativen wie JSON[6] oder YAML[7] in Betracht ziehen.

[ header = Seite 5: Es ist nie zu spät! ]

Es ist nie zu spät

Sofern man in einem Softwareprojekt einen proprietären XML-Dialekt verwendet, ist man natürlich nicht automatisch dazu verdammt, auf immer und ewig daran festzuhalten. Auch eine sukzessive Ablösung und Umstellung auf ein Xtext-basiertes Format ist möglich. Gerade die Verwendung des Eclipse Modeling Framework erweist sich dabei wieder als sehr hilfreich. Um mit Xtext herumzuspielen, ohne ein völlig synthetisches Szenario umzusetzen, kann beispielsweise mit EMF-Bordmitteln aus einem existierenden XML Schema ein korrespondierendes Ecore-Modell abgeleitet werden. Dabei werden die Konzepte und Typen aus dem Schema nach EMF übersetzt, und nachdem der EMF-Generator mit diesem Ecore-Modell konfiguriert und ausgeführt wurde, entsteht im Grunde ein typsicheres API genau für das eigene Schema.

Seit Version 1.0 erlaubt es Xtext, aus einem bestehenden Ecore-Modell wiederum eine initiale Grammatik abzuleiten. Sie enthält einfach eine Regel für jedes Konzept aus dem Ecore-Modell. Damit wird schon einmal eine gute Ausgangslage geschaffen, die eine Analyse nahe am echten Projektszenario zulässt. Von hier aus ist es kinderleicht, die automatisch erzeugte Grammatik nach und nach abzuspecken, an die eigenen Vorstellungen anzupassen und dabei stets inhaltlich kompatibel zu dem ursprünglichen XML-Format zu bleiben.

Im Grunde wird dadurch einfach eine alternative Syntax für das existierende Schema erzeugt. In beiden Formaten können jetzt gleichwertige Informationen abgelegt werden. EMF erlaubt es anschließend mit wenigen Zeilen Code, das XML nach Xtext zu übersetzen und umgekehrt. Ersten Experimenten mit der Technologie steht also nichts im Weg. Und da die beiden Syntaxen ineinander überführt werden können, stehen natürlich ausgehend von beiden Richtungen die gleichen Möglichkeiten für die Weiterverarbeitung des initialisierten Modells zur Verfügung. Wenn man also Xpand oder andere EMF-Technologien sowohl mit Xtext-basierten als auch gleichzeitig mit den existierenden XML-Modellen verwenden möchte, ist dies problemlos möglich – und sobald man von der Technologie überzeugt ist, können auf diesem Weg Schritt für Schritt alle alten Dateien abgelöst werden.

Spätestens nach den ersten eigenen Gehversuchen mit Xtext sollte auch den letzten Zweiflern deutlich werden, wie einfach das Bauen einer eigenen Sprache von der Hand geht. Freilich soll hier nichts verschönert werden: Es ist nicht trivial, eine vollständige Programmiersprache wie Java mit Xtext umzusetzen (aber mit Hexenwerk hat auch das nichts zu tun). Doch gerade, wenn es um statische Daten geht, wie sie in der Vergangenheit üblicherweise mit XML erfasst wurden, können mit Xtext schon nach sehr kurzer Zeit beachtliche Erfolge erzielt werden – und wer einmal mit EMF-basierten Modellen anstelle von Java Beans gearbeitet hat, wird auch dieses Framework nicht mehr missen wollen.

Sebastian Zarnekow ist Softwarearchitekt und Berater bei itemis. Er entwickelt Frameworks und Tools, um die modellgetriebene Softwareentwicklung zu verbessern und die Produktivität zu steigern. Sebastian ist Committer im Eclipse Modeling Project.
Sven Efftinge ist bei der itemis AG (http://www.itemis.de) beschäftigt und maßgeblich für die Weiterentwicklung von Methoden und Werkzeugen für die modellgetriebene Softwareentwicklung verantwortlich. Er ist Mitglied des Eclipse Modeling PMC und leitet die Entwicklung des TMF-Xtext-Frameworks. Er spricht regelmäßig auf Softwarekonferenzen und ist Koautor des Buchs „Modellgetriebene Softwareentwicklung“ (dpunkt). 
Geschrieben von
Sven Efftinge und Sebastian Zarnekow
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.