Spring Boot 2.0: Neuerungen und Migrationstipps

Spring Boot 2.0 ist da -- und es ändert sich einiges

Am 1. März 2018 hat Pivotal nach über einem Jahr Entwicklungszeit Spring Boot 2.0 veröffentlicht. Das Major-Release baut auf Spring Framework 5.0 auf und bringt grundlegende Änderungen mit, die sich auf nahezu jeden Aspekt der Entwicklung auswirken. Wir haben die letzten Wochen damit verbracht, mehrere unserer Services zu evaluieren und erste Migrationen durchzuführen. Hier ist unsere Zusammenfassung der wichtigsten Neuerungen -- und der Stolperfallen, die man kennen sollte.

Spring Framework 5 als Fundament

Die vielleicht bedeutendste Änderung ist die zugrunde liegende Plattform. Spring Boot 2.0 setzt auf Spring Framework 5.0, und das hat weitreichende Konsequenzen: Java 8 ist jetzt die Mindestanforderung. Wer noch auf Java 7 unterwegs ist, muss zuerst die Runtime aktualisieren. Gleichzeitig bringt Spring Framework 5 offizielle Unterstützung für Java 9 mit -- ein Thema, das angesichts der neuen Release-Kadenz von Oracle zunehmend relevant wird.

Die gesamte Codebasis nutzt nun Java-8-Features wie Lambdas, Streams und die java.time-API. Das klingt selbstverständlich, bedeutet in der Praxis aber, dass veraltete APIs konsequent abgelöst wurden. Wer eigene Konfigurationen oder Erweiterungen geschrieben hat, die auf den alten APIs aufbauen, muss diese anpassen.

WebFlux: Reaktive Programmierung im Spring-Ökosystem

Das Flaggschiff-Feature von Spring Boot 2.0 ist zweifellos WebFlux -- das neue reaktive Web-Framework. Neben dem klassischen Spring MVC existiert jetzt ein vollständig nicht-blockierender Stack, der auf Project Reactor aufbaut und mit Netty als Standard-Server läuft.

Ein einfacher reaktiver Controller sieht so aus:

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductRepository repository;

    public ProductController(ProductRepository repository) {
        this.repository = repository;
    }

    @GetMapping("/{id}")
    public Mono<ResponseEntity<Product>> getProduct(@PathVariable String id) {
        return repository.findById(id)
                .map(ResponseEntity::ok)
                .defaultIfEmpty(ResponseEntity.notFound().build());
    }

    @GetMapping
    public Flux<Product> getAllProducts() {
        return repository.findAll();
    }
}

Statt ein einzelnes Objekt zurückzugeben, arbeitet man mit Mono<T> (null oder ein Element) und Flux<T> (null bis n Elemente). Der Server blockiert keinen Thread, während auf Datenbank-Ergebnisse gewartet wird -- bei hoher Last ein entscheidender Vorteil.

Allerdings sei hier ein wichtiger Hinweis erlaubt: WebFlux ist kein Ersatz für Spring MVC. Wer klassische JDBC-basierte Anwendungen baut, profitiert kaum davon, weil JDBC selbst blockierend ist. Erst mit reaktiven Datenbanktreibern -- etwa für MongoDB mit dem Reactive Streams Driver oder mit R2DBC für relationale Datenbanken, das sich allerdings noch in einem frühen Stadium befindet -- entfaltet der reaktive Stack sein volles Potenzial. Für die meisten unserer bestehenden Services bleibt Spring MVC daher vorerst die richtige Wahl.

Actuator: Komplett überarbeitet

Der Spring Boot Actuator hat eine grundlegende Überarbeitung erfahren. Die Änderungen sind so umfangreich, dass sie bei der Migration den meisten Aufwand verursachen dürften.

Die wichtigsten Neuerungen im Überblick:

Neues Endpunkt-Modell: Alle Actuator-Endpunkte sind standardmäßig unter /actuator gruppiert. Der Health-Endpunkt ist also nicht mehr unter /health, sondern unter /actuator/health erreichbar.
Sicherheit als Default: Nur /actuator/health und /actuator/info sind standardmäßig über HTTP exponiert. Alle anderen Endpunkte müssen explizit freigeschaltet werden.
Technologieunabhängig: Endpunkte funktionieren sowohl mit Spring MVC als auch mit WebFlux -- die gleiche Implementierung bedient beide Stacks.

Die Konfiguration erfolgt jetzt deutlich granularer über die application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics, prometheus
  endpoint:
    health:
      show-details: when-authorized
  server:
    port: 9090

Wer bisher eigene Actuator-Endpunkte implementiert hat, muss diese auf das neue @Endpoint-Modell migrieren. Der Aufwand ist überschaubar, aber man sollte ihn einplanen.

Micrometer: Endlich ein vernünftiges Metrik-Framework

Spring Boot 1.x hatte ein eigenes, eher rudimentäres Metrik-System. In 2.0 wird dieses durch Micrometer ersetzt -- eine Art SLF4J für Metriken. Micrometer abstrahiert die Metrik-Sammlung und unterstützt eine breite Palette von Monitoring-Systemen: Prometheus, Datadog, InfluxDB, Graphite und viele mehr.

In der Praxis bedeutet das: Man bindet micrometer-registry-prometheus ein, konfiguriert den Actuator-Endpunkt, und hat sofort JVM-Metriken, HTTP-Request-Statistiken und eigene Business-Metriken im Prometheus-Format. Für unsere Kubernetes-Deployments, in denen wir ohnehin Prometheus einsetzen, ist das ein enormer Gewinn -- kein manuelles Instrumentieren mehr, keine Drittanbieter-Bibliotheken, die man selbst verdrahten muss.

Kotlin-Unterstützung

Spring Framework 5 und damit Spring Boot 2.0 bieten erstklassige Kotlin-Unterstützung. Das reicht von Null-Safety-Annotationen über Extensions bis hin zu dedizierten DSLs für Bean-Definition und Routing. Wer Kotlin als Sprache evaluiert oder bereits einsetzt, findet hier ein deutlich ausgereifteres Zusammenspiel als in der 1.x-Linie.

Besonders die Kotlin-DSL für das funktionale Routing in WebFlux ist elegant -- aber das ist ein Thema für einen eigenen Artikel.

Gradle-Plugin: Neu geschrieben

Das Gradle-Plugin für Spring Boot wurde von Grund auf neu geschrieben und erfordert jetzt Gradle 4.0 oder neuer. Wer noch Gradle 3.x einsetzt, muss zuerst Gradle aktualisieren. Das neue Plugin ist mächtiger und flexibler, bringt aber auch Breaking Changes mit: Die Task-Namen haben sich teilweise geändert, und die Konfiguration des Fat-JARs funktioniert anders als zuvor.

Migration von 1.5: Was zu beachten ist

Wir haben mittlerweile drei Services von Spring Boot 1.5 auf 2.0 migriert und dabei einige wiederkehrende Themen identifiziert.

Property-Umbenennungen: Zahlreiche Konfigurationseigenschaften wurden umbenannt. server.context-path heißt jetzt server.servlet.context-path, spring.http.multipart wurde zu spring.servlet.multipart. Spring bietet mit dem spring-boot-properties-migrator ein Modul an, das veraltete Properties zur Laufzeit erkennt und Warnungen loggt. Wir empfehlen, dieses Modul temporär einzubinden, um alle betroffenen Stellen zu finden.

Spring Security: Die Auto-Configuration für Spring Security hat sich grundlegend geändert. Das bisherige Verhalten, bei dem standardmäßig alles abgesichert wurde und man Ausnahmen definierte, ist nicht mehr gegeben. Stattdessen muss man eine eigene SecurityFilterChain-Konfiguration bereitstellen. Das erzwingt explizitere Sicherheitskonfigurationen -- letztlich eine gute Sache, aber bei der Migration ein Punkt, den man nicht übersehen sollte.

Dependency-Versionen: Mit Spring Boot 2.0 werden viele Drittanbieter-Bibliotheken auf neuere Versionen angehoben. Hibernate 5.2, Tomcat 8.5, Jackson 2.9 -- wer spezifische Versionen gepinnt hat, sollte Kompatibilität prüfen.

Entfernte Klassen und Methoden: Einige in 1.5 als @Deprecated markierte APIs wurden in 2.0 entfernt. Wer Compiler-Warnungen in 1.5 ignoriert hat, bekommt jetzt Compile-Fehler. Unser Tipp: Zuerst auf die aktuellste 1.5.x-Version gehen, alle Deprecation-Warnungen beheben und dann auf 2.0 wechseln.

Unser Fazit nach den ersten Wochen

Spring Boot 2.0 ist ein solides Major-Release. Die reaktiven Möglichkeiten mit WebFlux sind beeindruckend, auch wenn sie für die meisten klassischen Webanwendungen noch kein zwingender Grund für eine Migration sind. Die überarbeiteten Actuator-Endpunkte und die Micrometer-Integration hingegen sind für jeden relevant, der seine Services in Produktion betreibt -- und allein dafür lohnt sich der Umstieg.

Die Migration von 1.5 ist kein Selbstläufer und sollte nicht unterschätzt werden. Zwei bis drei Tage pro Service sind realistisch, abhängig von der Komplexität und der Anzahl der genutzten Spring-Boot-Features. Unser Rat: Nicht alle Services auf einmal migrieren, sondern mit einem unkritischen Service anfangen, Erfahrung sammeln und dann schrittweise vorgehen.

Spring Boot 1.5 wird noch bis August 2019 unterstützt. Zeit ist also vorhanden -- aber man sollte die Migration nicht auf die lange Bank schieben.