Java has always provided different ways to control how classes and interfaces are used.
For example, you can use:
finalto prevent inheritanceabstractto require subclassesprivateto control access- Interfaces to define contracts
But what if you want something in between?
What if you want a class to be extendable, but only by specific classes?
That’s exactly where sealed classes come in.
A sealed class lets you explicitly control which classes are allowed to extend it.
Sealed classes were introduced as a preview feature in Java 15 and became a permanent language feature in Java 17.
They are particularly useful when you know the complete set of valid subclasses and want the compiler to understand that hierarchy.
In this beginner-friendly guide, we’ll explore Java sealed classes from the basics to practical examples.
We’ll cover:
- What sealed classes are
- Why sealed classes were introduced
sealedpermitsfinalnon-sealed- Sealed interfaces
- Inheritance rules
- Pattern matching
- Exhaustive
switch - Records and sealed classes
- Real-world examples
- Sealed classes vs
final - Sealed classes vs abstract classes
- Common mistakes
- Best practices
Let’s get started.
What Is a Sealed Class?
A sealed class is a class that restricts which other classes can extend it.
For example:
public sealed class Payment
permits CardPayment, BankPayment {
}
Here, Payment can only be extended by:
CardPayment
BankPayment
A different class cannot simply write:
public class CryptoPayment
extends Payment {
}
unless it is included in the permitted hierarchy.
The idea is:
Payment
│
┌────────┴────────┐
↓ ↓
CardPayment BankPayment
The hierarchy is explicitly controlled.
Why Do We Need Sealed Classes?
Before sealed classes, Java gave you two common options.
Option 1: Allow Everyone to Extend
public class Payment {
}
Any class can extend it:
public class CardPayment
extends Payment {
}
public class BankPayment
extends Payment {
}
public class CryptoPayment
extends Payment {
}
You have little control over the inheritance hierarchy.
Option 2: Prevent Everyone from Extending
You could make the class final:
public final class Payment {
}
Now:
Payment
↓
No subclasses allowed
But sometimes you want controlled inheritance.
That’s where sealed classes fit.
Open class
↓
Anyone can extend
Final class
↓
Nobody can extend
Sealed class
↓
Only approved classes can extend
Basic Sealed Class Syntax
The basic syntax is:
public sealed class Payment
permits CardPayment, BankPayment {
}
There are two important keywords here:
sealed
permits
sealed declares that the class restricts inheritance.
permits specifies which classes are allowed to extend it.
Creating a Permitted Subclass
If a class is permitted to extend a sealed class, it must declare how the inheritance should continue.
For example:
public final class CardPayment
extends Payment {
}
And:
public final class BankPayment
extends Payment {
}
The hierarchy becomes:
Payment
│
├── CardPayment
│
└── BankPayment
Because both subclasses are final, no further class can extend them.
Why Must Subclasses Declare final, sealed, or non-sealed?
A direct subclass of a sealed class must explicitly choose one of three possibilities:
final
sealed
non-sealed
For example:
public final class CardPayment
extends Payment {
}
or:
public sealed class OnlinePayment
extends Payment
permits CardPayment {
}
or:
public non-sealed class OtherPayment
extends Payment {
}
This tells Java how the inheritance hierarchy should continue.
The final Modifier
If a permitted subclass is final:
public final class CardPayment
extends Payment {
}
then nobody can extend CardPayment.
The hierarchy ends there.
Payment
↓
CardPayment
↓
STOP
This is useful when you want a specific concrete type that cannot be further specialized.
The sealed Modifier on a Subclass
A permitted subclass can itself be sealed.
For example:
public sealed class OnlinePayment
extends Payment
permits CardPayment, WalletPayment {
}
Now you have a deeper hierarchy:
Payment
│
↓
OnlinePayment
/ \
↓ ↓
CardPayment WalletPayment
Each level can control its own permitted subclasses.
The non-sealed Modifier
Sometimes you want the top-level class to restrict its direct subclasses, but you want one of those subclasses to become open for further inheritance.
That’s what non-sealed does.
For example:
public non-sealed class OnlinePayment
extends Payment {
}
Now other classes can extend OnlinePayment.
Payment
↓
OnlinePayment
↓
Anyone can extend
So non-sealed effectively opens that branch of the hierarchy again.
Sealed Class Example
Let’s build a complete example.
public sealed class Notification
permits EmailNotification,
SmsNotification,
PushNotification {
}
Now create the permitted classes:
public final class EmailNotification
extends Notification {
}
public final class SmsNotification
extends Notification {
}
public final class PushNotification
extends Notification {
}
The hierarchy is:
Notification
│
┌────────────┼────────────┐
↓ ↓ ↓
Email SMS Push
Now Java knows exactly which notification types are allowed.
What Happens If We Add an Unauthorized Subclass?
Suppose we try:
public final class WhatsAppNotification
extends Notification {
}
But WhatsAppNotification isn’t listed in:
permits
Java will reject the code.
This is one of the main benefits of sealed classes.
The inheritance hierarchy is enforced by the compiler.
Explicit permits
You can explicitly list the permitted classes:
public sealed class Notification
permits EmailNotification,
SmsNotification,
PushNotification {
}
This makes the allowed hierarchy very clear.
For larger hierarchies, explicit permits can also improve readability because someone reading the class can immediately see its direct subclasses.
When Can You Omit permits?
In certain situations, the permitted subclasses can be inferred when the relevant classes are declared in the same compilation unit.
For example:
public sealed class Payment
permits CardPayment, BankPayment {
}
is explicit and easy to understand.
If the compiler can infer the permitted subclasses based on the source structure, Java allows the permits clause to be omitted in the applicable cases.
For beginners, explicit permits is often easier to understand.
Sealed Interfaces
Sealed classes aren’t limited to classes.
You can also create a sealed interface.
For example:
public sealed interface PaymentMethod
permits CardPayment,
BankTransfer {
}
Then:
public final class CardPayment
implements PaymentMethod {
}
And:
public final class BankTransfer
implements PaymentMethod {
}
The hierarchy becomes:
PaymentMethod
/ \
↓ ↓
CardPayment BankTransfer
Sealed Interface with Records
Sealed interfaces work particularly well with Java records.
For example:
public sealed interface Result
permits Success, Failure {
}
Then:
public record Success(
String value
) implements Result {
}
And:
public record Failure(
String message
) implements Result {
}
Records are implicitly final, so they naturally fit into a sealed hierarchy.
Sealed Classes and Pattern Matching
Sealed classes become particularly powerful when combined with Java’s pattern matching features.
Suppose:
public sealed interface Result
permits Success, Failure {
}
with:
public record Success(
String value
) implements Result {
}
and:
public record Failure(
String message
) implements Result {
}
You can use pattern matching in a switch:
static String describe(Result result) {
return switch (result) {
case Success success ->
"Success: " + success.value();
case Failure failure ->
"Failure: " + failure.message();
};
}
Because the compiler knows that Result has only these permitted implementations, it can determine that the cases are exhaustive.
What Does Exhaustive Mean?
Exhaustive means all possible cases are handled.
Without a sealed hierarchy, imagine:
Result
├── Success
├── Failure
├── Pending
├── Cancelled
└── Unknown
You may need to consider many possible implementations.
With:
Result
├── Success
└── Failure
Java knows the complete permitted set.
So a switch can cover:
Success ✓
Failure ✓
and the compiler knows there are no other direct permitted implementations to handle.
This makes sealed types especially useful for representing a closed set of alternatives.
Sealed Classes and Domain Modeling
One of the best uses of sealed classes is modeling a domain where only a known set of types is valid.
For example:
Payment
├── CardPayment
├── BankPayment
└── CashPayment
Or:
OrderStatus
├── Pending
├── Confirmed
├── Shipped
└── Cancelled
Or:
Result
├── Success
└── Failure
The compiler understands the structure instead of treating the base type as completely open.
Real-World Example: API Result
Imagine a service method that returns either success or failure.
You could model it as:
public sealed interface ApiResult
permits Success, Error {
}
Success:
public record Success(
String data
) implements ApiResult {
}
Error:
public record Error(
String message,
int status
) implements ApiResult {
}
Now a method can return:
public ApiResult getUser() {
if (userExists()) {
return new Success("User found");
}
return new Error(
"User not found",
404
);
}
The caller knows that the result is one of the defined types.
Sealed Classes vs Final Classes
These two are easy to confuse.
Final Class
public final class Payment {
}
Means:
Payment
↓
No inheritance
Sealed Class
public sealed class Payment
permits CardPayment,
BankPayment {
}
Means:
Payment
├── CardPayment
└── BankPayment
So:
final → No subclasses
sealed → Specific subclasses only
Sealed Classes vs Abstract Classes
An abstract class can be extended by any class that has access to it, unless additional restrictions are used.
For example:
public abstract class Payment {
}
Potentially:
Payment
├── CardPayment
├── BankPayment
├── CryptoPayment
├── CashPayment
└── AnythingElse
With a sealed class:
public sealed class Payment
permits CardPayment,
BankPayment {
}
the hierarchy is closed to the permitted types.
So:
abstract → Inheritance allowed
sealed → Controlled inheritance
Sealed Classes vs Interfaces
A sealed interface is useful when you want multiple unrelated classes to implement a controlled contract.
For example:
public sealed interface Shape
permits Circle,
Rectangle,
Triangle {
}
The implementing classes don’t need to share a common class hierarchy beyond implementing the interface.
This can be a great fit for modeling a fixed set of alternatives.
Sealed Classes and Records
Records and sealed types complement each other nicely.
For example:
public sealed interface PaymentResult
permits Success, Failure {
}
Then:
public record Success(
String transactionId
) implements PaymentResult {
}
and:
public record Failure(
String reason
) implements PaymentResult {
}
You get:
Sealed Interface
↓
Known Types
↓
Immutable Records
This is a clean approach for many data-modeling scenarios.
Sealed Classes and Generics
Sealed interfaces can also be generic.
For example:
public sealed interface Result<T>
permits Success, Failure {
}
Then:
public record Success<T>(
T value
) implements Result<T> {
}
and:
public record Failure<T>(
String message
) implements Result<T> {
}
This allows the result to carry different types of data while keeping the set of result variants controlled.
Sealed Classes and Package Rules
Java also places restrictions around where permitted subclasses can be declared.
For a sealed hierarchy, the compiler must be able to determine the permitted types.
Depending on how the classes are organized, permitted subclasses need to be appropriately related through the same module or package rules.
In a simple beginner project, keeping the related classes together makes the relationship easy to understand.
Sealed Classes in Java 17
Sealed classes became a permanent feature in Java 17.
So if you’re learning modern Java, you can use them directly in Java 17+ projects.
For example:
public sealed class Vehicle
permits Car, Bike {
}
This is one reason modern Java has become more expressive for modeling data and domain hierarchies.
Why Sealed Classes Improve Code
Sealed classes provide several benefits.
Better Control
You decide which classes can extend the base type.
Better Domain Modeling
You can clearly represent a closed set of valid types.
Compiler Assistance
The compiler understands the permitted hierarchy.
Safer Refactoring
Adding a new permitted subtype can reveal places where the application needs to handle the new case.
Better Pattern Matching
Sealed types work especially well with pattern matching and exhaustive switch expressions.
Clearer Design
The inheritance relationship is explicit.
A Complete Example
Let’s build a small payment system.
Base interface:
public sealed interface Payment
permits CardPayment,
BankPayment,
CashPayment {
}
Card payment:
public record CardPayment(
String cardNumber
) implements Payment {
}
Bank payment:
public record BankPayment(
String accountNumber
) implements Payment {
}
Cash payment:
public record CashPayment(
double amount
) implements Payment {
}
Now we can process payments:
public static String process(
Payment payment
) {
return switch (payment) {
case CardPayment card ->
"Processing card payment";
case BankPayment bank ->
"Processing bank payment";
case CashPayment cash ->
"Processing cash payment";
};
}
The code is easy to understand:
Payment
│
├── CardPayment
├── BankPayment
└── CashPayment
The compiler knows these are the permitted implementations.
Adding a New Payment Type
Suppose we add:
public record WalletPayment(
String walletId
) implements Payment {
}
We also need to add it to the sealed interface:
public sealed interface Payment
permits CardPayment,
BankPayment,
CashPayment,
WalletPayment {
}
Now any exhaustive switch over Payment may need a new case:
case WalletPayment wallet ->
"Processing wallet payment";
This is useful because the compiler can help identify code that needs to be updated when the domain model changes.
When Should You Use Sealed Classes?
Sealed classes are a good fit when:
The Set of Types Is Known
For example:
Success
Failure
You Want a Closed Hierarchy
You don’t want unknown third-party subclasses.
Pattern Matching Is Useful
You want to handle every possible type safely.
Domain Rules Are Important
The application has a clearly defined set of valid states or variants.
When Should You Avoid Sealed Classes?
Don’t use sealed classes simply because they are a new Java feature.
They may not be appropriate when:
- Third-party code needs to extend your class
- New implementations should be added freely
- Your hierarchy is intentionally open
- The restrictions don’t provide meaningful value
For example, a plugin architecture may intentionally require external implementations.
A sealed interface would work against that design.
Common Mistakes
1. Forgetting final, sealed, or non-sealed
A direct subclass of a sealed class must specify how inheritance continues.
For example:
public class CardPayment
extends Payment {
}
is not enough if Payment is sealed.
Instead, use:
public final class CardPayment
extends Payment {
}
or one of the other permitted modifiers.
2. Forgetting the permits List
If the compiler cannot infer the permitted types, you need to declare them.
public sealed class Payment
permits CardPayment, BankPayment {
}
3. Making Everything Sealed
Sealed classes are useful for closed hierarchies, not every inheritance relationship.
Use them when the restriction represents a real design rule.
4. Confusing sealed with final
Remember:
final → Nobody can extend
sealed → Only approved classes can extend
5. Ignoring Exhaustive Handling
One of the major advantages of sealed types is compiler knowledge of the hierarchy.
Take advantage of that when using pattern matching and switch.
Sealed Classes and Clean Architecture
Sealed types can help make domain models more explicit.
For example:
Domain Result
│
┌────┴────┐
↓ ↓
Success Failure
Instead of returning loosely structured data and relying on conventions, the type system can communicate the possible outcomes.
This can make code easier to reason about and reduce certain classes of invalid states.
Sealed Classes vs Enums
You might wonder:
“Why not just use an enum?”
Enums are excellent when you have a fixed set of simple constants.
For example:
enum OrderStatus {
PENDING,
CONFIRMED,
CANCELLED
}
But what if each variant needs different data?
For example:
Success → data
Failure → error message
A sealed hierarchy can represent this much more naturally:
Result
├── Success(data)
└── Failure(message)
So:
Enum
→ Fixed values
Sealed types
→ Fixed types with potentially different data and behavior
Sealed Classes vs Polymorphism
Sealed classes don’t eliminate polymorphism.
They provide controlled polymorphism.
For example:
Payment payment =
new CardPayment("1234");
You can still treat the object as the parent type:
Payment payment;
while knowing that only permitted types can exist within the hierarchy.
This combines flexibility with stronger constraints.
Best Practices
Use Sealed Types for Closed Domains
Use them when the set of valid implementations is intentionally limited.
Combine with Records When Appropriate
Records work very well for immutable data variants.
Use Pattern Matching
Take advantage of the compiler’s knowledge of the hierarchy.
Keep Hierarchies Simple
A sealed hierarchy should be understandable.
Choose final, sealed, or non-sealed Carefully
Each modifier communicates a different design intention.
Don’t Seal Public Extension Points Unnecessarily
If developers or external systems are expected to implement your interface, sealing it may be the wrong choice.
Quick Cheat Sheet
Remember these three keywords:
sealed
↓
Controls inheritance
permits
↓
Lists allowed subclasses
non-sealed
↓
Re-opens a branch for inheritance
And:
final
↓
Stops inheritance completely
So a hierarchy might look like:
Payment
[sealed]
│ ┌─────────┴─────────┐ ↓ ↓ CardPayment OnlinePayment [final] [sealed] │ ┌──────┴──────┐ ↓ ↓ Wallet Bank [final] [final]
Final Thoughts
Java sealed classes provide a clean way to control inheritance while keeping the benefits of polymorphism.
The key idea is simple:
A sealed class or interface defines a controlled set of permitted subtypes.
The three modifiers you should remember are:
sealed
final
non-sealed
Together, they let you decide whether a branch of your class hierarchy should:
Continue with restrictions
↓
sealed
Stop completely
↓
final
Become open again
↓
non-sealed
Sealed types become even more powerful when combined with records and pattern matching.
For example:
public sealed interface Result
permits Success, Failure {
}
can represent a closed set of possible outcomes, while modern switch pattern matching can handle those outcomes cleanly.
If you’re learning modern Java, sealed classes are definitely worth understanding—not because every application needs them, but because they give you a powerful way to express your application’s domain rules directly in the type system.
