Sealed Classes mit Java JDK 17

Was sind Sealed Classes?
Mit dem kommenden Java Release 17 werden sogenannte Sealed Classes eingeführt. Diese waren zuvor bereits seit dem JDK 15 in Form eines Preview Features vorhanden und in JDK 16 überarbeitet. Nun erscheinen sie final mit JDK 17.
Bei diesem Feature wird es möglich sein, das Erben und Implementieren von Klassen bzw. Interfaces auf bestimmte andere Klassen und Interfaces einzuschränken. Kurz gesagt, die entwickelnde Person kann vorgeben, welche andere Klasse erben darf.
Ziele und Nutzen
Codebeschreibung
Mit dem Modifier „sealed“ wird die Klasse als solche deklariert. Mit dem Schlüsselwort „permits“ können im Nachgang die zugelassenen Klassen eingefügt werden.
public abstract sealed class Fahrzeug
permits com.example.test.Lkw, Pkw, Fahrrad { ... }
Es ist auch möglich die erlaubten Klassen direkt im Sourcefile zu erstellen. Das Schlüsselwort „permits“ wird hier weggelassen. Der Javacompiler leitet die erlaubten Klassen anhand des Codes ab.
abstract sealed class Root { ...
final class A extends Root { ... }
final class B extends Root { ... }
final class C extends Root { ... }
}
Zu beachten
- Die Sealed Class und die erlaubten Unterklassen müssen sich im gleichen Modul befinden.
Eine Besonderheit gibt es noch für „unnamed module“. Diese müssen sich im gleichen Package befinden. - Jede erlaubte Unterklasse muss von der Sealed Class erben.
- Jede erlaubte Unterklasse muss entweder final, sealed oder non-sealed deklariert sein.
Beispiel
Angenommen wir haben eine Klasse Fahrzeug. Von dieser Klasse erbt PKW, LKW und anschließend Fahrrad.
public abstract sealed class Fahrzeug
permits Pkw, Lkw, Fahrrad { /*some code*/ }
public final class Pkw extends Fahrzeug { ... }
public sealed class Lkw extends Fahrzeug
permits Kleinlaster, Schwertransport { ... }
public final class Kleinlaster extends Lkw { ... }
public final class Schwertransport extends Lkw { ... }
public non-sealed class Fahrrad extends Fahrzeug { ... }
Die Klasse Fahrrad ist somit offen für Erweiterungen aber geschlossen für Änderungen (Open-Closed Prinzip). Es ist nicht möglich, final und sealed zu sein, nur ein Modifier ist erlaubt. Interfaces verhalten sich Analog zu Klassen.
Fazit
Ich persönlich sehe hier großes Potential die API-Entwicklung zu vereinfachen, besonders im Bezug auf Security Aspekte. Sobald eine Sealed Vorraussetzung verletzt wird, wirft der Compiler eine Exception, das hilft nicht nur beim Entwickeln, sondern auch beim Testen. Unvorhersehbare Effekte werden dadurch verringert. Ich bin auf jeden Fall sehr gespannt, wenn dieses Feature fertig released wird und welche neuen Möglichkeiten sich daraus ergeben können.