Java 17 LTS: Die wichtigsten Neuerungen im Überblick

Am 14. September hat Oracle Java 17 veröffentlicht -- und für viele Java-Entwickler ist das der Release, auf den sie seit drei Jahren gewartet haben. Java 17 ist das nächste Long-Term-Support-Release nach Java 11, das wir damals in unserem Java-11-Artikel ausführlich vorgestellt haben. Für Teams, die auf LTS-Versionen setzen und die Zwischenreleases 12 bis 16 übersprungen haben, lohnt sich ein genauer Blick auf die gesammelten Neuerungen.

Drei Jahre, sechs Releases

Seit Java 9 erscheint alle sechs Monate eine neue Java-Version -- das hatten wir bereits in unserem Artikel zum Java-9-Modulsystem erläutert. Zwischen Java 11 (September 2018) und Java 17 (September 2021) liegen damit sechs Zwischenreleases. Jedes davon brachte neue Features, die in der Community oft unter dem Radar blieben, weil viele Projekte auf LTS-Versionen verharren.

Das ist verständlich -- niemand möchte in Produktion auf einer Version laufen, die nach sechs Monaten keine Sicherheitsupdates mehr bekommt. Doch es bedeutet auch, dass Java 17 nicht nur die Features aus JDK 17 selbst mitbringt, sondern die kumulierten Neuerungen aus den Versionen 12 bis 17. Und die haben es in sich.

Sealed Classes: Kontrollierte Vererbung

Sealed Classes sind eines der Highlights, das über mehrere Releases hinweg gereift ist (JEP 360, 375, 409) und in Java 17 seinen finalen Status erreicht hat. Die Idee ist einfach, aber mächtig: Eine Klasse oder ein Interface kann explizit festlegen, welche Klassen sie erweitern oder implementieren dürfen.

public sealed interface Shape
        permits Circle, Rectangle, Triangle {
    double area();
}

public final class Circle implements Shape {
    private final double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}

public final class Rectangle implements Shape {
    private final double width, height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double area() {
        return width * height;
    }
}

public non-sealed class Triangle implements Shape {
    // non-sealed erlaubt weitere Unterklassen
    private final double base, height;

    public Triangle(double base, double height) {
        this.base = base;
        this.height = height;
    }

    @Override
    public double area() {
        return 0.5 * base * height;
    }
}

Das Schlüsselwort sealed in Kombination mit permits schränkt die Vererbungshierarchie ein. Jede Unterklasse muss sich als final, sealed oder non-sealed deklarieren. Damit kann der Compiler prüfen, ob alle möglichen Subtypen abgedeckt sind -- eine Eigenschaft, die besonders in Kombination mit Pattern Matching in switch-Ausdrücken ihre Stärke zeigen wird.

Für die Modellierung von Domänentypen ist das Gold wert. Statt einer offenen Klassenhierarchie, bei der theoretisch jede Klasse im Classpath eine Unterklasse bilden kann, definiert man präzise, welche Varianten es gibt. Wer mit algebraischen Datentypen aus Sprachen wie Kotlin, Scala oder Haskell vertraut ist, erkennt das Muster sofort.

Pattern Matching für instanceof

Das zweite große Feature, das in Java 17 seinen finalen Status erreicht (JEP 394, nach Previews in Java 14 und 15), eliminiert ein Stück Boilerplate, das Java-Entwickler seit Jahrzehnten begleitet:

// Vorher: klassisches instanceof mit explizitem Cast
if (obj instanceof String) {
    String s = (String) obj;
    System.out.println(s.length());
}

// Nachher: Pattern Matching -- Typ und Variable in einem Schritt
if (obj instanceof String s) {
    System.out.println(s.length());
}

Die Variable s ist direkt im if-Block verfügbar, korrekt typisiert und ohne redundanten Cast. Das funktioniert auch mit logischen Operatoren:

if (obj instanceof String s && s.length() > 5) {
    System.out.println("Langer String: " + s);
}

Das mag auf den ersten Blick wie eine kleine Verbesserung wirken. In der Praxis -- besonders in Visitor-Patterns, Event-Handlern oder Deserialisierungslogik -- entfällt damit eine Menge repetitiver Code.

Pattern Matching für switch (Preview)

Als Preview-Feature liefert Java 17 mit JEP 406 eine noch mächtigere Erweiterung: Pattern Matching in switch-Ausdrücken. In Kombination mit Sealed Classes ergibt sich ein kompaktes, erschöpfendes Matching:

// Preview-Feature in Java 17
static String describe(Shape shape) {
    return switch (shape) {
        case Circle c    -> "Kreis mit Radius " + c.getRadius();
        case Rectangle r -> "Rechteck: " + r.getWidth() + " x " + r.getHeight();
        case Triangle t  -> "Dreieck mit Fläche " + t.area();
    };
}

Weil Shape sealed ist und der Compiler alle permits-Klassen kennt, kann er die Vollständigkeit prüfen -- ein default-Branch ist nicht nötig. Das ist ein erheblicher Fortschritt gegenüber langen if-else-instanceof-Ketten, die fehleranfällig und schwer wartbar waren.

Wichtig: Als Preview-Feature muss es explizit mit --enable-preview aktiviert werden und ist noch nicht für den Produktionseinsatz gedacht. Die finale Version wird voraussichtlich in einem der nächsten Releases kommen.

Records und Text Blocks: Jetzt Standard

Zwei Features, die bereits in Java 14 bis 16 als Preview liefen, sind mittlerweile fester Bestandteil der Sprache und stehen Teams, die von Java 11 kommen, erstmals zur Verfügung:

Records (final seit Java 16) sind kompakte, unveränderliche Datenklassen:

public record Point(double x, double y) {}

var p = new Point(3.0, 4.0);
System.out.println(p.x());       // 3.0
System.out.println(p);           // Point[x=3.0, y=4.0]

Konstruktor, Getter, equals(), hashCode() und toString() werden automatisch generiert. Für DTOs, Value Objects und Konfigurationsobjekte ersetzt das in vielen Fällen Lombok oder handgeschriebenen Boilerplate.

Text Blocks (final seit Java 15) machen mehrzeilige Strings lesbar:

var json = """
        {
            "name": "encircle360",
            "type": "software-consultancy",
            "founded": 2017
        }
        """;

Wer regelmäßig mit JSON, SQL oder HTML in Java-Code arbeitet, wird Text Blocks nicht mehr missen wollen.

Weitere nennenswerte Änderungen

Enhanced Pseudo-Random Number Generators (JEP 356)

Java 17 führt ein neues Interface RandomGenerator und mehrere neue Algorithmen ein, die über RandomGeneratorFactory verfügbar sind. Für die meisten Anwendungen ändert sich wenig, aber wer statistische Simulationen oder kryptographische Anforderungen hat, profitiert von der erweiterten Auswahl und dem einheitlichen API.

Neue macOS-Rendering-Pipeline (JEP 382)

Auf macOS nutzt Java 17 die Apple Metal API statt des veralteten OpenGL-Backends. Für Desktop-Anwendungen auf macOS bringt das eine bessere Performance und Zukunftssicherheit, da Apple OpenGL seit macOS 10.14 als deprecated markiert hat.

Deprecation des Security Managers (JEP 411)

Der Security Manager -- einst für Applets konzipiert und seit Jahren kaum noch genutzt -- wird in Java 17 als deprecated markiert. Das ist ein Signal, das in kommenden Versionen die endgültige Entfernung folgen wird. Für die überwiegende Mehrheit der Server-Anwendungen hat das keine Auswirkungen, da der Security Manager dort ohnehin nicht aktiviert war.

Starke Kapselung von JDK-Internals (JEP 403)

Was mit Java 9 und dem Modulsystem begann, wird in Java 17 konsequent umgesetzt: Der Zugriff auf interne JDK-APIs über Reflection ist standardmäßig blockiert. Die Kommandozeilenoption --illegal-access, die in früheren Versionen als Überbrückung diente, existiert nicht mehr. Bibliotheken und Frameworks, die auf interne APIs zugegriffen haben, mussten in den vergangenen drei Jahren auf öffentliche Alternativen umstellen -- und die meisten haben das getan.

Was bedeutet das für das Ökosystem?

Die Java-17-Unterstützung im Framework-Ökosystem ist erfreulich gut. Spring Boot 2.5 und 2.6 laufen einwandfrei auf Java 17. Hibernate, Jackson, Testcontainers und die gängigen Build-Tools haben bereits kompatible Versionen.

Besonders interessant für die mittelfristige Planung: Das Spring-Team hat angekündigt, dass Spring Framework 6 und Spring Boot 3 Java 17 als Mindestanforderung haben werden. Das ist ein deutliches Signal, dass Java 17 für die nächsten Jahre die Baseline im Enterprise-Java-Ökosystem sein wird. Spring Boot 3 wird voraussichtlich 2022 erscheinen und zusätzlich die Migration von javax.* zu jakarta.* Namespaces vollziehen. Wer jetzt auf Java 17 migriert, ist dafür bestens vorbereitet.

Unsere Empfehlung

Wir bei encircle360 haben die ersten Services bereits in der Woche nach dem Release auf Java 17 aktualisiert. Für Teams, die auf Java 11 LTS laufen, ist die Migration erfreulich unkompliziert -- deutlich einfacher als der Sprung von Java 8 auf 11. Die größte Hürde ist in der Regel die starke Kapselung der JDK-Internals (JEP 403). Wer die --illegal-access-Warnungen in den letzten drei Jahren bereinigt hat, sollte hier kaum Probleme haben.

Ein pragmatischer Migrationsplan:

1. JDK 17 installieren und in CI/CD einbinden -- wir empfehlen Eclipse Temurin (ehemals AdoptOpenJDK) oder Amazon Corretto
2. Kompilieren und Tests laufen lassen -- die meisten Inkompatibilitäten zeigen sich sofort
3. Illegal-Access-Probleme beheben -- --add-opens-Flags durch Updates der betroffenen Bibliotheken ersetzen
4. Source Level auf 17 setzen -- im Compiler-Plugin von Maven oder Gradle
5. Neue Features schrittweise einführen -- Records, Sealed Classes und Pattern Matching in neuem Code nutzen

Die Kombination aus Sealed Classes, Records und Pattern Matching verändert die Art, wie man Java-Domänenmodelle schreibt. Es fühlt sich an wie ein substanzieller Sprung in der Ausdruckskraft der Sprache -- und das bei voller Abwärtskompatibilität. Java 17 ist ein hervorragendes LTS-Release und wird für viele Teams die Basis für die kommenden Jahre sein.