Sie ist in aller Munde: Die Programmiersprache Kotlin aus dem Hause JetBrains. In diesem Artikel möchte ich darauf eingehen, ob sie sich im Projektalltag aus meiner Sicht bewähren könnte oder nicht. Feedback ist willkommen!
Als Java-Entwickler bin ich schon vor Jahren auf Kotlin gestoßen und hatte im ersten Moment Erinnerungen an Scala. Im Jahr 2010 hatte mein damaliger Teamleiter von Scala nur so geschwärmt. Zu der Zeit war Java in der Version 6 gängig, die noch keine Aspekte funktionaler Programmierung kannte. Scala bot tatsächlich einige Vorteile, sodass wir damals Scala als Java-Nachfolger vermuteten. Heute leben beide Sprachen in friedlicher Koexistenz. Allerdings beherrscht Java seit der Version 8 funktionale Aspekte und ist somit weiter als die damalige Version 6.
Die Programmiersprache hinter der Java-Technologie weist 50 Schlüsselwörter in der Version 8 auf, die man als Java-Entwickler kennen und ihren richtigen Einsatz verstehen sollte. Andere Programmiersprachen wie Ruby, JavaScript, Python und C liegen zahlenmäßig darunter. Nimmt man diese Metrik als Maßstab, was natürlich vermessen ist, so hat Kotlin mit seinen 28 Schlüsselwörtern schonmal ein kleineres Vokabular. Das ist natürlich nicht der einzige Grund für die Wahl einer Programmiersprache, soll aber zumindest verdeutlichen, dass eine Programmiersprache weniger umfangreich gestaltet sein kann. Doch welche Herausforderungen löst Kotlin besser als Java? Und was heißt eigentlich besser?
Kotlin wurde 2010 von JetBrains ins Leben gerufen und ist damit eine relativ neue statisch-typisierte Programmiersprache. Sie kombiniert objektorientierte und funktionale Bestandteile, die nicht zum Java-Sprachumfang gehören. Den Datentyp ermittelt Kotlin anhand der Inferenz, d.h. sie leitet sie aus dem Kontext ab. Das kann Java seit der Version 10 bei lokalen Variablen, aber (noch) nicht im großen Stil. Die erweiterten Sprachfeatures sind auch der Grund, warum Teams von Java zu Kotlin wechseln. Im Gegensatz zu Java unterscheidet Kotlins Typsystem zwischen Referenzen, die null enthalten können und welchen, die null nicht enthalten können:
var someVar: String
someVar = null // -> Kann nicht kompiliert werden
var someVar: String?
someVar = null // -> Kann kompiliert werdenUm das zu garantieren, hat Kotlin im Gegensatz zu Java keine primitiven Datentypen, wie z.B. byte, short, int, long, char, float, double und boolean. Arrays werden durch eine eigene Klasse repräsentiert, die über entsprechende Zugriffsmethoden verfügt. Zudem verfügt die Sprache über Funktionstypen, wie z.B. (Int) -> String. In ihr gibt es im Gegensatz zu Java keine Checked Exceptions. Es gibt viele weitere Features, die sie bietet und Java nicht. Allesamt erinnern sie ein wenig an andere Sprachen wie z.B. TypeScript.
Der Kotlin-Compiler produziert Java Bytecode, der von einer Java Virtual Machine ausgeführt werden kann. Außerdem können native MacOS-, Windows- und JavaScript-Applikationen entwickelt werden. Insbesondere als Sprache für Android-Applikationen eignet sich Kotlin aufgrund seiner Kompatibilität, Leistungsfähigkeit, Interoperabilität und Größe seiner Laufzeitbibliothek. Erst in 2016 wurde die Version 1.0 veröffentlicht. Der Kotlin-Compiler reift zwar stetig, stürzt aber bei komplexerem Quellcode ab und zu ab und enthält Bugs. Seine Entwicklung geht im Vergleich zu anderen Sprachen rapide voran und die Community wächst weiter. Kotlin adressiert Java-Entwickler und präferiert IntelliJ als Entwicklungsumgebung. Für mich zeigt das auch ein kommerzielles Interesse des Herstellers JetBrains.
Die Migration von Java zu Kotlin geht relativ schnell. Oft lässt sich mit einem Commit eine Java-Anwendung komplett zu Kotlin migrieren. Es existieren Konvertierungstools, die allerdings oft eine manuelle Nachkorrektur erfordern. Es ist ebenfalls möglich, Java-Code und Kotlin-Code parallel innerhalb einer Anwendung zu betreiben.
Meine persönliche Meinung ist, dass Kotlin durch seine einfachere Lesbarkeit, seine große Community und seine gute Kompatibilität und Toolunterstützung ein guter Kandidat für eine zukunftssichere Ablösung von Java ist. Einzig und allein der instabile Compiler schreckt mich derzeit noch ab.