Kotlin: Are you ready for business?

Im Frontend sind wir es gewohnt, dass immer wieder neue, hippe, trendige Sprachen und Frameworks aufkommen. Der Backend-Bereich dagegen wird von den Platzhirschen Java und .net dominiert. Da es bereits große Installationen gibt, ist es sinnvoll und wirtschaftlich, auch neue Projekte in der gleichen Sprache zu schreiben. Mit dem Microservice-Ansatz ist es nun erstmals möglich, jeden Service sauber getrennt in einer eigenen Sprache zu implementieren. Natürlich möchte man innerhalb eines Unternehmens das Set an eingesetzten Technologien beherrschbar halten, weswegen von dieser Möglichkeit nur bedingt gebraucht gemacht wird. Mit Kotlin gibt es seit ein paar Jahren nun einen sehr interessanten, neuen Kandidaten für das Backend.

Auf elegante Weise hat es der Hersteller und Sponsor JetBrains geschafft, eine Sprache mit neuen und modernen Konstrukten und Philosophien zu schaffen, die auf der etablierten Java Virtual Machine läuft. Damit bietet es genügend Neuerung, die Entwickler begeistern können, ohne gleich alle Tools und Investitionen auf den Kopf zu stellen.

Das Zusammenspiel von Kotlin und Java ist jetzt schon sehr gut. Die Tatsache, dass Spring 5 Kotlin vollständig unterstützt, dürfte dem Ganzen nochmal entsprechend Aufwind geben. Im Thoughtworks Technology Radar steht Kotlin auf Asses, also eine Empfehlung zur näheren Betrachtung. Und seit Kotlin auf der Google I/O zur offiziellen Sprache für Android erklärt wurde, ist klar, dass Kotlin bereit für den produktiven Einsatz ist.

Zeit, Kotlin auf Alltagstauglichkeit für kritische Unternehmenssoftware zu prüfen.

Was zeichnet Kotlin aus?

Ein Vorteil von etablierten Sprachen ist es, dass sich um die Sprache herum schon eine Vielzahl an Tools und Werkzeugen gebildet hat, auf die man als Entwickler zurückgreifen kann. Kotlin stammt aus dem Hause JetBrains, die eine mächtige und beliebte Java IDE herstellen, und Kotlin dort auch direkt integriert haben. Wer also mit IntelliJ arbeitet, kann sofort mit Kotlin arbeiten. Außerdem gibt es für die populären Build Tools Maven und Gradle Kotlin-Unterstützung, so dass sich am Build Prozess im Vergleich zu Java nichts ändert.

Der Einstieg in Kotlin ist denkbar einfach. Dabei fallen ein paar Punkte sofort auf: 

Wir schreiben weniger Boilerplate Code

Kotlin kommt wesentlich kompakter daher als Java: Datenklassen bieten einfache Properties, so dass man auf die in Java üblichen setter/getter verzichten kann. Das spart viel Tipparbeit und hält die Klassen klein.

Dazu kommt, dass man bei Konstruktoren benannte Parameter und Defaults angeben kann. In der Regel kommt man also mit einer Konstruktor-Definition aus, wo man in Java diverse Varianten implementiert hat. Außerdem muss man später nur die Daten angeben, die man tatsächlich verwendet.

Code-Checks sind schlanker

Smart Casts in Kotlin machen den Code ebenfalls schlanker und weniger fehleranfällig, denn sie nehmen uns zwei typische Checks ab: Wenn ein Typcheck erfolgreich war, wird die Variable automatisch im folgenden Block auf den Typ gecastet und Kotlin kann garantieren, dass die Variable nicht null ist. Die Variable kann also, anders als in Java, direkt und sicher verwendet werden. Explizite Casts oder Nullchecks sind nicht mehr erforderlich.  

Komfortabel sind auch die String Templates in Kotlin. Anstelle von String-Konkatenationen, die in Java schnell unübersichtlich werden, können in Kotlin-Variablen direkt im String angegeben werden. Intern übersetzt Kotlin dieses Konstrukt in einen performanten StringBuilder.

In Java muss der Entwickler viele Konstrukte und Code-Stellen immer und immer wieder schreiben, die genauso gut durch die Sprache oder den Compiler erzeugt werden können. Kotlin folgt einem pragmatischeren Ansatz und hält den Entwickler nicht mit solchen Details auf: Es arbeitet mit sinnvollen Standard-Implementierungen für Konstrukte, die in den allermeisten Fällen ausreichen.

Die Standard-Implementierungen sind Java-konform, so dass man Kotlin und Java parallel im Projekt verwenden kann. 

Kompakterer Code macht viele Entwickler glücklich. …wenn man mit den Pitfalls leben kann. 

Pitfalls

Tools für Arbeit im Team fehlen noch

Die Inspection für Kotlin im hauseigenen IntelliJ ist zwar schon sehr gut. Was für größere Projekt noch fehlt, ist das zentrale Dashboard für ein Team. Der Platzhirsch hier ist SonarQube. Die statischen Code-Analysen sorgen dafür, dass der im Projekt festgelegte Qualitätsanspruch kontinuierlich und zentral für alle Entwickler überprüft wird. Für Kotlin gibt es dafür bisher noch keine Unterstützung.

Java Interoperabilität hebelt Kotlin-Konzepte teilweise aus

In einer idealen Welt könnte man sich dem Kotlin-Ansatz in einem reinen Kotlin-Projekt widmen. Zumindest in der Business-IT werden wir immer Schnittstellen zur Java-Welt haben. Um beide Welten in einem Projekt zusammenzubringen, muss man sich ein bisschen verbiegen.

Zwei Beispiele: Persistenz und Annotationen.

Wenn es um Persistenz geht, führt fast kein Weg an Hibernate als Defacto-Standard für JPA vorbei. Hier brauchen wir zwingend einen No-Arguments-Konstruktor – und das widerspricht dem Kotlin-Ansatz, für alle Parameter konkrete Werte zu verlangen. Um Kotlin und Hibernate gemeinsam zu betreiben, gibt es deswegen das No-Arg-Plugin. Leider geben wir damit auch einen der großen Vorzüge von Kotlin wieder auf.

Annotationen, die an die Getter oder Setter oder direkt an die Felder geschrieben werden, können in Kotlin nicht ohne Weiteres verwendet werden. Der Zugriff erfolgt hier bevorzugt über properties. Deswegen erweitert Kotlin die Syntax für Annotationen und erlaubt es, den Anker für Annotationen per Prefix festzulegen.

Alltagstauglich? Absolut!

Trotz der (noch bestehenden) Nachteile: Kotlin ist für mich absolut alltagstauglich!

Die Sprache begeistert schnell: Sie ist ein modern und kompakt, ihre Konzepte in sich stimmig, und sie belohnt schnell mit Erfolgen in einer flachen Lernkurve. Die an anderer Stelle erwähnte “developer happiness” können wir nach ersten Projekten absolut bescheinigen.

Im Moment kann die Konfrontation mit der Java-Welt die Kotlin-Magie noch entzaubern. Plötzlich muss man einen Blick unter die Haube wagen – sprich: in den decompilierten Bytecode –, um zum Beispiel zu verstehen, wo Kotlin Annotationen verankert. Außerdem schränken die Verrenkungen, die im Java-Umfeld noch notwendig sind, einige zeitgemäße Konzepte in Kotlin wieder ein.

Aber: Meine Prognose ist, dass wir bald weniger Verrenkungen machen müssen. Dafür spricht, wie schnell etablierte Player – siehe Google oder Spring/Pivotal – Kotlin den Ritterschlag gegeben haben.

Und: Ich halte Kotlin nicht nur für alltags sondern auch zukunftstauglich! Im Unterschied zu anderen Herausforderern in der Backend-Entwicklung gibt es seit Stunde Null exzellente Tool-Unterstützung. Und es ist kompatibel mit Java-Welt: Wir können das komplette Java-Ökosystem weiter nutzen.

Wie sind Ihre Erfahrungen mit Kotlin? Schreiben Sie mir, entweder über einen Kommentar oder per E-Mail. 

---

Über den Autor

Philippe Schrettenbrunner, stellvertretender Bereichsleiter Cybersecurity, ist seit 2005 bei MaibornWolff. Als Techie durch und durch, bildet für ihn Qualität die Grundlage des Handelns. Sein Fokus liegt hierbei auf dem Backend. Philippe ist Diplom-Informatiker und hat zudem einen Master of Engineering in Computer Science. In seiner Freizeit ist er Portraitfotograf. 

LinkedIn: https://www.linkedin.com/in/philippe-schrettenbrunner-5a8a87225/