Sealed Classes & Interfaces

Record patterns deconstruct records in a case, pattern-matching switch binds by runtime type with guards, and over a sealed hierarchy the compiler enforces exhaustiveness so adding a case becomes a compile error you cannot miss.

A sealed class can be abstract: `abstract` stops direct instantiation while `sealed` restricts who may extend it, and both constraints apply at once.

A sealed class cannot permit itself because `permits` lists direct subtypes, and nothing can be its own subtype.

A permitted subclass must declare `final`, `sealed`, or `non-sealed`; omitting all three is a compile error because sealing requires an explicit extensibility decision at every subtype.

Yes: serialize freely, but polymorphic deserialization needs a type discriminator in the JSON via Jackson's `@JsonTypeInfo`/`@JsonSubTypes` or Gson's `RuntimeTypeAdapterFactory`.

Sealed types provide the closed sum ("one of these variants"), records provide the product (bundled fields), and exhaustive `switch` makes handling them type-safe and complete.

A `non-sealed` subtype reopens its branch, so any unlisted class may extend it and thereby become an indirect subtype of the sealed interface.

`getPermittedSubclasses()` returns the direct permitted subtypes recorded in the class file at runtime, but only the direct ones, not transitive descendants or open `non-sealed` subclasses.

Sealed types say "it is exactly one of these," records say "and here are its fields," and pattern matching reads both in a single exhaustive switch.

Reflection cannot break sealing because the JVM re-checks the permits list at load time, but raw bytecode edits can forge that metadata, so sealing is an integrity guarantee, not a security sandbox.

A sealed type uses `permits` to name exactly which types may directly extend it, and each permitted subtype must be `final`, `sealed`, or `non-sealed`.

Same module, different packages is allowed; classpath requires the same package; different modules is never allowed.