Sealed Classes and Interfaces

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

sealed

A modifier for a class or interface that restricts which classes may directly extend or implement it.

permits

The clause listing the classes allowed to extend a sealed type: permits Circle, Square.

non-sealed

A modifier for a permitted subclass that opens it back up, so any class can extend it.

Exhaustive

Covering every possible case. A switch over a sealed type with a case for each permitted subtype is exhaustive.

Algebraic data type

A type defined as a fixed set of alternatives, each holding some data. In Java: a sealed interface plus records.

Record

A compact, immutable data class (Java 16, Topic 4.9). Records are implicitly final.

Pattern matching for switch

A Java 21 feature letting case labels test types, like case Circle c ->, and bind a variable.

1. 1

   Add a variant and let the compiler guide you

   In the Payment example (Java 21), add record Wallet(double amount) implements Payment { } and add Wallet to permits. Compile: both switches fail with 'does not cover all possible input values'. Add a case Wallet w -> ... to each and run again.

2. 2

   Try to sneak in a subclass

   In the shapes example, add record Triangle(double b, double h) implements Shape { } without changing permits. Read the error. Then add it to permits, and notice area() still compiles (instanceof chains aren't checked) but throws at run time for a Triangle. That's exactly why the Java 21 switch is better.

3. 3

   Drop the modifier

   In the Vehicle example, remove final from Car. Read sealed, non-sealed or final modifiers expected.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

sealed interface Shape permits Circle, Square { }
final class Circle implements Shape { }
final class Square implements Shape { }
final class Triangle implements Shape { }

sealed interface Shape permits Circle { }
class Circle implements Shape { }

sealed interface Shape permits Circle, Square { }
record Circle(double r) implements Shape { }
record Square(double s) implements Shape { }
public class Main {
  static double area(Shape s) { return switch (s) { case Circle c -> 3.0 * c.r(); }; }
  public static void main(String[] a) { } }

1. 1

   Between final (no subclasses) and an ordinary class (anyone can subclass), sealed gives a third option: these subclasses and no others. Write sealed interface Shape permits Circle, Square, Rectangle { }.

2. 2

   Every permitted subclass must say how *it* continues the hierarchy, with exactly one of: **final (no further subclasses), sealed (its own closed list), or non-sealed** (open again to anyone). Records and enums are implicitly final, so a record can implement a sealed interface with no extra modifier.

3. 3

   Location rules: permitted subclasses must be in the same module as the sealed type, or, if the code isn't in a named module (the usual case for small programs), in the same package. If all subclasses are in the same source file, you may leave out permits and the compiler infers the list.

4. 4

   The payoff is exhaustiveness. Because the compiler knows every subtype, a switch over a sealed type with a case for each subtype needs no default (pattern matching for switch, Java 21, Topic 11.2). Add a new subtype later and every such switch stops compiling until it handles the new case. The compiler finds your missing cases for you.

5. 5

   Sealed interfaces plus records give Java algebraic data types: a closed set of alternatives (sum type), each a simple data carrier (product type). This is the modern way to model things like Payment = Card | Upi | Cash or Result = Success | Failure.

6. 6

   It's enforced at run time too. The class file records a PermittedSubclasses attribute, and the JVM refuses to load a class that extends a sealed type without being listed, so a sealed hierarchy can't be bypassed by compiling a rogue class separately.

• ↔

  Sealing gives compile-time completeness checks and stronger domain models, but closes the hierarchy to outside extension. Library authors must be sure no user needs their own subtype.

• ↔

  Adding a permitted subtype is a source-breaking change for every exhaustive switch in client code. That's the point inside one codebase, but a compatibility burden across published library versions.

• Done when you can declare a sealed interface with records as permitted subtypes.

• Done when you can explain final, sealed and non-sealed on the children.

• Done when you can write an exhaustive Java 21 switch over a sealed type with no default.

• Done when you can explain the package/module rule and run-time enforcement.

• Done when you can choose between a sealed hierarchy and open polymorphism for a design.