Ist Xtend das neue Java? Vor- und Nachteile im Überblick.

Hatte sich Xtend ursprünglich wie Scala, Kotlin und andere als das nächste Java positioniert? Wie ist der Stand heute? Ist Xtend seinen Ambitionen gerecht geworden? Wird es überhaupt eingesetzt und wenn ja, wofür?

2011 wurde Xtend als Teil von Xtext veröffentlicht. Zu diesem Zeitpunkt lag Java 8 noch drei Jahre in der Zukunft. Von Lambdas in Java konnte man zu dieser Zeit also nur träumen. Dadurch, dass Xtend nach Java kompilierte, zugleich aber moderne Features umsetzte, erlaubte es eine komplette Rückwärtskompatibilität, eine perfekte Integration mit Java bei gleichzeitig massiv vereinfachtem Code. Daher wurde nicht nur Xtend mit Xtext entwickelt, sondern auch umgekehrt der Xtext-Code mithilfe von Xtend vereinfacht. Wie aber ist der Stand heute?

Um das zu klären, schauen wir uns zunächst einige Stärken von Xtend an.

1. Template-Expressions: Diese sind so mächtig, dass eine Templatebibliothek wie zum Beispiel Velocity komplett überflüssig wird. Text zu generieren ist so innerhalb der Sprache wesentlich einfacher als mit Java. Ein einfaches Beispiel:
   

   public String javaStub(String name) {
       StringBuilder result = new StringBuilder();
       result.append("public class ").append(name).append("{").append(System.lineSeparator());
       result.append("public static void main(String[] args) {").append(System.lineSeparator());
       result.append("}").append(System.lineSeparator());
       result.append("}");
       return result.toString();
   }

   Vergleichbarer Code in Xtend:
   

   def javaStub(String name) '''
   public class «name» {
       public static void main(String[] args) {
       }
   }'''

   Schon dieses sehr einfache Beispiel macht deutlich, warum es wenig Freude macht, Generatoren in Java zu schreiben, während es sich in Xtend so anfühlt, als sei man zu Hause. Auch bei Tests, welche auf Texten basieren, spielt Xtend diese Stärke aus. Die Spezifikation von Input und Output fällt einfach viel leichter, wenn sie nicht durch die umständliche Java-Syntax unterbrochen werden.
2. Java-Interoperability: Da Xtend nach Java kompiliert, ist es sehr einfach, Java und Xtend im selben Projekt zu verwenden. Einfach in einen separaten Source-Folder generieren (welcher normalerweise nicht eingecheckt wird), den Rest übernimmt der Java-Compiler. Dadurch können alle Java-Klassen sehr einfach Xtend referenzieren und umgekehrt. Es ist also nicht nötig, alles in Xtend zu schreiben, sondern man setzt es einfach nur dort ein, wo es sinnvoll ist.

Natürlich hat Xtend viele weitere Features, die im Vergleich zu Java den Code lesbarer machen, zum Beispiel Extension-Methods, (lesbare) Lambda-Expressions oder Operator-Overloading. Für mich sind das allerdings nur kleine Nettigkeiten die, richtig eingesetzt, punktuell Vorteile bringen, ohne in vielen Fällen den Code grundsätzlich zu verändern.

Und was sind die größten Schwächen von Xtend?

1. Nur Eclipse unterstützt Xtend wirklich. 2011 kam Eclipse zumindest in Deutschland auf einen Marktanteil von etwa 70 %. Daher war zu dieser Zeit auch kaum von Nachteil, dass andere IDEs keine gute Sprachunterstützung boten. Heute stellt sich die Situation etwas anders dar. Die IDE-Landschaft ist heterogener geworden. Es ist schwierig, genaue Zahlen zu bekommen, aber es ist klar, dass Eclipse nicht mehr der Platzhirsch ist, sondern momentan nach IntelliJ IDEA auf Platz 2 landet. Eine Sprache, deren Unterstützung primär von einer IDE abhängt, kann aus meiner Sicht kein Java-Ersatz sein.
2. Die Compile-Zeiten sind, bedingt durch den Zwischenschritt der Java-Generierung, länger als bei vielen anderen Sprachen. Das macht sich insbesondere dann bemerkbar, wenn Xtend großflächig zum Einsatz kommt.
3. Das Tooling von Xtend ist zwar gut, aber doch nicht so gut wie das von Java. Wer komplett auf Xtend setzt, verzichtet also auf den einen oder anderen Komfort, den er vielleicht gewohnt ist.

Aus den Nachteilen lässt sich folgern: Nur dann, wenn Eclipse aus dem einen oder anderen Grund als IDE gesetzt ist – ein Szenario, welches zum Beispiel bei vielen Industrieunternehmen gegeben ist, welche alle ihre Werkzeuge in einer Plattform integriert haben –, kann eine Entscheidung pro Xtend sinnvoll sein.

Aber auch, wenn dies der Fall ist, stellt sich die weitere Frage: In welchen Bereichen sollte Xtend zum Einsatz kommen? Wenn das komplette System aus Xtend gebaut wird, schlagen die Nachteile voll durch. Die Zeit zum Bauen der Anwendung steigt, und die nicht ganz optimale IDE stört in jeder einzelnen Quellcode-Datei. Daher kann es nur sinnvoll sein, Xtend lediglich punktuell einzusetzen, was durch die mühelose Java-Integration sehr einfach ist. Welche Bereiche das sind, wird an den Vorteilen deutlich: Überall dort, wo Text generiert oder verarbeitet wird – insbesondere, aber nicht ausschließlich, in Xtext Projekten –, spielt Xtend seine Stärken aus. Besonders für Generatoren und Tests ist Xtend sinnvoll. Ein neues Java ist Xtend aber nicht.

Interessiert, wie Xtend-Code aussehen könnte? Viele Beispiele finden sich im Quellcode von Xtext. Einfach vorbeischauen:

Hast du bereits Erfahrungen mit Xtend? Schreibe mir deine Erfahrung in die Kommentare!