Java 2020 == Kotlin?

(Kommentare: 0)

Die Lernkurve beim Umstieg von Java auf Kotlin ist steil, aber der Umstieg fühlt sich natürlich an.
Die Lernkurve beim Umstieg von Java auf Kotlin ist steil, aber der Umstieg fühlt sich natürlich an.

Embrace Change

Über 20 Jahre gibt es nun Java, 19 davon habe ich in Java entworfen und programmiert. Selten habe ich das Bedürfnis gehabt, etwas anderes zu benutzen, spätestens seit 2003 Eclipse als Entwicklungsumgebung herauskam. Im Januar 2018 aber begann ich dann mit einem App-Projekt für Android. Google setzt Kotlin als die Sprache der Zukunft für seine Plattform. Die Frage war also: Bauen wir auf die breite Erfahrung mit Java, was natürlich machbar wäre, oder starten wir mit Kotlin. Ein Kollege, der schon ein solches Projekt realisiert hatte, sagte damals: „You will love it“. Ich habe mir dann ein paar Sprachkonstrukte und die IDE-Integration von ihm zeigen lassen, die Dokumentation und die Verbreitung der Sprache recherchiert und dann beschlossen, mich darauf einzulassen. Heute kann ich sagen: Der Kollege hat Recht behalten.

Java: 20 Jahre das Maß der Dinge

Als Java Ende der 90er Jahre aufkam, brachte es einige gute Konzepte zusammen. Weniger die sprachlichen, vielmehr die organisatorischen Konzepte machten es attraktiv: Gemacht fürs Internet, plattformunabhängig und übergeordnete Standarddefinitionen wie J2EE. Syntaktisch war es damals State-of-the-Art und hat sich in den Folgejahren auch entsprechend weiterentwickelt. Und immer blieb es dabei abwärtskompatibel.
Und da liegt sowohl der Segen als auch der Haken: Alte Zöpfe wurden nie abgeschnitten und behindern bis heute Verbesserungen. Ein Beispiel hierfür sind die Generics (der Art List<T>), die deswegen immer konzeptionelle Lücken haben werden. Ebenso unhandlich sind ständig zu wiederholende Deklarationsanteile. Wie oft haben wir mittlerweile die Wortfolge „public static void“ gelesen oder geschrieben?

Kotlin hat seine Wurzel ganz offensichtlich in seinem Vorgänger.
Kotlin hat seine Wurzel ganz offensichtlich in seinem Vorgänger.

Kotlin räumt auf

Mit Kotlin schickt sich eine jüngere Programmiersprache an Java abzulösen, die ihre Wurzeln ganz offensichtlich bei ihrem Vorgänger hat. Dabei schneidet Kotlin die alten Zöpfe ab und lässt Erfahrungen aus anderen neueren Sprachen wie C#, Scala und Groovy einfließen.
Deklarationen in Kotlin arbeiten dabei mit gängigen Defaults, die häufigen Keywords extends und implements werden durch einen Doppelpunkt ersetzt, das Semikolon am Zeilenende entfällt ganz – ebenso das Schlüsselwort new zum Erzeugen neuer Objekte. Für Funktionen ohne Rückgabewert entfällt dessen Deklaration (void). Diese und weitere Vereinfachungen führen dazu, dass der Code wesentlich kompakter und dadurch sprechender ist.

Die für mich wichtigsten sprachlichen Verbesserungen finden sich im Umgang mit Null-Werten. Einerseits werden in Kotlin Nullables als explizite Typen von den Nicht-Null-werdenden unterschieden. Das sorgt für Klarheit und vermeidet so manche NullpointerException schon beim Kompilieren. Hat man es doch mal mit möglichen Nullen zu tun, so kann man die über Fragezeichenoperatoren elegant behandeln. Es ist für mich eines der großen Rätsel, dass Java nicht schon längst, den „Safe Navigation Operator“ ?. ins Sprachprogramm aufgenommen hat. Möglich, dass er dort mit dem ternären Operator kollidieren würde, den es in Kotlin gar nicht gibt. Diese sichere Navigation über Objektpfade  bietet Kotlin und dazu den rocking „Elvis-Operator“ ?:.

Ein Appetizer:

Kotlin:
var favouriteAnimal = autralia?.wombat ?: throw AppException(„no animal“)
Java:
String favouriteAnimal = australia != null ? australia.wombat : null;
if( favouriteAnimal == null )
      throw new AppException(„no animal“);
}

Wer mag, kann den Variablen Typen geben. Meist ist dies aber nicht notwendig. Den Typ nicht explizit zu deklarieren, erleichtert ein späteres Refactoring.

Und weiter geht’s mit dem Eindampfen von Code ohne Mehrwert: Baut man in Java Komponenten (also Klassen), die man mit geschickten Defaults bequem von außen aufrufen kann, dann kann es schon mal passieren, dass man eine Methode fünfmal oder noch häufiger überlädt, um alle Varianten verfügbar zu machen. In Kotlin genügt eine. Parameter können mit Namen aufgerufen werden, Defaults werden bei der Deklaration der Methode mit definiert. Fertig.

Es gibt eine Reihe weiterer Sprachfeatures, die über das hinausgehen, was Java kann: Data Classes, Mix-in-Methoden, Delegates für Getter und Setter und viele mehr. Man kann gut ohne sie programmieren, wenn man sie aber kennt, kürzen sie vieles ab.

Kotlin mag Java

Der Kotlin-Compiler baut seinen Bytecode für die JVM. Das ist clever, denn so lassen sich alle in Java gebauten Komponenten aus Kotlin heraus verwenden – eine Art Generationenvertrag. Damit lassen sich zum Beispiel JEE-Anwendungen für Wildfly in Kotlin entwickeln. Für Container gibt es allerdings ein paar Einschränkungen, die zwar überwindbar, aber zu beachten sind. Doch auch hier lohnt sich der Umstieg.

Bei der Entwicklung von Android-Apps ist es gang und gäbe, Bibliotheken derartig zu mixen. Man kann sogar Java- und Kotlin-Klassen im selben Quellcode-Baum haben, ohne es wirklich zu merken. Den Java-Code zu erhalten ist im Allgemeinen aber auch nicht nötig: AndroidStudio (das auf IntelliJ IDEA basiert) ermöglicht es, per Knopfdruck Java-Code nach Kotlin zu wandeln. Das funktioniert zu etwa 99 Prozent, den Rest muss man nacharbeiten. Meistens ist es die Arbeit wert.

In russischer Hand

Der Wechsel von Java nach Kotlin ist der Wechsel von einer großen Insel im Süden zu einer kleinen im Norden. Der Namensgeber für Kotlin ist eine Insel in der Bucht vor dem schillernd-schönen Sankt Petersburg. Dort hat die tschechische Firma JetBrains, die die Sprache entwickelt hat und auch weiter pflegt, einen Standort. Es ist denn auch JetBrains‘ Entwicklungsumgebung IntelliJ IDEA, die die Arbeit mit der Sprache am besten unterstützt. Zumindest haben sich Versuche mit Eclipse und dem Kotlin-Plugin in der Version 0.8 als nicht praktikabel erwiesen. Die Entwicklung am NetBeans-Plugin wurde 2017 eingestellt.

Alles rund um Kotlin scheint Open Source zu sein. Es gibt eine Unmenge von GitHub-Projekten von JetBrains dazu, die meist unter der Apache 2 License veröffentlicht sind. Natürlich bleibt dennoch die Gefahr, mit der Sprache auch von den Umgebungen des Herstellers JetBrains abhängig zu sein.

Ausblick

Wenn es nach JetBrains geht, wird man Kotlin zukünftig nicht nur auf Android und im bisherigen Java-Umfeld einsetzen, sondern auch auf iOS (!), im Browser und in anderen Umgebungen. Das Ganze läuft unter dem Begriff „Kotlin Native“ und klingt ambitioniert. Sollte dies gelingen, ergäben sich neue Möglichkeiten, Code-Teile auf verschiedenen Plattformen gemeinsam zu benutzen. Aber natürlich verliert man „native“ vollständig die Bindung zu existierenden Java-Klassen. Wir werden beobachten, wie sich die Sache entwickelt.

Zusammenfassung

Die Lernkurve beim Umstieg von Java auf Kotlin ist steil, aber der Umstieg fühlt sich natürlich an. Die Grundkonstrukte lassen sich weitgehend übertragen, Neues lernt man nach und nach. Kotlin-Code ist prägnanter und kompakter als der von Java. Die Bytecode-Kompatibilität ermöglicht auch in der Laufzeitumgebung einen sanften Umstieg.

I love it.

P.S.: Wer Kotlin einfach mal ausprobieren möchte, kann das online tun. Man findet dort eine kleine Entwicklungsumgebung, in der man mit den Sprachelementen herumspielen kann.

Autor:
Thomas Nordmeyer
Senior Consultant

Bildrechte: (c) Mediaan Pieter Otten, (c) devteam space

Zurück