A sealed class or interface lets its author write down, once and for all, the complete list of types allowed to extend or implement it - and have the compiler enforce that list everywhere, forever. Declaring sealed interface Shape permits Circle, Rectangle does not just suggest that Circle and Rectangle are the only shapes; it makes any other class claiming to be a Shape a compile error. The payoff shows up the moment code needs to handle every kind of Shape: a switch over a sealed type can know, at compile time, that Circle and Rectangle are the only possibilities - no default branch standing in for "something I didn't think of."

What Is a Sealed Class?

A sealed class or interface is declared with the sealed modifier and a permits clause naming every type allowed to directly extend or implement it. This feature was previewed in Java 15 and 16, and finalized in Java 17. Every type named in permits must itself declare, explicitly, what happens to the closed-hierarchy guarantee from that point onward - by being final, sealed (with its own narrower permits), or non-sealed.

sealed interface Shape permits Circle, Rectangle {}

record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

// class Triangle implements Shape {}   <- COMPILE ERROR
// Triangle is not in Shape's permits clause

A note on Java versions, since this matters for the examples ahead: the sealed / permits / non-sealed / final declarations themselves are a Java 17 feature. The most natural way to USE a sealed type - a switch that exhaustively handles every permitted subtype with no default - relies on pattern matching for switch, which was finalized in Java 21 (JEP 441), after several preview rounds starting in 17. On Java 17 through 20, sealed declarations compile and the closed-hierarchy guarantee is enforced at the declaration level, but the switch-based exhaustiveness shown throughout this article specifically needs Java 21 (or the relevant preview flag on earlier versions).

Basic Overview - The Three Things a Permitted Subtype Can Be

DECLARING THE SEALED TYPE
  sealed interface Shape permits Circle, Rectangle { }

  Fresher view  : a closed list, written by the author, of every type
                  allowed to be a Shape - nothing else, ever
  Deeper view   : 'permits' can be OMITTED if every permitted type is
                  declared in the SAME source file - the compiler
                  infers the list from what it sees there

EVERY DIRECT SUBTYPE MUST CHOOSE EXACTLY ONE OF THREE OPTIONS:

  final        - "the hierarchy ends here"
    final record Circle(double radius) implements Shape {}
    Fresher view  : Circle cannot be extended by anything, ever
    Deeper view   : records are implicitly final already - writing
                    'final' on a record is redundant but harmless

  sealed       - "extendable, but only by MY OWN closed list"
    sealed interface Polygon extends Shape permits Triangle, Square {}
    Fresher view  : Polygon is itself a closed set, nested inside Shape's
    Deeper view   : multi-level sealed hierarchies are fully supported -
                    a switch over Shape must still account for every
                    concrete type reachable through Polygon too

  non-sealed   - "the closed guarantee deliberately ENDS here"
    non-sealed class ElectricVehicle implements Vehicle {}
    Fresher view  : from ElectricVehicle onward, any class anywhere
                    can extend it normally
    Deeper view   : this is an explicit, visible DECISION recorded in
                    the type itself - "Vehicle is closed, except this
                    one branch is intentionally open"

EXHAUSTIVE switch OVER A SEALED TYPE (Java 21)
  Fresher view  : a switch handling every permitted subtype needs no
                  default branch - the compiler already knows there
                  is nothing else
  Deeper view   : adding a new permitted subtype later, without
                  updating every switch that should handle it, becomes
                  a COMPILE ERROR at each one - not a runtime surprise
                  discovered later

A fresher mainly needs the top two boxes - declare the closed list, and know that final is the default expectation for "this branch ends here." The non-sealed and exhaustive-switch boxes are where sealed types stop being "a slightly stricter interface" and start being the foundation of a pattern - modeling a fixed set of "shapes" a value can take, with the compiler checking that every shape is handled, everywhere.

Why Sealed Classes Were Introduced

Before sealed types, every interface and every non-final class was, by definition, open - any class anywhere, in any package, could implement or extend it. This was rarely a problem for types meant to be extended freely, but it was a real gap for types meant to represent "one of a few specific things and nothing else."

Java

Try it out

// BEFORE - a plain interface, open to anyone

interface Shape {}

record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

// Nothing stops this, anywhere in the codebase, ever:
// record Triangle(double base, double height) implements Shape {}

double area(Shape shape) {
    if (shape instanceof Circle c) {
        return Math.PI * c.radius() * c.radius();
    } else if (shape instanceof Rectangle r) {
        return r.width() * r.height();
    } else {
        // This branch exists ONLY because the compiler cannot know
        // whether Circle and Rectangle are "all of them" - as far as
        // Shape is concerned, ANY class could implement it
        throw new IllegalStateException("Unknown shape: " + shape);
    }
}

Java

Try it out

// AFTER - a sealed interface, closed by declaration

sealed interface Shape permits Circle, Rectangle {}

record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

// record Triangle(double base, double height) implements Shape {}
// COMPILE ERROR - Triangle is not in Shape's permits clause

double area(Shape shape) {
    return switch (shape) {
        case Circle(double radius) -> Math.PI * radius * radius;
        case Rectangle(double width, double height) -> width * height;
        // NO default - the compiler verified Circle and Rectangle
        // are the ONLY possible Shape values
    };
}

The else branch in the "before" version was not handling a real case - it was a safety net for a possibility the compiler could not rule out, because Shape placed no restriction on who could implement it. The "after" version removes that branch entirely, and the removal is not optional cleanup - the compiler requires the switch to cover exactly Circle and Rectangle, because Shape's declaration says those are the only two that exist. If a third shape is ever added to permits, every switch like this one that does not yet handle it becomes a compile error - turning "we forgot to handle the new case" from a bug report into a build failure, at every affected location, immediately.

Syntax

DECLARING A SEALED TYPE:
  sealed interface Shape permits Circle, Rectangle { }
  sealed class Vehicle permits Car, Truck { }

  - 'permits' lists every type allowed to directly extend/implement
    this one
  - 'permits' can be OMITTED if every permitted type is declared in
    the SAME source file - the compiler infers the list

EVERY DIRECT PERMITTED SUBTYPE MUST BE EXACTLY ONE OF:

  final        - the hierarchy ends here
    final class Car implements Vehicle { }

  sealed       - extendable, but only by its OWN permits list
    sealed interface Polygon extends Shape permits Triangle, Square { }

  non-sealed   - reopens extension from this point onward
    non-sealed class ElectricVehicle implements Vehicle { }

WHERE PERMITTED SUBTYPES MUST LIVE:
  - the same module as the sealed type, if modules are used, or
  - the same package, if not - typically the same source file when
    'permits' is omitted

Common Use Cases

A Closed Result Type With Exhaustive Switch

The most common shape for sealed types: a small, closed set of possible outcomes, each represented by a record, handled by a switch with no default.

Java

Try it out

// File: PaymentResultDemo.java

public class PaymentResultDemo {

    sealed interface PaymentResult permits Success, Failure {}

    record Success(String transactionId, double amount) implements PaymentResult {}
    record Failure(String reason) implements PaymentResult {}

    static String describe(PaymentResult result) {
        return switch (result) {
            case Success(String transactionId, double amount) ->
                "Payment successful: " + transactionId + " for Rs." + amount;
            case Failure(String reason) ->
                "Payment failed: " + reason;
            // No default needed - PaymentResult permits ONLY
            // Success and Failure
        };
    }

    public static void main(String[] args) {
        PaymentResult success = new Success("TXN-9001", 1499.0);
        PaymentResult failure = new Failure("Insufficient balance");

        System.out.println(describe(success));
        System.out.println(describe(failure));
    }
}

Output:
Payment successful: TXN-9001 for Rs.1499.0
Payment failed: Insufficient balance

Reopening a Branch With non-sealed

non-sealed is a deliberate, visible decision: this specific branch of an otherwise closed hierarchy is open to extension by anything, anywhere. The switch over the top-level sealed type stays exhaustive - it only needs to know about the permitted branch, not every possible subclass of that branch.

Java

Try it out

// File: VehicleHierarchyDemo.java

public class VehicleHierarchyDemo {

    sealed interface Vehicle permits Car, Truck, ElectricVehicle {
        String describe();
    }

    // final - Car cannot be extended further
    static final class Car implements Vehicle {
        @Override
        public String describe() { return "Car"; }
    }

    // final - Truck cannot be extended further
    static final class Truck implements Vehicle {
        @Override
        public String describe() { return "Truck"; }
    }

    // non-sealed - intentionally REOPENS extension. Any class, anywhere,
    // can extend ElectricVehicle - the closed guarantee deliberately
    // ends here, by the original author's explicit choice.
    static non-sealed class ElectricVehicle implements Vehicle {
        @Override
        public String describe() { return "ElectricVehicle"; }
    }

    // Allowed - ElectricVehicle is non-sealed, so this compiles even
    // though ElectricScooter is NOT listed in Vehicle's permits clause
    static class ElectricScooter extends ElectricVehicle {
        @Override
        public String describe() { return "ElectricScooter (extends ElectricVehicle)"; }
    }

    static String classify(Vehicle vehicle) {
        return switch (vehicle) {
            case Car c -> "Four-wheeler: " + c.describe();
            case Truck t -> "Heavy vehicle: " + t.describe();
            case ElectricVehicle e -> "Electric: " + e.describe();
            // Still exhaustive - ElectricScooter IS-A ElectricVehicle, so
            // it matches THIS case. Vehicle's permits clause only lists
            // Car, Truck, and ElectricVehicle - the compiler does not
            // need (and cannot have) a separate case for ElectricScooter
        };
    }

    public static void main(String[] args) {
        System.out.println(classify(new Car()));
        System.out.println(classify(new Truck()));
        System.out.println(classify(new ElectricVehicle()));
        System.out.println(classify(new ElectricScooter()));
    }
}

Output:
Four-wheeler: Car
Heavy vehicle: Truck
Electric: ElectricVehicle
Electric: ElectricScooter (extends ElectricVehicle)

Multi-Level Sealed Hierarchies

A sealed type's permitted subtype can itself be sealed, with its own narrower permits list. A switch over the top-level type must still account for every concrete type reachable through that nested hierarchy - the compiler follows the chain all the way down.

Java

Try it out

// File: ShapeHierarchyDemo.java

public class ShapeHierarchyDemo {

    sealed interface Shape permits Circle, Polygon {}

    record Circle(double radius) implements Shape {}

    // Polygon is ITSELF sealed - it further restricts who can implement it
    sealed interface Polygon extends Shape permits Triangle, Square {}

    record Triangle(double base, double height) implements Polygon {}
    record Square(double side) implements Polygon {}

    static double area(Shape shape) {
        return switch (shape) {
            case Circle(double radius) -> Math.PI * radius * radius;
            case Triangle(double base, double height) -> 0.5 * base * height;
            case Square(double side) -> side * side;
            // Exhaustive across BOTH levels - Shape permits Circle and
            // Polygon; Polygon permits Triangle and Square. The compiler
            // verifies all THREE concrete shapes are handled here, even
            // though only TWO names appear in Shape's own permits clause
        };
    }

    public static void main(String[] args) {
        System.out.printf("Circle area   : %.2f%n", area(new Circle(3.0)));
        System.out.printf("Triangle area : %.2f%n", area(new Triangle(6.0, 4.0)));
        System.out.printf("Square area   : %.2f%n", area(new Square(5.0)));
    }
}

Output:
Circle area   : 28.27
Triangle area : 12.00
Square area   : 25.00

Real-World Example - Zerodha Order Execution Result

A trading platform's order execution result is a textbook closed set: an order is filled, partially filled, rejected, or still pending - exactly four possibilities, each carrying different data, and every part of the system that displays or acts on an order result needs to handle all four, with nothing left to a default guess.

Java

Try it out

// File: OrderResult.java

public sealed interface OrderResult permits Filled, PartiallyFilled, Rejected, Pending {}

record Filled(String orderId, int quantity, double averagePrice) implements OrderResult {}

record PartiallyFilled(String orderId, int filledQuantity, int remainingQuantity, double averagePrice)
    implements OrderResult {}

record Rejected(String orderId, String reason) implements OrderResult {}

record Pending(String orderId) implements OrderResult {}

Java

Try it out

// File: OrderResultService.java

import java.util.List;

public class OrderResultService {

    public String describeResult(OrderResult result) {
        return switch (result) {
            case Filled(String orderId, int quantity, double avgPrice) ->
                "Order " + orderId + " FILLED: " + quantity + " units @ Rs." + avgPrice;

            case PartiallyFilled(String orderId, int filled, int remaining, double avgPrice) ->
                "Order " + orderId + " PARTIALLY FILLED: " + filled + "/" + (filled + remaining)
                    + " units @ Rs." + avgPrice + " (remaining: " + remaining + ")";

            case Rejected(String orderId, String reason) ->
                "Order " + orderId + " REJECTED: " + reason;

            case Pending(String orderId) ->
                "Order " + orderId + " is PENDING - awaiting exchange confirmation";
        };
    }

    // A SECOND switch over the SAME sealed type - independently
    // exhaustive, with completely different logic. Sealed types are
    // designed for exactly this: many places can each handle "all of
    // OrderResult" their own way, and each one is checked separately.
    public boolean requiresFollowUp(OrderResult result) {
        return switch (result) {
            case Filled f -> false;
            case PartiallyFilled p -> true;
            case Rejected r -> true;
            case Pending p -> true;
        };
    }

    public static void main(String[] args) {
        OrderResultService service = new OrderResultService();

        List<OrderResult> results = List.of(
            new Filled("ORD-1001", 50, 2415.50),
            new PartiallyFilled("ORD-1002", 30, 20, 1899.75),
            new Rejected("ORD-1003", "Insufficient margin"),
            new Pending("ORD-1004")
        );

        System.out.println("=== Order results ===");
        for (OrderResult result : results) {
            System.out.println("  " + service.describeResult(result));
        }

        System.out.println();
        System.out.println("=== Orders requiring follow-up ===");
        for (OrderResult result : results) {
            if (service.requiresFollowUp(result)) {
                System.out.println("  " + service.describeResult(result));
            }
        }
    }
}

Output:
=== Order results ===
  Order ORD-1001 FILLED: 50 units @ Rs.2415.5
  Order ORD-1002 PARTIALLY FILLED: 30/50 units @ Rs.1899.75 (remaining: 20)
  Order ORD-1003 REJECTED: Insufficient margin
  Order ORD-1004 is PENDING - awaiting exchange confirmation

=== Orders requiring follow-up ===
  Order ORD-1002 PARTIALLY FILLED: 30/50 units @ Rs.1899.75 (remaining: 20)
  Order ORD-1003 REJECTED: Insufficient margin
  Order ORD-1004 is PENDING - awaiting exchange confirmation

describeResult uses record patterns to destructure each variant's fields directly in the case label; requiresFollowUp uses plain type patterns and asks a completely different question about the same four types. Both are exhaustive independently - if a fifth OrderResult variant is ever added to permits, both methods (and any other switch like them anywhere in the codebase) become compile errors until updated, which is precisely the point: a new order outcome cannot silently fall through either piece of logic unnoticed.

Best Practices

Reach for sealed types when a value is genuinely "one of a known, finite set of shapes" - not as a general-purpose replacement for interfaces. Order results, API response variants, AST/expression nodes, UI states, parsed-command types: these are closed by their very nature - there is no meaningful "fifth kind of OrderResult" waiting to be discovered by calling code. An interface meant for arbitrary, unforeseen implementations - a plugin contract, a strategy interface - should stay open.

Pair sealed interfaces with records for each variant. OrderResult permits Filled, PartiallyFilled, Rejected, Pending, with each variant a record, gives both a closed set of shapes AND value semantics for each shape's data - the combination this article has used throughout, and the one most discussions of "sealed types" in modern Java are really about.

Use non-sealed deliberately, and treat it as documentation. A non-sealed branch is a statement: "the closed-hierarchy guarantee intentionally stops here." It should be rare enough in a given hierarchy that, when it appears, a reader notices it and understands why - usually because that branch represents an extension point meant for code outside the module that owns the sealed type.

When adding a new permitted subtype breaks existing switches, that is the feature working - do not "fix" it with a default branch. Each compile error from an exhaustiveness check is the exact location that needs to handle the new case. Adding default -> /* do nothing */ to make the error go away defeats the entire reason for using a sealed type in the first place - it reintroduces the "silently ignored case" problem sealed types exist to eliminate.

Common Mistakes

Mistake 1 - A Permitted Subtype Missing final, sealed, or non-sealed

Java

Try it out

sealed interface Shape permits Circle, Rectangle {}

record Circle(double radius) implements Shape {} // records are implicitly final - fine

// WRONG - 'Rectangle' is permitted by Shape, but does not declare
// itself as final, sealed, or non-sealed. COMPILE ERROR:
// "class Rectangle is not final, sealed, or non-sealed"
class Rectangle implements Shape {
    double width;
    double height;
}

// CORRECT - every permitted subtype must declare what happens next.
// A plain class (not a record) needs one of the three explicitly.
final class RectangleFixed implements Shape {
    double width;
    double height;
}

Mistake 2 - Placing a Permitted Subtype in a Different Package

Java

Try it out

// File: shapes/Shape.java
package shapes;

// WRONG - permits names a class in a DIFFERENT package without a
// module relationship that allows it. COMPILE ERROR along the lines
// of: "class shapes.extra.Triangle is not allowed to extend sealed
// class shapes.Shape because shapes.extra.Triangle is in a different
// package/module"
public sealed interface Shape permits shapes.Circle, shapes.extra.Triangle {}

// CORRECT - keep permitted subtypes in the SAME package (or, with
// modules, the same module) as the sealed type itself
// File: shapes/Triangle.java
package shapes;

final class Triangle implements Shape {
    double base;
    double height;
}

Mistake 3 - Adding a default to Silence an Exhaustiveness Error

Java

Try it out

sealed interface OrderResult permits Filled, PartiallyFilled, Rejected, Pending {}
// ... record declarations ...

// A new variant is added to the permits clause:
// sealed interface OrderResult permits Filled, PartiallyFilled, Rejected, Pending, Cancelled {}
// record Cancelled(String orderId) implements OrderResult {}

// WRONG - the switch below now fails to compile because it does not
// cover Cancelled. Adding 'default' makes it compile again, but
// SILENTLY drops every Cancelled order into whatever the default does
String describe(OrderResult result) {
    return switch (result) {
        case Filled f -> "Filled";
        case PartiallyFilled p -> "Partially filled";
        case Rejected r -> "Rejected";
        case Pending p -> "Pending";
        default -> "Unknown"; // defeats the purpose of sealing OrderResult
    };
}

// CORRECT - add the missing case. This is the exhaustiveness check
// doing exactly what it is for: finding every place Cancelled needs
// to be handled, at compile time
String describeFixed(OrderResult result) {
    return switch (result) {
        case Filled f -> "Filled";
        case PartiallyFilled p -> "Partially filled";
        case Rejected r -> "Rejected";
        case Pending p -> "Pending";
        case Cancelled c -> "Cancelled";
    };
}

Mistake 4 - Confusing sealed With final

Java

Try it out

// WRONG ASSUMPTION - 'final' on Shape would mean NOTHING can ever
// implement or extend it - but Shape is meant to have several
// implementations (Circle, Rectangle). 'final' on an interface is
// not even valid; on a class, it would prevent ALL subclassing,
// not describe a closed SET of subclasses.
final class Shape { } // cannot be implemented/extended AT ALL

// CORRECT - 'sealed' with 'permits' describes a CLOSED SET of
// allowed subtypes - "exactly these, and no others" - which is a
// different statement from 'final's "no subtypes at all"
sealed interface ShapeFixed permits Circle, Rectangle {}
record Circle(double radius) implements ShapeFixed {}
record Rectangle(double width, double height) implements ShapeFixed {}

// 'final' is still the right choice for an individual VARIANT - it
// says "this specific shape has no further subtypes," which is a
// different statement, made at a different level of the hierarchy

Interview Questions

Q1. What is a sealed class or interface in Java, and what problem does it solve?

A sealed class or interface, finalized in Java 17, declares - via the sealed modifier and a permits clause - the complete, closed set of types allowed to directly extend or implement it. It solves the problem of representing "one of a few specific things, and nothing else" as a type: before sealed types, any interface or non-final class was open to implementation by any class anywhere, so code handling "every possible subtype" always needed a fallback branch for cases the compiler could not rule out. A sealed type lets the compiler verify that a fixed list is genuinely complete, both by preventing unlisted subtypes from existing and by checking that code handling the type's subtypes covers all of them.

Q2. What are the three options for a direct subtype of a sealed type, and what does each mean?

Every type named in a sealed type's permits clause must itself be exactly one of final, sealed, or non-sealed. final means the hierarchy ends at that type - it cannot be extended further. sealed means that type can be extended, but only by types in ITS OWN permits clause - creating a multi-level closed hierarchy. non-sealed means the closed-hierarchy guarantee deliberately stops at that type - from there onward, any class anywhere can extend it normally, as if it were an ordinary open type. Records satisfy the final requirement automatically, since records are implicitly final.

Q3. When can the permits clause be omitted, and why?

permits can be omitted if every type that implements or extends the sealed type is declared in the same source file as the sealed type itself. In that case, the compiler scans the rest of the file, finds every type that names the sealed type in an implements or extends clause, and treats that as the permitted list automatically. This is common for small, self-contained hierarchies - a sealed interface with two or three record implementations, all in one file - where writing out permits would just repeat information already visible a few lines later.

Q4. How does a sealed type enable exhaustive switch, and what Java version is required for that?

Because a sealed type's complete set of permitted subtypes is known to the compiler, a switch using pattern matching (type patterns like case Circle c ->, or record patterns like case Circle(double radius) ->) can be checked for exhaustiveness - the compiler verifies every permitted subtype (including, recursively, the permitted subtypes of any permitted subtype that is itself sealed) is covered by some case, and a default branch becomes unnecessary. Sealed type declarations themselves are available from Java 17, but pattern matching for switch - the feature that makes this exhaustiveness checking possible - was finalized in Java 21, after preview status starting in 17. On Java 17 through 20, the same switch-based exhaustiveness requires enabling the relevant preview feature.

Q5. Can a sealed interface have implementations in a different package or module?

Only if the sealed type and the permitted subtype are in the same module (when modules are used) - in that case, they can be in different packages within that module. Without modules, every permitted subtype must be in the same package as the sealed type. This restriction exists because the closed-set guarantee would be meaningless if any code, anywhere, with access to the sealed type could add a new implementation from an unrelated package - the compiler needs to see and verify the entire permitted set, which it can only do within these boundaries.

Q6. How do sealed types and records work together, and why is this combination significant?

A sealed interface with record implementations gives a value two guarantees at once: the set of possible "shapes" the value can take is closed and verified by the compiler (from sealed), and each shape's data has value-based equality, an automatically generated toString(), and immutability (from record). Combined with pattern matching for switch and record patterns, this lets code destructure and exhaustively handle "one of N specific data shapes" - Filled, PartiallyFilled, Rejected, Pending, in the example above - with no default branch, no manual instanceof casts, and a compile error at every affected location if a new shape is ever added. This combination is often referred to as Java's approach to algebraic data types, familiar from functional languages, expressed using features the language already had individually.

FAQs

Can a sealed class be extended by an anonymous class?

No. An anonymous class's supertype would not appear in the sealed type's permits clause, so it would violate the closed-set guarantee - the compiler rejects this. If a one-off implementation is needed, it must be one of the types already listed in permits, used directly (records, in particular, are very commonly used this way - each permitted "shape" is just a record, with no need for one-off implementations at all).

Can an enum be a permitted subtype of a sealed interface?

Yes. An enum can implement an interface, including a sealed one - declaring enum Status implements StatusLike where StatusLike is a sealed interface permitting Status among its implementations is valid. Since an enum's set of constants is itself closed, combining an enum with a sealed interface is sometimes used when some "shapes" in a closed set are simple, valueless constants (a good fit for enum constants) while others carry data (a good fit for records).

What happens if a switch over a sealed type doesn't cover all permitted subtypes?

With pattern matching for switch (Java 21), this is a compile error - the switch expression or statement is rejected as non-exhaustive, naming which permitted subtype(s) are not covered. This is the entire point of combining switch with a sealed type: an incomplete switch over a sealed type's subtypes cannot compile, whereas an incomplete switch (or if-else chain) over an ordinary open type compiles fine and simply produces no result - or a default - for unhandled cases at runtime.

Can a sealed class have non-sealed, sealed, AND final subtypes all at once?

Yes - each permitted subtype chooses independently. sealed interface Vehicle permits Car, Truck, ElectricVehicle could have Car and Truck as final while ElectricVehicle is non-sealed, exactly as in this article's example, or ElectricVehicle could instead be sealed with its own further-restricted permits. There is no requirement that all permitted subtypes use the same option.

Is sealed the same as final?

No, and the difference is the entire point of the feature. final on a class means it cannot be extended or implemented by anything, ever - there is no hierarchy below it at all. sealed (with permits) on a class or interface means it CAN be extended or implemented, but only by a specific, closed, named set of types - there IS a hierarchy below it, and that hierarchy's membership is fixed and known. A sealed interface with several record implementations has a real hierarchy of several types; a final class has none.

Can a sealed interface extend a non-sealed interface, or vice versa?

A sealed interface can extend any interface, sealed or not - sealed interface Polygon extends Shape permits Triangle, Square extends Shape, regardless of whether Shape itself is sealed. A non-sealed interface extending a sealed interface is more unusual: if Shape is sealed and permits Polygon, then Polygon itself must be final, sealed, or non-sealed - if Polygon chooses non-sealed, it reopens extension from that point, exactly as non-sealed does for classes, while still being one of Shape's explicitly permitted types.

Summary

A sealed type turns "these are all the kinds of X that exist" from a comment or a naming convention into something the compiler verifies - both that nothing outside the permitted list can claim to be an X, and, with pattern matching for switch from Java 21, that code handling "every kind of X" genuinely does. Every permitted subtype must say, explicitly, what happens next: final ends the hierarchy there, sealed continues it under a new, narrower closed list, and non-sealed deliberately reopens it.

The combination this article keeps returning to - a sealed interface, one record per permitted shape, and an exhaustive switch with record patterns - is worth recognizing on sight. It is the modern Java answer to "this value is one of a few specific things, each with its own data, and every place that handles it needs to handle all of them."

The practical habit worth carrying forward: when a new variant needs to be added to a sealed type's permits, the compile errors that follow at every now-incomplete switch are not a problem to work around - they are the complete, precise list of every place that needs to learn about the new variant, found before the code ever runs.

What to Read Next

Continue Learning Advanced OOP

Next Step

Immutable Classes

Learn how to design a class whose objects can never change.

→

Records (Java 16+)

Learn Java's shortcut for simple data-holding classes.

→

public Access Modifier

Learn what the public modifier allows other code to do.

→

Anonymous Classes

Learn how to create a one-off class without naming it.

→

←

PreviousRecords (Java 16+)

NextImmutable Classes

→