Sealed Classes
A language feature formally introduced in Java 17. A permits clause explicitly restricts the subtypes that may extend or implement a type, making the inheritance relationship controlled and closed, which in turn supports compile-time exhaustiveness checking.
Timeline (last 90 days)
Java sealed classes have been officially released since Java 17.
Sealed classes explicitly declare the permitted subtypes via the permits clause, turning inheritance relationships from open to controlled.
In combination with sealed classes, the compiler can verify whether all permitted subclasses in a switch are handled, and a missed subtype results in a compile error (exhaustiveness checking).
Exhaustiveness checking is only effective for sealed hierarchies; for ordinary open interfaces, the compiler still requires a default branch.
Adding a default branch in a switch disables exhaustiveness checking, so newly added subtypes no longer trigger compile errors; therefore, unnecessary default branches should be avoided when using sealed classes.
Subtypes of sealed classes can carry their own distinct state and methods, giving them greater expressiveness than enums; if it is merely a fixed set of constants, an enum is the lighter-weight choice.
The permits clause of a sealed class requires that subclasses reside in the same module (or the same package, depending on the module system configuration).
Mainstream IDEs already support prompting for missing branches in sealed hierarchies, forming a dual safeguard together with the compiler's exhaustiveness checking.
According to Hacker News discussion, many developers believe the most valuable use case for sealed classes is domain modeling—expressing business states with a closed set of variants.
All Facts (9)
Java sealed classes have been officially released since Java 17.
50%UnverifiedSealed classes explicitly declare the permitted subtypes via the permits clause, turning inheritance relationships from open to controlled.
50%UnverifiedIn combination with sealed classes, the compiler can verify whether all permitted subclasses in a switch are handled, and a missed subtype results in a compile error (exhaustiveness checking).
50%UnverifiedExhaustiveness checking is only effective for sealed hierarchies; for ordinary open interfaces, the compiler still requires a default branch.
50%UnverifiedAdding a default branch in a switch disables exhaustiveness checking, so newly added subtypes no longer trigger compile errors; therefore, unnecessary default branches should be avoided when using sealed classes.
50%UnverifiedSubtypes of sealed classes can carry their own distinct state and methods, giving them greater expressiveness than enums; if it is merely a fixed set of constants, an enum is the lighter-weight choice.
50%UnverifiedThe permits clause of a sealed class requires that subclasses reside in the same module (or the same package, depending on the module system configuration).
50%UnverifiedMainstream IDEs already support prompting for missing branches in sealed hierarchies, forming a dual safeguard together with the compiler's exhaustiveness checking.
50%UnverifiedAccording to Hacker News discussion, many developers believe the most valuable use case for sealed classes is domain modeling—expressing business states with a closed set of variants.
50%