Java Records, Sealed Types und Pattern Matching für switch

Worum es geht

JEP 395 beschreibt einen Record als eine Klasse, die als transparenter Träger für unveränderliche Daten dient. record Point(int x, int y) {} deklariert die Komponenten; der Compiler leitet daraus einen kanonischen Konstruktor, pro Komponente eine öffentliche Zugriffsmethode (x(), nicht getX()) sowie equals, hashCode und toString über alle Komponenten ab. Ein Record ist implizit final, kann keine andere Klasse erweitern und ausser seinen Komponenten keine Instanzfelder deklarieren. Ein kompakter Konstruktor, ohne Parameterliste geschrieben, validiert oder normalisiert die Argumente, bevor sie zugewiesen werden.

JEP 409 fügt Sealed Classes und Interfaces hinzu: sealed interface Shape permits Circle, Square {} benennt die einzigen zulässigen direkten Subtypen, von denen jeder final, sealed oder non-sealed sein muss und die alle im selben Modul (oder im selben Package des unbenannten Moduls) liegen müssen. Records sind implizit final und daher natürliche zulässige Subtypen.

JEP 441 (JDK 21) erlaubt es switch, Typmuster (case Circle c -> ...), Guards (case Circle c when c.radius() > 0), case null sowie Dekonstruktionsmuster für Records zu verwenden. Ein Pattern-Switch muss vollständig sein: Über einem Sealed Type braucht es kein default, wenn für jeden zulässigen Subtyp ein Case vorhanden ist, und der Compiler weist einen unvollständigen Switch zurück.

Warum es wichtig ist

Wer von Rust, Kotlin, Swift oder TypeScript kommt, erwartet algebraische Datentypen und vollständiges Pattern Matching. Vor diesen Sprachmerkmalen modellierte Java «eines von mehreren Shapes» mit einer Klassenhierarchie plus instanceof-Ketten, und der Compiler konnte keine unbehandelte Variante melden. Bei einer Sealed-Hierarchie macht das Hinzufügen eines zulässigen Subtyps jeden vollständigen Switch ohne default bis zur Aktualisierung zu einem Kompilierfehler.

So wird es angewendet

• Records für Werte verwenden: DTOs, Map-Schlüssel, Ergebnisse, Ereignisse. Im kompakten Konstruktor validieren und bei ungültigen Argumenten eine Exception werfen.
• Eine abgeschlossene Menge von Alternativen als Sealed Interface modellieren, dessen zulässige Typen Records sind; die gesamte Hierarchie in einer Datei oder einem Package halten.
• Switch-Ausdrücke mit Pattern-Labels gegenüber instanceof-Ketten bevorzugen und default bewusst weglassen, damit der Compiler die Vollständigkeit erzwingt.
• Records absichtlich nur flach unveränderlich halten: Ein Record, der eine List hält, gibt weiterhin eine veränderliche Liste preis, sofern der Konstruktor sie nicht kopiert (List.copyOf).
• Records werden anhand ihrer Komponenten serialisiert und über den kanonischen Konstruktor deserialisiert, sodass die dortige Validierung auch die Deserialisierung absichert.

Stolpersteine

Das equals eines Records verwendet alle Komponenten, was für Entitäten mit Identität falsch ist. Ein default-Zweig in einem Pattern-Switch verdeckt fehlende Fälle stillschweigend. Pattern-Switch braucht JDK 21 (Records brauchen 16, Sealed Types 17). JEP 441 hält fest, dass ein Pattern-Switch, der zur Laufzeit kein passendes Label findet – etwa weil eine separat kompilierte Sealed-Hierarchie einen Subtyp dazugewonnen hat – eine MatchException wirft.