Java 17 Sealed Classes: A Practical Engineering Decision

Why Sealed Classes Matter for Your Codebase

When you need a type that can only be extended by a known set of classes, sealed classes give you compile‑time enforcement. They let the compiler know the exact subclasses, which improves type safety, enables exhaustive switch statements, and documents intent for future maintainers.

Defining a Sealed Class Hierarchy

Use the permits clause to list every allowed subclass. The syntax is available from Java 17 onward; you must compile with --release 17 (or -source 17 -target 17) so the compiler recognises the feature.

// Shape.java
public sealed class Shape permits Circle, Rectangle, Polygon {
    public abstract double area();
}

// Circle.java
public final class Circle extends Shape {
    private final double radius;
    public Circle(double radius) { this.radius = radius; }
    @Override public double area() { return Math.PI * radius * radius; }
}

// Rectangle.java
public final class Rectangle extends Shape {
    private final double width, height;
    public Rectangle(double width, double height) {
        this.width = width; this.height = height;
    }
    @Override public double area() { return width * height; }
}

// Polygon.java – a non‑sealed extension that can grow later
public non‑sealed class Polygon extends Shape {
    private final int sides;
    public Polygon(int sides) { this.sides = sides; }
    @Override public double area() { return 0; /* placeholder */ }
}

Notice the final modifier on Circle and Rectangle—they cannot be subclassed further. Polygon is declared non‑sealed, allowing future extensions without altering the parent’s permits list.

Exhaustive Switch with Pattern Matching

With a sealed hierarchy, the compiler can verify that a switch covers all possible cases. This is a powerful safety net when adding new subclasses.

public static double totalArea(List<Shape> shapes) {
    return shapes.stream()
        .mapToDouble(s -> switch (s) {
            case Circle c -> c.area();
            case Rectangle r -> r.area();
            case Polygon p -> p.area();
        })
        .sum();
}

Compiling this with javac --release 17 will succeed. If you add a new sealed subclass, the compiler will flag the switch as non‑exhaustive, forcing you to handle the new case.

Limitations and Edge Cases

• Generic Wildcards: You can use List<? extends Shape> but List<? super Shape> cannot contain non‑sealed subclasses because the compiler cannot guarantee the type safety of the wildcard.
• Reflection: The sealed constraint is enforced at compile time. Using reflection to create subclasses bypasses the rule, but the resulting classes will not be assignable to Shape without a permits declaration.
• Inter‑module Boundaries: In a multi‑module project, each module must declare the permitted subclasses in its own module-info. The compiler checks the permits list across module boundaries.
• Preview Features: If you compile with --enable-preview (pre‑Java 17), you need to run with the same flag. From Java 17 onward, sealed classes are a stable feature.

Common Pitfalls and How to Avoid Them

1. Missing the permits Clause: A sealed class without a permits list is illegal. Always include the clause, even if you currently have no subclasses.
2. Forgetting to Declare All Subclasses: If you add a new subclass and forget to update the permits list, compilation will fail. Keep the list in sync or use a code‑review checklist.
3. Mixing Sealed and Non‑Sealed Subclasses Unnecessarily: If you only need a fixed set of subclasses, make them all final. Introducing non‑sealed subclasses defeats the purpose of restriction.
4. Using Wildcard Generics Improperly: Avoid List<? super Shape> when you need to add non‑sealed subclasses. Stick to List<Shape> or List<? extends Shape> for read‑only collections.
5. Assuming Runtime Enforcement: Sealed classes are compile‑time only. If you load classes dynamically, the sealed constraint is not enforced by the JVM.

Practical Checklist for Introducing Sealed Classes

• Verify your project targets Java 17 or newer.
• Use javac --release 17 or configure your build tool accordingly.
• Define the sealed class with a permits clause.
• Mark all concrete subclasses as final unless future extension is required.
• Update switch statements to be exhaustive; run javac to catch missing cases.
• Run unit tests that cover each subclass path.
• Document the intent in code comments and architecture notes.

Sealed classes are a straightforward, type‑safe tool for controlling inheritance. When used correctly, they reduce bugs, clarify intent, and empower the compiler to catch missing branches before runtime.