Kotlin als Sprache für das Spring-Ökosystem

2017 war ein bemerkenswertes Jahr für Kotlin. Im Mai hat Google auf der I/O die Sprache als offiziell unterstützte Entwicklungssprache für Android vorgestellt, im September ist Spring Framework 5.0 mit dediziertem Kotlin-Support erschienen, und vor wenigen Wochen wurde Kotlin 1.2 veröffentlicht. Für uns als Java- und Spring-Entwickler stellt sich damit eine naheliegende Frage: Lohnt sich der Blick auf Kotlin auch abseits der Android-Welt?

Warum Kotlin für Spring-Entwickler interessant ist

Kotlin ist eine statisch typisierte Programmiersprache, die von JetBrains entwickelt wird und vollständig auf der JVM läuft. Der entscheidende Punkt für bestehende Java-Projekte: Kotlin ist zu 100 Prozent interoperabel mit Java. Das bedeutet, man kann Kotlin-Code in ein bestehendes Java-Projekt einführen, ohne alles neu schreiben zu müssen. Bestehende Java-Bibliotheken, Spring-Annotationen und das gesamte Ökosystem funktionieren nahtlos weiter.

Die Sprache wurde mit dem Ziel entworfen, die bekannten Schwachstellen von Java zu beheben -- ohne dabei die Laufzeitperformance zu opfern. Im Alltag zeigt sich das vor allem an drei Stellen: Null Safety, deutlich weniger Boilerplate-Code und ausdrucksstärkere Sprachkonstrukte.

Null Safety: Schluss mit der NullPointerException

Einer der grössten Vorteile von Kotlin ist das Typsystem, das zwischen nullable und non-nullable Typen unterscheidet. In Java ist jede Objektreferenz potenziell null, was seit Jahrzehnten zu den berüchtigten NullPointerException-Fehlern führt. Kotlin löst dieses Problem auf Sprachebene.

Ein Typ ist in Kotlin standardmässig nicht-nullable. Wer null explizit zulassen möchte, muss den Typ mit einem Fragezeichen markieren:

var name: String = "Kotlin"    // Kann nicht null sein
var title: String? = null      // Nullable, explizit markiert

// Sicherer Zugriff mit dem ?.-Operator
val length = title?.length     // Gibt null zurück statt NPE

Der Compiler erzwingt, dass nullable Typen vor dem Zugriff geprüft werden. Das eliminiert eine ganze Fehlerklasse bereits zur Compile-Zeit -- ein enormer Gewinn für die Code-Qualität.

Data Classes: Weniger Boilerplate, mehr Klarheit

Ein klassisches Beispiel für den Unterschied in der Ausdrucksstärke sind Datenklassen. In Java-Projekten mit Spring kennt man die typischen DTOs und Entities mit Gettern, Settern, equals(), hashCode() und toString(). Der Vergleich spricht für sich.

Java:

@Entity
public class Customer {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String firstName;
    private String lastName;
    private String email;

    public Customer() {}

    public Customer(Long id, String firstName, String lastName, String email) {
        this.id = id;
        this.firstName = firstName;
        this.lastName = lastName;
        this.email = email;
    }

    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getFirstName() { return firstName; }
    public void setFirstName(String firstName) { this.firstName = firstName; }
    public String getLastName() { return lastName; }
    public void setLastName(String lastName) { this.lastName = lastName; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    @Override
    public boolean equals(Object o) { /* ... */ }

    @Override
    public int hashCode() { /* ... */ }

    @Override
    public String toString() { /* ... */ }
}

Kotlin:

@Entity
data class Customer(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,
    val firstName: String,
    val lastName: String,
    val email: String
)

Das Kotlin-Beispiel generiert automatisch equals(), hashCode(), toString() und eine copy()-Funktion. Aus rund 40 Zeilen Java werden 7 Zeilen Kotlin -- bei identischer Funktionalität. Das ist kein Spielzeug-Beispiel: In einem typischen Spring-Projekt mit Dutzenden von DTOs summiert sich dieser Unterschied erheblich.

Extension Functions und Spring

Extension Functions erlauben es, bestehende Klassen um neue Methoden zu erweitern, ohne sie zu verändern oder von ihnen zu erben. Das passt hervorragend zum Spring-Ökosystem, in dem man häufig mit Framework-Klassen arbeitet, die man nicht selbst kontrolliert.

// Eine Extension Function für RestTemplate
fun RestTemplate.getForEntity(url: String): ResponseEntity<String> =
    this.getForEntity(url, String::class.java)

// Nutzung
val response = restTemplate.getForEntity("https://api.example.com/data")

Spring Framework 5.0 nutzt dieses Konzept selbst und liefert Kotlin Extensions mit, etwa für RestOperations, BeanDefinitionDsl oder die neue funktionale Router-DSL für WebFlux.

Spring Framework 5.0 und Kotlin-Support

Mit Spring Framework 5.0, das im September 2017 erschienen ist, hat Pivotal deutlich in Kotlin investiert. Die wichtigsten Neuerungen:

• Null Safety im gesamten API: Spring 5.0 ist vollständig mit Null-Safety-Annotationen versehen, die Kotlin versteht und zur Compile-Zeit auswertet.
• Kotlin Extensions: Offizielle Extension Functions für zentrale Spring-APIs reduzieren Boilerplate und machen den Code idiomatischer.
• Funktionale Bean-Registrierung: Mit der BeanDefinitionDsl lassen sich Beans in einem typensicheren DSL registrieren -- ohne XML und ohne Reflection.
• WebFlux Router DSL: Für reaktive Web-Anwendungen bietet Spring eine Kotlin-DSL, die das Routing funktional und ausdrucksstark definiert.

Auch Spring Boot 2.0, das sich derzeit in der Milestone-Phase befindet, wird Kotlin als erstklassig unterstützte Sprache behandeln. Der Spring Initializr unter start.spring.io bietet bereits jetzt die Option, ein Projekt direkt mit Kotlin zu generieren.

Ein Blick auf Coroutines

Kotlin 1.1 hat mit Coroutines ein Konzept eingeführt, das asynchrone Programmierung deutlich vereinfacht. Statt verschachtelter Callbacks oder komplexer Reactive-Streams-Ketten lässt sich asynchroner Code sequenziell schreiben. In Kotlin 1.2 sind Coroutines weiterhin als experimentelles Feature markiert, zeigen aber bereits grosses Potenzial.

Für das Spring-Ökosystem ist das besonders relevant, weil Spring 5.0 mit WebFlux stark auf reaktive Programmierung setzt. In Zukunft könnten Coroutines eine elegantere Alternative zu Mono und Flux bieten, um nicht-blockierenden Code zu schreiben, der trotzdem lesbar bleibt. Hier ist die Entwicklung noch am Anfang, aber die Richtung stimmt.

Wo stehen wir heute?

Bei aller Begeisterung für die Sprache sollte man ehrlich bleiben: Kotlin im Backend ist noch ein vergleichsweise junges Thema. Die meisten Spring-Projekte in Produktion laufen auf Java, die Tooling-Unterstützung ist in IntelliJ IDEA zwar hervorragend, in anderen IDEs aber noch ausbaufähig. Auch die Dokumentation und Community-Ressourcen für Kotlin im Spring-Kontext sind noch nicht so umfangreich wie für Java.

Einige Punkte, die man bedenken sollte:

• Lernkurve: Für erfahrene Java-Entwickler ist der Einstieg in Kotlin relativ schnell. Die Syntax ist aber anders genug, dass man sich bewusst Zeit nehmen sollte.
• Teamgrösse und Onboarding: In grösseren Teams muss sichergestellt sein, dass alle Entwickler mit Kotlin vertraut sind. Ein Mix aus Java und Kotlin im selben Projekt ist technisch möglich, erhöht aber die Komplexität.
• Compile-Zeiten: Der Kotlin-Compiler ist aktuell noch etwas langsamer als der Java-Compiler. Bei grossen Projekten kann das spürbar sein.
• Bibliotheken und Frameworks: Die Java-Interoperabilität funktioniert sehr gut, gelegentlich stösst man aber auf Randfälle, etwa bei Annotation Processing oder bestimmten Reflection-Mustern.

Fazit

Kotlin ist eine ausgereifte, pragmatische Sprache, die viele Schwächen von Java adressiert, ohne das bewährte Ökosystem aufzugeben. Mit dem dedizierten Support in Spring Framework 5.0 und dem kommenden Spring Boot 2.0 ist die Grundlage für den produktiven Einsatz im Backend gelegt.

Für neue Projekte lohnt es sich, Kotlin ernsthaft in Betracht zu ziehen. Für bestehende Java-Projekte bietet die Interoperabilität die Möglichkeit, Kotlin schrittweise einzuführen -- etwa in neuen Modulen oder Services.

Wir bei encircle360 werden Kotlin in den kommenden Monaten in ausgewählten Projekten einsetzen und unsere Erfahrungen hier im Blog teilen. Die Sprache hat das Potenzial, die Art, wie wir Spring-Anwendungen entwickeln, nachhaltig zu verändern.