Both features have been stable since Java 17 and 21. Most articles show the syntax. Almost none explain how they change library design, error modelling, and what you owe callers when you add a new variant to a hierarchy. This one does.

1. The Adoption Gap and Why It Exists

Records have been a success story. BellSoft’s 2024 Java Developer Survey found that 55% of developers now use them regularly — remarkable for a feature that shipped in Java 16, just four years ago. Sealed classes, which arrived a release later and are deeply intertwined with records, haven’t come close to that number. Estimates from the same survey period suggest adoption in the low-to-mid teens, percentage-wise.

The gap isn’t hard to explain. Records solve an old, familiar problem that every Java developer has complained about for decades: data-carrying classes with fifteen lines of boilerplate. You see the before and after immediately, and the win is obvious. Sealed classes solve a subtler problem — one that lives at the level of API design and type modelling, not boilerplate reduction. If you don’t already think about your codebase in terms of closed hierarchies and exhaustive case handling, sealed classes look like a restriction rather than a tool.

That perceptual problem is compounded by how most articles introduce the feature. They show you the syntax, give you a Shape example with Circle and Rectangle, and move on. What they skip is the architectural question: when should I seal a type, and what does that decision mean for the people who call my code? That’s what this article addresses.

2. What Sealed Classes Actually Are: ADTs Explained

The clearest way to understand sealed classes is through the lens of algebraic data types, which Java finally has proper support for after decades of workarounds. The terminology can sound academic, but the idea is simple: some types in your domain are open — anyone can add a new implementation — and some are closed — the complete set of possibilities is fixed and known at compile time.

Java has always supported open types through interfaces and abstract classes. Before Java 17, it had no real mechanism for closed types. The closest approximations were enums (closed, but carrying no per-variant data) and abstract classes with package-private constructors (closed by convention, not by contract). Both are hacks. Sealed classes are the real thing.

Sum types and product types

In type theory, a product type combines multiple fields (a record is exactly this — a Point(int x, int y) is a product of two integers). A sum type says a value is one of a fixed set of alternatives. Sealed interfaces are Java’s sum types. The combination — a sealed interface with record implementations — is an algebraic data type, or ADT. Haskell, Scala, Rust, and OCaml developers have had these natively for decades. Java now has them too, just with more ceremony.

Here’s what that looks like when applied to a real domain concept — a payment result — rather than an academic shape hierarchy:

public sealed interface PaymentResult
 permits PaymentResult.Success,
 PaymentResult.Declined,
 PaymentResult.GatewayTimeout {

 record Success(String transactionId, BigDecimal amount)
 implements PaymentResult {}

 record Declined(String reason, boolean canRetry)
 implements PaymentResult {}

 record GatewayTimeout(Duration elapsed)
 implements PaymentResult {}
}

Notice what this does that an enum cannot: each variant carries its own, different data. A Success has a transaction ID and an amount. A Declined has a reason and a retry flag. A GatewayTimeout has elapsed duration. No variant shares the same shape. You can’t model this cleanly with a traditional enum without adding nullable fields or maps, which collapses type safety entirely.

Furthermore, notice what this does that an open interface cannot: the compiler knows, at compile time, that PaymentResult has exactly three possible shapes. That knowledge is the foundation of everything that follows.

3. Exhaustiveness Is a Refactoring Tool, Not a Syntax Feature

The most commonly cited benefit of sealed classes is that you can write a switch without a default branch. That framing undersells it considerably. The real benefit is what happens six months later, when a fourth variant is added to the hierarchy.

Without sealed classes and exhaustive switching, adding a new subtype is silent. You update the hierarchy, ship the code, and any instanceof chains or switch statements elsewhere that don’t handle the new case just fall through to whatever default behaviour they have — if they have any at all. The bug is discovered at runtime, probably in production, probably by a user.

With a sealed hierarchy and exhaustive switch expressions, the opposite happens. As the OpenJDK design notes explain, adding a new permitted type to a sealed interface immediately breaks every switch expression that handled the type without a default clause. The compiler refuses to compile. You get a list of every call site that now needs updating. The bug is discovered at compile time, by you, before anything ships.

“Case analysis is a deep, ingrained part of programming. Having basic checks like the fact that your case analysis is exhaustive is very powerful. As your code evolves, you can use these exhaustiveness checks to figure out where you need to fix things.”— Yaron Minsky, Jane Street, on algebraic types. Quoted in Algebraic Types on the JVM

This is not a syntax improvement. It’s a change in what the compiler knows about your domain and what it can therefore check on your behalf. The implication for API design is significant: if you’re writing a method that returns one of a finite set of outcomes, the difference between returning an open interface and a sealed one is the difference between hoping callers handle all cases and guaranteeing they’re forced to.

Concretely, this is what a call site looks like under Java 21 exhaustive pattern matching:

PaymentResult result = paymentService.process(order);

String message = switch (result) {
 case PaymentResult.Success s ->
 "Paid. Tx ID: " + s.transactionId();
 case PaymentResult.Declined d when d.canRetry() ->
 "Declined — retrying. Reason: " + d.reason();
 case PaymentResult.Declined d ->
 "Declined. Reason: " + d.reason();
 case PaymentResult.GatewayTimeout t ->
 "Timed out after " + t.elapsed().toSeconds() + "s";
}; 

The when guard on Declined is worth noting. Pattern matching lets you refine a case with an arbitrary boolean predicate — giving you the expressiveness of a full conditional tree inside a tightly typed switch expression. You’re not choosing between type safety and nuance; you get both.

4. Error Modelling: Beyond Optional and Exceptions

This is where sealed classes change library design most concretely. Java has two traditional mechanisms for signalling failure: checked exceptions and Optional. Both have known problems that have been debated for twenty years.

Checked exceptions force callers to handle errors, but they can’t carry structured data about the failure without custom exception subclasses. They’re also infectious — they propagate through call stacks in ways that are hard to compose. Optional collapses success and failure into a single binary: present or absent. It tells you nothing about why something is absent. And neither mechanism supports the pattern of “there are several distinct, structured failure modes, each with its own data.”

Sealed interfaces with records make that pattern first-class. The SoftwareMill team demonstrates this well with a generic Result type:

public sealed interface Result<E, A>
 permits Result.Success, Result.Failure {

 record Success<E, A>(A value) implements Result<E, A> {}
 record Failure<E, A>(E error) implements Result<E, A> {}
}

// The error type E is itself a sealed type — structured failure
public sealed interface PaymentError
 permits PaymentError.InsufficientFunds,
 PaymentError.CardExpired,
 PaymentError.FraudBlock {

 record InsufficientFunds(BigDecimal shortfall) implements PaymentError {}
 record CardExpired(YearMonth expiry) implements PaymentError {}
 record FraudBlock(String ruleId) implements PaymentError {}
}

// At the call site — all cases forced, no swallowed exceptions
Result<PaymentError, String> result = service.charge(card, amount);
switch (result) {
 case Result.Success<PaymentError, String> s ->
 notify(s.value());
 case Result.Failure<PaymentError, String> f -> switch (f.error()) {
 case PaymentError.InsufficientFunds e -> showFundsError(e.shortfall());
 case PaymentError.CardExpired e -> promptCardUpdate(e.expiry());
 case PaymentError.FraudBlock e -> contactSupport(e.ruleId());
 };
}

This is, as Puspalata Sahoo puts it, a shift from runtime surprises to compile-time guarantees. Adding a new PaymentError variant — say, NetworkUnavailable — immediately breaks every call site that handles errors exhaustively. The compiler has turned “the developer forgot to handle this case” from a runtime bug into a build failure. That’s a fundamentally different kind of safety guarantee.

Error Handling Mechanism Comparison

5. Killing the Visitor Pattern

The Visitor pattern exists to solve exactly one problem: how do you add new operations to a fixed type hierarchy without modifying every type in it? The answer, before Java 17, was a double-dispatch mechanism involving an accept(Visitor v) method on each element type and a separate visitor interface with one visit method per element. It works. It is also notoriously verbose, hard to discover, and requires explaining to every new team member.

Sealed classes with pattern matching solve the same problem with vastly less machinery. As Nicolai Parlog argues convincingly, when you add a new type to a sealed interface, all pattern switches without a default branch become non-exhaustive and fail to compile — exactly the same safety guarantee the Visitor pattern provides, but without the boilerplate.

The safety guarantee is identical. Adding a fourth Shape — say, Hexagon — causes the visitor approach to break at the ShapeVisitor interface level (every implementor must add visit(Hexagon h)) and causes the switch approach to break at every call site without a default. Both guide you to exactly where you need to make changes. The switch version simply requires a fraction of the setup code and is readable without a design-pattern handbook.

6. The API Design Shift

If you’re designing a library or a service interface rather than application code, sealed classes change a specific conversation: what do you promise callers, and what can you take away without breaking them?

An open interface is a promise that callers can add implementations. That’s the right choice when extensibility is the point — a plugin API, a strategy interface, anything where callers are supposed to supply their own types. A sealed interface is the opposite promise: callers can consume the hierarchy, but they cannot extend it. In exchange for giving up extensibility, you give callers compiler-guaranteed exhaustiveness.

There is also a versioning dimension that often gets ignored. When you seal a public API type — one that callers outside your module see — adding a new permitted type is a breaking change. Every caller with an exhaustive switch that previously compiled now won’t. That’s good for correctness; it’s disruptive for library maintainers. The OpenJDK design notes are candid about this: subtypes can be less accessible than the sealed parent, which means callers who can’t see the subtypes can’t write exhaustive switches and must use a default clause — a deliberate partial mitigation.

Versioning advice for library authors

If you’re sealing a public API type, treat adding a new variant the same way you’d treat removing a method — it’s a major version bump under semantic versioning. Document your sealed hierarchies explicitly. Callers who pin to a minor version and rely on exhaustive switches will break on next release if you add a variant silently. The compiler enforces this, which is the point, but it should also inform your release planning.

7. The Open/Closed Principle Tension

A fair objection arises here. SOLID’s Open/Closed Principle says software entities should be open for extension, closed for modification. Sealed classes are literally closed for extension by outside parties. Does that violate OCP?

The short answer is: it depends on what you mean by extension, and OCP was written before sum types existed as a first-class option in mainstream OO languages. The longer answer is that OCP was designed around the fear of modifying existing code. Sealed hierarchies don’t require modifying existing code when you add operations — you just write a new method with a new switch. They only require modification when you add new variants, and they make that modification safe by ensuring you handle all the call sites.

When sealed is the right choice for OCP

If your domain has a fixed set of cases and you expect to add many new operations over those cases over time, sealed classes are more OCP-aligned than an open hierarchy. You extend by adding new switch-based operations without touching the data model. If you expect to add new cases frequently, an open interface is still the right choice — sealed just adds friction where you need flexibility.

The real insight is that sealed classes flip the extensibility axis. An open interface is easy to extend with new types but hard to extend with new operations safely. A sealed interface is easy to extend with new operations (just write a new switch) but requires deliberate, breaking changes to add new types. The question “should I seal this?” is really the question “which axis of extensibility matters more for this type?”

Feature Adoption — Modern Java Language Features (2024–2025)

8. What We Have Learned

Sealed classes and exhaustive pattern matching are not syntax improvements. They are a change in what Java’s type system can express and what its compiler can check. The key shift is this: for the first time, a Java method can return a type where the compiler guarantees callers have handled every possible shape — not because they’re disciplined, but because the code won’t compile if they haven’t.

That guarantee changes how you model errors. Instead of checked exceptions that carry no structured data, or Optional that throws away failure information, you can define a sealed error hierarchy where each variant carries exactly the fields it needs and the caller is forced to address all of them. It changes how you design return types: a sealed interface communicating a finite set of outcomes is a clearer, safer contract than a wide-open interface.

It also changes the Visitor pattern from a necessary ceremony into an unnecessary one. The exhaustiveness guarantee the Visitor pattern provides through a double-dispatch mechanism is now provided by the compiler for free, whenever you switch over a sealed type without a default branch.

The adoption gap relative to records exists because sealed classes solve an architectural problem, and most tutorials only show the syntax. The real question — when do I seal a type? — is answered by a second question: do you want callers to be able to add implementations, or do you want to guarantee they’ve handled all your implementations? If the answer is the latter, sealed is the right keyword. And if you’re adding a new variant later and the compiler floods you with errors, that’s not a problem — that’s the feature working exactly as designed.