Java sealed classes and exhaustive pattern matching

armchairhacker

Java also has recursive patterns and (maybe still in preview) literal patterns: `switch (x) { case A(B(true, var c)) -> f(c); }`

Larrikin

Java continues to try and catch up to Kotlin https://kotlinlang.org/docs/sealed-classes.html I didn't mind Java when the comparisons were to C++, Ruby, and Python. I can not find a reason to go back after Scala (which seemed to fail due to being indiscriminate) and especially Kotlin

timshel2

Scala punching the air rn

shepherdjerred

I love how far Java has come. I still prefer TypeScript since I do a lot of frontend work and prefer to use the same language across the stack. With the said, you can do exhaustive pattern matching in TypeScript! https://github.com/gvergnaud/ts-pattern

panny

I don't think you need those switch defaults with the sealed types. I didn't check with a compiler, but I think those are unnecessary.

another_twist

Took me a while to get used to sealed and I didn't quite see the use. But AI seems to love it for Java so I gave it a go and now I get it. Its like a really good access control mechanism esp if you use DI and want to deprecated some stuff. Apart from ofcourse the pattern matching - which comes in handy for event driven messages where payload shape changes.

DimmieMan

Might be grass is greener mentality, but I think I prefer this to whatever C# is doing. The sealed keyword makes sense, isn't unique to this feature and you can pattern match exhaustively. I feel like I could explain this to a beginner without overloading them, it's still 'just Java' while giving you a way to occasionally model a one-of relations with out the awkward default handling while sticking to the predominately OOP driven nature of the language. The stuff you can do with a functional language is amazing but I don't think bolting on new paradigm's until you have a diabetic Frankenstein of a language is the right answer, Scalar is right over there if that's your preferred style.

smarks

The article (which seems to be from 2026-04-24 based on its URL) refers to the JDK 26 version of the PEM Encodings API. [1] [1]: https://openjdk.org/jeps/524 The article points out a potential pitfall with how this version of the API exposes a sealed class. If the application has an exhaustive switch expression that lists all permitted subclasses, and a later JDK release were to add a new permitted subclass, this would potentially expose the application to a MatchException at runtime. In the JDK 27 version of the PEM Encodings API, JEP 538 [2], we’ve adjusted the permitted subclasses of the sealed class in question to include a non-public permitted subclass. [2]: https://openjdk.org/jeps/538 This prevents applications from using an exhaustive switch expression by enumerating all permitted subclasses. This allows the JDK to extend set of permitted subclasses in the future without exposing applications to the risk of unexpected exceptions.