Java sealed classes brechen Code, wenn sie in öffentlichen APIs landen
Java sealed classes and exhaustive pattern matching
Sealed classes in Java 17 ermöglichen Exhaustiveness-Checking beim Pattern Matching: Der Compiler prüft, ob alle Fälle abgedeckt sind. Doch wer einen sealed type in einer öffentlichen API exportiert, schafft eine neue Art von Breaking Change. Wird ein Subtyp hinzugefügt, kompiliert der Code der Nutzer nicht mehr – oder schlimmer: Er stürzt zur Laufzeit mit einer MatchException ab, wenn nicht alles neu kompiliert wird. Der Autor rät, sealed types nur intern einzusetzen.
Wenn du einen sealed type in deiner API exportierst, ist das Hinzufügen eines neuen Subtyps ein Breaking Change, der einen Major-Versionssprung erfordern würde.
- shepherdjerred
Ich liebe es, wie weit es Java gebracht hat. Ich bevorzuge trotzdem TypeScript, da ich viel Frontend-Arbeit mache und lieber dieselbe Sprache im gesamten Stack verwende.
Davon abgesehen kann man in TypeScript erschöpfendes Pattern Matching machen! https://github.com/gvergnaud/ts-pattern
- another_twist
Ich habe eine Weile gebraucht, um mich an sealed zu gewöhnen, und den Nutzen nicht so recht gesehen. Aber die KI scheint es für Java zu lieben, also habe ich es ausprobiert, und jetzt verstehe ich es. Es ist wie ein richtig guter Zugriffskontrollmechanismus, besonders wenn man DI verwendet und ein paar Sachen deprecaten will. Abgesehen natürlich vom Pattern Matching – das ist praktisch bei eventgetriebenen Nachrichten, bei denen sich die Form der Payload ändert.
- armchairhacker
Java hat auch rekursive Patterns und (vielleicht noch in der Preview) Literal-Patterns: `switch (x) { case A(B(true, var c)) -> f(c); }`
- timshel2
Scala boxt gerade in die Luft
- panny
Ich glaube nicht, dass man diese switch-Defaults bei den sealed Types braucht. Ich habe es nicht mit einem Compiler geprüft, aber ich denke, die sind unnötig.
- Larrikin
Java versucht weiterhin, mit Kotlin mitzuhalten
https://kotlinlang.org/docs/sealed-classes.html
Mir war Java egal, als die Vergleiche noch mit C++, Ruby und Python waren. Nach Scala (das ja offenbar gescheitert ist, weil es zu wahllos war) und besonders Kotlin finde ich keinen Grund, zurückzugehen.