Primitive Datentypen haben in Domainobjekten und der datenorientierten Programmierung viele Vorteile. Doch wurden sie im Projekt Amber bei der Einführung von Pattern Matching bisher ausgeklammert. Mit JEP 455, Primitive Types in Patterns, instanceof, and switch, gehört die Außenseiterrolle der primitiven Datentypen der Vergangenheit an.

Das Open-JDK-Projekt Amber hat das Ziel, die Sprache Java mit kleinen und produktivitätssteigernden Verbesserungen zu modernisieren. Ein großer Baustein bei diesem Bestreben ist das Pattern Matching und das Paradigma der Datenorientierung. Doch dabei wurden primitive Datentypen fast immer ausgeklammert. Begründet wurde das mit den komplizierten Typumwandlungen für primitive Datentypen. Diese Lücke wird mit JEP 455 geschlossen.

Pattern Matching in Java

Pattern Matching wird seit Java 14 durch das Projekt Amber schrittweise eingeführt. In den jüngsten Versionen der Sprache wurden viele Konstrukte finalisiert, die wir zunächst kurz umreißen:

Mit JEP 394, Pattern Matching for instanceof, [1] wurden in Java 16 der instanceof-Operator und der assoziierte Type Cast zum Type Pattern verschmolzen. Dessen Aufgabestellung lautet: „Ist das Objekt in den Datentyp umwandelbar? Wenn ja, dann erzeuge eine neue Pattern-Variable mit dem umgewandelten Wert.“ Dadurch wurden nicht nur Type-Checks und Umwandlung enger aneinandergebunden, sondern es wurde auch das grundlegende Pattern geschaffen. Für sich genommen nicht besonders aufregend, bildet es doch die Grundlage für alle weiteren Patterns und syntaktischen Verbesserungen.

Mit Hilfe des Type Pattern wurde mit JEP 441 das Pattern Matching for switch [2] vorangetrieben und in Java 21 finalisiert. In diesem JEP wurden das Switch Statement und die Switch Expression erweitert, sodass Patterns als Case Labels verwendet werden können. Dadurch ist es möglich, mehrere unterschiedliche Patterns zu definieren und eine Instanz zu prüfen. So kann auf unterschiedliche Datenkonstellationen reagiert werden. Zusätzlich wurden when-Clauses hinzugefügt. Durch sie kann ein Pattern um einen booleschen Ausdruck erweitert werden, um eine feingranulare Verarbeitung der Daten durchzuführen.

Durch Dekonstruktion werden Objekte in ihre Komponenten zerlegt, um sie weiterzuverarbeiten. Mit JEP 440, Record Patterns, [3] wurde ein erstes Dekonstruktionspattern in Java 21 eingeführt. Das an einen Konstruktor erinnernde Record Deconstruction Pattern wird verwendet, um Komponenten aus einer Record-Instanz typsicher zu entnehmen. In diesem Pattern ist es möglich, das Type Pattern als Nested Pattern zu verwenden, um generische Komponenten explizit zu behandeln. Durch das automatische Unboxing sind hier auch bedingt primitive Datentypen möglich. Sie stehen allerdings nicht im Fokus.

Bei vielen Anwendungen des Record Deconstruction Pattern ist es nicht notwendig, dass alle Komponenten zugreifbar sind. Um nicht verwendete Variablen und die verbundene mentale Belastung zu senken, wurde mit JEP 456, Unnamed Variables & Patterns, [4] das Unnamed Pattern eingeführt. Dieses Pattern matcht alles und definiert keine Patternvariablen. Es ist gedacht, um nicht benötigte Patternvariablen oder ganze nicht benötigte Patterns als solche auszuzeichnen. Als Syntax wurde hier der einfache Unterstrich verwendet; er wirkt wie eine Wildcard.

In Listing 1 ist für jedes JEP ein kleines Codebeispiel gegeben, um die Syntax aufzufrischen. In früheren Ausgaben dieses Magazins ist jedes JEP bereits...