Enums, Records and Sealed Types

A job tracker needs to record the stage of every application: applied, screening, interview, offer, rejected, withdrawn. The quick way is to store the stage as a number, or as a string. Then one day somebody writes status = 7, or "Aplied", and it compiles fine and fails in some distant part of the program.

Java has three features for this kind of modelling, and they build on one another. Enums model a fixed set of values. Records model plain data. Sealed types model a fixed set of alternatives, each with its own data. This article introduces them in that order. All three make invalid states harder to write, and make the compiler your assistant.

• Why constants and strings are a weak way to model a fixed set of values, and how enums fix that.
• How to give an enum fields, methods and behaviour.
• What a record is, what it generates, and what it does not protect.
• What a sealed type is, and how pattern matching for switch uses it.
• How to choose between a class, an enum, a record and a sealed hierarchy.

Here is the older style that enums replace, with the bug built in:

// File: Main.javapublic class Main {    static final int APPLIED = 1;    static final int SCREENING = 2;    static final int INTERVIEW = 3;    static String label(int status) {        switch (status) {            case APPLIED: return "Applied";            case SCREENING: return "Screening";            case INTERVIEW: return "Interview";            default: return "unknown";        }    }    public static void main(String[] args) {        System.out.println(label(INTERVIEW));        System.out.println(label(7));          // compiles: any int is accepted        System.out.println(label(APPLIED + SCREENING));   // meaningless arithmetic also compiles    }}

InterviewunknownInterview

int constants have no type safety. The compiler cannot tell INTERVIEW from 7 or from APPLIED + SCREENING. There is no way to list all valid values, and printing one gives you a number.

An enum is a special kind of class with a fixed set of instances. Oracle's tutorial puts it this way: use enum types any time you need to represent a fixed set of constants whose values you know at compile time.

// File: ApplicationStatus.javapublic enum ApplicationStatus {    APPLIED("Applied", false),    SCREENING("Screening", false),    INTERVIEW("Interview", false),    OFFER("Offer received", true),    REJECTED("Rejected", true),    WITHDRAWN("Withdrawn", true);    private final String label;    private final boolean finished;    ApplicationStatus(String label, boolean finished) {     // enum constructors are private        this.label = label;        this.finished = finished;    }    public String label() {        return label;    }    public boolean isFinished() {        return finished;    }    public boolean canMoveTo(ApplicationStatus next) {        return switch (this) {            case APPLIED -> next == SCREENING || next == REJECTED || next == WITHDRAWN;            case SCREENING -> next == INTERVIEW || next == REJECTED || next == WITHDRAWN;            case INTERVIEW -> next == OFFER || next == REJECTED || next == WITHDRAWN;            case OFFER, REJECTED, WITHDRAWN -> false;        };    }}

// File: Main.javaimport java.util.EnumMap;import java.util.Map;public class Main {    public static void main(String[] args) {        for (ApplicationStatus status : ApplicationStatus.values()) {            System.out.println(status + " -> " + status.label() + " finished=" + status.isFinished());        }        ApplicationStatus current = ApplicationStatus.valueOf("INTERVIEW");        System.out.println(current.canMoveTo(ApplicationStatus.OFFER));        System.out.println(current.canMoveTo(ApplicationStatus.APPLIED));        System.out.println(current == ApplicationStatus.INTERVIEW);        Map<ApplicationStatus, Integer> counts = new EnumMap<>(ApplicationStatus.class);        counts.put(ApplicationStatus.APPLIED, 4);        counts.put(ApplicationStatus.OFFER, 1);        counts.put(ApplicationStatus.SCREENING, 2);        System.out.println(counts);        try {            ApplicationStatus.valueOf("Aplied");        } catch (IllegalArgumentException e) {            System.out.println("rejected: " + e.getMessage());        }    }}

APPLIED -> Applied finished=falseSCREENING -> Screening finished=falseINTERVIEW -> Interview finished=falseOFFER -> Offer received finished=trueREJECTED -> Rejected finished=trueWITHDRAWN -> Withdrawn finished=truetruefalsetrue{APPLIED=4, SCREENING=2, OFFER=1}rejected: No enum constant ApplicationStatus.Aplied

What the enum gives you:

• Type safety. A variable of type ApplicationStatus can only hold one of the six constants (or null). label(7) is no longer possible.
• A fixed, enumerable set. values() returns all constants in declaration order, and valueOf("INTERVIEW") converts a string to a constant, failing loudly for an invalid name.
• Behaviour next to the data. The enum has fields, a private constructor and methods. canMoveTo encodes the rules for status changes in one place.
• Compiler-checked switches. A switch expression over an enum must cover every constant. Add a seventh status and the canMoveTo method stops compiling until you handle it, which is the exhaustiveness check from article 3 at work, with no default needed.
• Safe comparison. There is exactly one instance of each constant, so == is correct for enums (and is also null-safe).
• Special collections. EnumMap and EnumSet are very compact and fast collections keyed by enum constants. Note that the map prints in declaration order.

A few cautions: avoid ordinal() (the constant's position) for anything stored or compared, because inserting a constant in the middle changes every number after it. And when you store an enum in a database, store its name ("INTERVIEW"), not its ordinal, which article 34 returns to. An enum can also implement an interface, and individual constants can override methods, so an enum can carry behaviour (a PaymentMethod enum with a different fee calculation per constant), as long as the set of alternatives is fixed.

Many classes exist only to carry values: a point, a currency amount, a search request, a response. In older Java, each one needs a constructor, getters, equals, hashCode and toString, which is a lot of ceremony around no behaviour. Records, final in Java 16 (JEP 395), are designed for this. The JEP describes them as transparent carriers for immutable data, and emphasises that the aim is to model data as data, not merely to cut boilerplate.

One line replaces the whole class:

// File: Main.javaimport java.time.LocalDate;import java.util.ArrayList;import java.util.List;public class Main {    record Contact(String name, String email) {}    record Application(String company, String role, LocalDate appliedOn) {        Application {                                   // compact canonical constructor: validation            if (company == null || company.isBlank()) {                throw new IllegalArgumentException("company is required");            }            if (appliedOn.isAfter(LocalDate.of(2100, 1, 1))) {                throw new IllegalArgumentException("date is unrealistic");            }            company = company.strip();                  // normalise before the fields are assigned        }        boolean isRecent(LocalDate today) {             // records can have methods            return !appliedOn.isBefore(today.minusDays(30));        }    }    record Team(String name, List<String> members) {}    public static void main(String[] args) {        Contact a = new Contact("Asha", "asha@example.com");        Contact b = new Contact("Asha", "asha@example.com");        System.out.println(a);        System.out.println(a.equals(b) + " " + (a.hashCode() == b.hashCode()) + " " + a.name());        Application app = new Application("  Acme Ltd ", "Backend Developer", LocalDate.of(2026, 10, 1));        System.out.println(app);        System.out.println(app.isRecent(LocalDate.of(2026, 10, 20)));        try {            new Application(" ", "Tester", LocalDate.of(2026, 1, 1));        } catch (IllegalArgumentException e) {            System.out.println("rejected: " + e.getMessage());        }        List<String> people = new ArrayList<>(List.of("Ravi"));        Team team = new Team("Platform", people);        people.add("Meena");                            // the record's list changes!        System.out.println(team);    }}

Contact[name=Asha, email=asha@example.com]true true AshaApplication[company=Acme Ltd, role=Backend Developer, appliedOn=2026-10-01]truerejected: company is requiredTeam[name=Platform, members=[Ravi, Meena]]

From the single header record Contact(String name, String email) {} the compiler generates:

• private final fields for each component;
• a canonical constructor taking all components;
• accessor methods named after the components (name(), not getName());
• equals and hashCode based on all components, and a toString that lists them.

You can add methods, static members and validation. The compact constructor (the one written without a parameter list, as in Application) runs before the fields are assigned, so it is the place to validate and normalise inputs. Records are implicitly final, cannot extend another class (they can implement interfaces), and their fields are final: that is the point.

Records are only shallowly immutable. The last lines show the trap: the record's component is a reference to a mutable ArrayList, and the caller changed that list after the record was built, so the record's apparent state changed. The record cannot protect the contents of objects it holds. Apply the defensive-copy rule from article 7: copy mutable components in the compact constructor with members = List.copyOf(members);.

Use records for DTOs (data transfer objects) in the Spring project, for compound map keys, for return values that group several results, and for value objects. Do not use a record for an object with identity and a mutable lifecycle (an account, a JPA entity), because the whole point of a record is that two with equal data are equal and interchangeable.

An enum models a closed set of values. Often what you need to model is a closed set of kinds of thing, each with different data. Consider the events in the life of a job application:

• it was submitted (with a company name),
• an interview was scheduled (with a time and a round),
• it was rejected (with a reason), or
• an offer was received (with an amount).

An enum cannot hold different data per constant. An open interface can, but then anyone can add a fifth kind of event, and a switch over events can never be sure it has covered everything. Sealed types (JEP 409, final in Java 17) fix this. JEP 409 describes the goal: a superclass that is widely accessible but not widely extensible, where the subclasses are restricted to those known to the author.

// File: Main.javaimport java.time.LocalDateTime;public class Main {    sealed interface ApplicationEvent permits Submitted, InterviewScheduled, Rejected, OfferReceived {}    record Submitted(String company) implements ApplicationEvent {}    record InterviewScheduled(LocalDateTime at, int round) implements ApplicationEvent {}    record Rejected(String reason) implements ApplicationEvent {}    record OfferReceived(long annualAmount) implements ApplicationEvent {}    static String describe(ApplicationEvent event) {        return switch (event) {            case Submitted s -> "Applied to " + s.company();            case InterviewScheduled(LocalDateTime at, int round) -> "Round " + round + " on " + at.toLocalDate();            case Rejected r when r.reason().isBlank() -> "Rejected (no reason given)";            case Rejected r -> "Rejected: " + r.reason();            case OfferReceived o when o.annualAmount() >= 2_000_000 -> "Large offer: " + o.annualAmount();            case OfferReceived o -> "Offer: " + o.annualAmount();        };    }    public static void main(String[] args) {        ApplicationEvent[] events = {                new Submitted("Acme Ltd"),                new InterviewScheduled(LocalDateTime.of(2026, 10, 12, 15, 30), 2),                new Rejected(""),                new Rejected("position filled"),                new OfferReceived(2_400_000),                new OfferReceived(900_000)        };        for (ApplicationEvent event : events) {            System.out.println(describe(event));        }    }}

Applied to Acme LtdRound 2 on 2026-10-12Rejected (no reason given)Rejected: position filledLarge offer: 2400000Offer: 900000

Several features work together:

• sealed ... permits declares exactly which types may implement the interface. Each permitted subtype must itself be final (records are), sealed, or non-sealed.
• Pattern matching for switch (JEP 441, final in Java 21) lets case labels test types instead of constants. case Submitted s matches and binds the variable s.
• Record patterns (JEP 440, final in Java 21) deconstruct a record directly in the label: InterviewScheduled(LocalDateTime at, int round) pulls out the components with no accessor calls.
• Guards: a when clause adds a condition to a pattern, as in case Rejected r when r.reason().isBlank(). Order matters: the guarded case must come before the general one, and the compiler rejects an unreachable order.
• Exhaustiveness without default. Because the interface is sealed, the compiler knows the full list of subtypes and checks that the switch covers them all.

That last point is the payoff. Watch what happens when someone adds a fifth kind of event but forgets to update describe:

// File: Main.javapublic class Main {    sealed interface Event permits Created, Closed, Reopened {}    record Created() implements Event {}    record Closed() implements Event {}    record Reopened() implements Event {}    static String describe(Event event) {        return switch (event) {            case Created c -> "created";            case Closed c -> "closed";        };    }    public static void main(String[] args) {        System.out.println(describe(new Created()));    }}

Main.java:12: error: the switch expression does not cover all possible input values        return switch (event) {               ^1 error

The compiler reports that the switch expression does not cover all possible input values. You have found the missing case at compile time, instead of finding out in production, which is exactly what you want from modelling with sealed types. If the hierarchy had been an ordinary open interface with a default branch, the new event would have been handled by the default, silently and wrongly.

The sealed approach is sometimes described as modelling with sum types (a value is one of several alternatives) combined with product types (records, which hold several fields). You do not need the terms to use the idea, but you will meet them in articles and interviews.

• Using ordinal() for storage or comparison.
• Storing enum values as numbers in a database or JSON, making reordering dangerous.
• Adding a default branch to a switch over a sealed type or an enum, which turns off the compiler's exhaustiveness check and hides missing cases.
• Assuming a record is deeply immutable.
• Using records for entities with identity and mutable state.
• Putting a more general pattern before a more specific one, which makes the specific case unreachable.
• Using a sealed type when third parties must be allowed to add variants. Sealing is a deliberate restriction.

public enum Priority {    LOW, MEDIUM, HIGH;    public boolean isUrgent() {        return this == HIGH;    }}

public record Money(long paise, String currency) {    public Money {        if (paise < 0) {            throw new IllegalArgumentException("amount cannot be negative");        }        if (currency == null || currency.isBlank()) {            throw new IllegalArgumentException("currency is required");        }    }    public Money plus(Money other) {        if (!currency.equals(other.currency)) {            throw new IllegalArgumentException("currency mismatch");        }        return new Money(paise + other.paise, currency);    }}

sealed interface ParseResult permits Parsed, Failed {}record Parsed(int value) implements ParseResult {}record Failed(String message) implements ParseResult {}static ParseResult parse(String text) {    try {        return new Parsed(Integer.parseInt(text.strip()));    } catch (NumberFormatException e) {        return new Failed("'" + text + "' is not a whole number");    }}static String show(ParseResult result) {    return switch (result) {        case Parsed p -> "Parsed " + p.value();        case Failed f -> "Problem: " + f.message();    };}

• Next: Exceptions: Handling Errors Properly completes core Java by covering what to do when things go wrong.
• For records as DTOs: Building a REST API with Spring Boot.
• For enums in the database: JPA and Hibernate: The Persistence Model.