جاوا مدرن ۸ تا ۲۱: Record، Sealed و Pattern MatchingModern Java 8→21: Records, Sealed, Pattern Matching

Let's get one thing straight up front: for its first two decades, Java made you write dozens of lines of repetitive boilerplate just to model "a little bundle of data." Java 8 through 21 came to end that misery. In this chapter you won't just memorize a feature list — you'll actually understand what pain each feature cures, where it came from, and how to talk about it in a senior interview.

Part 0 — a few words you must feel before we start

Before we touch code, three terms recur throughout this chapter. Let me plant them in your mind with analogies now, so you don't get stuck later.

• Immutable: something that can't change once created, like text carved in stone. Its opposite is mutable, like a whiteboard you keep erasing and rewriting.
• Exhaustive: "you covered every case, nothing left out" — like a checklist with every box ticked.
• Compiler: the program that reads your code before it runs and translates it to bytecode. The whole theme of this chapter is: the more errors we can push to compile time (before the program even runs), the calmer our nights are.

Mental model: Java became a data-oriented language

For its first two decades Java forced you to model everything as mutable objects with hand-written boilerplate. Java 8→21 quietly added a second paradigm on top of the OOP core: data-oriented programming. That means: instead of hiding data behind layers of behavior, you model it transparently and directly, and keep the logic outside, as functions that pattern-match over that data.

The three co-designed pillars are:

• Records — transparent data carriers (the menu's "product type").
• Sealed types — a closed set of alternatives (the menu's "sum type").
• Pattern matching — destructuring plus exhaustive dispatch (the waiter).

Read together they give you algebraic data types and safe, compiler-checked case analysis — the same ergonomics as Scala/Kotlin/Rust enums, but native to the JVM.

The rest arrived to make everyday code less noisy: var, switch expressions, text blocks, and — landing in Java 21 — virtual threads (covered deeply in its own chapter). This chapter is a precise map of what shipped, in which release, and how to wield it at a senior level.

Timeline of what landed (and when it became final)

Before the table, let me unpack a word you'll see a lot below:

The senior takeaway: as of Java 21 (the current LTS), records, sealed types, pattern matching for switch, and record patterns are all final and production-safe.

Records: transparent carriers for immutable data

A record is a final class whose state is a fixed ordered list of components. Let me unpack "component": it's just the fields you write inside the parentheses after the record's name — the grains of data that make up this bundle. The compiler auto-generates for you:

• a canonical constructor (the "main" constructor that takes exactly those components),
• private final fields,
• accessors (an accessor is just the read method) named exactly like the components — no get prefix,
• plus equals, hashCode, and toString derived structurally from the components. "Structurally" means it compares by contents, not by whether two references point to the same object in memory.

public record Point(int x, int y) {}

That one line is equivalent to ~40 lines of a hand-written value class. Here's how it's used:

Point p = new Point(3, 4);
int a = p.x();                 // accessor, not getX()
boolean eq = p.equals(new Point(3, 4)); // true — structural equality
System.out.println(p);         // Point[x=3, y=4]

Semantics you must know

• Shallow immutability. Components are final, but if a component is a mutable type (e.g. int[] or List), its contents can still change. "Shallow" means only the top layer is locked, not the depths. If you need real immutability, make a defensive copy in the constructor.
• equals/hashCode are component-based, so records are safe as Map keys and in Sets.
• A record cannot extend another class (it implicitly extends java.lang.Record) but can implement interfaces.
• Records can be generic, can declare static members, additional instance methods, and even nested/local records inside a method.

Compact vs canonical constructors

The compact constructor lets you validate or normalize without re-listing parameters or assigning fields — assignment to the final fields is implicit at the end:

public record Range(int lo, int hi) {
    public Range {                       // compact form — no parameter list
        if (lo > hi) throw new IllegalArgumentException("lo > hi");
        // normalization: reassign the *parameter*, not a field
        hi = Math.max(lo, hi);
    }
}

Note the subtlety: inside a compact constructor you reassign the parameters; the compiler copies their final values into the fields when the block exits. You may not assign this.lo = ... in a compact constructor.

The canonical constructor is the full-signature version; use it when you need defensive copies:

public record Team(String name, List<String> members) {
    public Team(String name, List<String> members) {   // canonical, explicit
        this.name = name;
        this.members = List.copyOf(members);           // defensive, immutable copy
    }
}

You can also add secondary constructors that delegate to the canonical one via this(...) — that is, they hand the work of building off to the main constructor so the logic lives in one place.

When not to use a record

Records are for data whose identity is its contents. Do not use them for:

• JPA @Entity types (they need a no-arg constructor and mutable identity),
• anywhere you need inheritance or lifecycle mutation.

They're perfect for DTOs, value objects, map keys, tuples, and — crucially — the cases of a sealed hierarchy. Which brings us to pillar two.

Sealed classes and interfaces: closing the hierarchy

A sealed type declares exactly which types may extend or implement it. This turns an open, unknowable hierarchy into a closed algebraic sum the compiler can reason about. Remember "closed sum"? It's the menu's "sum type": one among a fixed, enumerated set of cases.

public sealed interface Shape permits Circle, Rectangle, Triangle {}

public record Circle(double radius) implements Shape {}
public record Rectangle(double w, double h) implements Shape {}
public record Triangle(double base, double height) implements Shape {}

Rules of the permits clause (the "guest list"):

• Every permitted subtype must be final, sealed, or non-sealed. non-sealed deliberately re-opens that branch for further extension — like saying "this one guest may bring any number of companions."
• Permitted subtypes must be in the same module (or same package if unnamed module). A module is the packaging unit of code in Java's module system; the logic is that the compiler must be able to see all subtypes to guarantee the list.
• If all permitted subtypes sit in the same source file, you can omit permits — the compiler infers it.

Pattern matching: from instanceof to exhaustive switch

Now our waiter arrives. Pattern matching means "tell the compiler what shape of data you're looking for, and if it's found, hand me its pieces right there." Let's start with the simplest form.

Pattern matching for instanceof (Java 16)

The classic test-cast-assign trio collapses into a type pattern that binds a variable when the test succeeds. "Bind" is that same "labeling": if the data matches the pattern, its value is placed into a fresh variable ready to use.

// Old
if (obj instanceof String) {
    String s = (String) obj;
    return s.length();
}

// Java 16+
if (obj instanceof String s) {      // s is in scope where the test is true
    return s.length();
}

The binding respects flow scoping. "Flow scoping" means s is available exactly where the compiler can prove instanceof held — not necessarily inside a specific {} block, but wherever the program's logical path guarantees the test succeeded. That includes the right side of && and even after an early return:

if (!(obj instanceof String s)) return 0;
return s.length();   // legal: we only reach here if the pattern matched

See how clean that is: because we return early in the "not a string" case, the only way to reach the next line is if s really is a String — and the compiler figures exactly that out.

Switch expressions (Java 14) and pattern matching for switch (Java 21)

First a step back: what's the difference between an old switch statement and a switch expression?

Switch expressions (Java 14) fixed the fall-through footgun and let switch produce a value:

int days = switch (month) {
    case JAN, MAR, MAY, JUL, AUG, OCT, DEC -> 31;
    case APR, JUN, SEP, NOV -> 30;
    case FEB -> 28;                       // arrow form: no fall-through, no break
};

That -> arrow is the hero: each branch is independent, yields its own value, and can't leak into the next.

Now the big Java 21 leap: type patterns can appear in case labels. Combined with a sealed type, the switch becomes exhaustive with no default — and if you later add a fourth Shape, the switch fails to compile until you handle it.

double area(Shape s) {
    return switch (s) {                          // no default needed
        case Circle c    -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.w() * r.h();
        case Triangle t  -> 0.5 * t.base() * t.height();
    };
}

Record patterns (Java 21): destructuring

Record patterns let you match and pull components apart in one step, nesting arbitrarily deep:

sealed interface Expr permits Num, Add, Mul {}
record Num(double v) implements Expr {}
record Add(Expr left, Expr right) implements Expr {}
record Mul(Expr left, Expr right) implements Expr {}

double eval(Expr e) {
    return switch (e) {
        case Num(double v)            -> v;
        case Add(Expr l, Expr r)      -> eval(l) + eval(r);
        case Mul(Expr l, Expr r)      -> eval(l) * eval(r);
    };
}

Notice this is a complete recursive calculator packed into a few lines — with no default at all, because Expr is sealed and the compiler knows the cases are exactly these three.

Nested destructuring reads like the data itself:

// match "an Add whose left side is the literal 0"
case Add(Num(var v), Expr r) when v == 0 -> eval(r);   // 0 + r  ==  r

See how the pattern is nearly the shape of what you're hunting for: an Add containing a Num with value zero. The code looks like a description of the data, not instructions to dig through it.

Guarded patterns with when

A when clause adds a boolean guard to a pattern. Order matters — guarded cases must precede the more general unguarded one:

String describe(Shape s) {
    return switch (s) {
        case Circle c when c.radius() > 100 -> "huge circle";
        case Circle c                        -> "circle";
        case Rectangle r when r.w() == r.h() -> "square";
        case Rectangle r                     -> "rectangle";
        case Triangle t                      -> "triangle";
    };
}

null in switch

Historically switch(null) threw NullPointerException (NPE for short — the "pointing at nothing" error). Since Java 21 you may add an explicit case null (optionally case null, default). Without it, a pattern switch still throws NPE on null — the null-hostility is preserved unless you opt in to taming it.

String render(Object o) {
    return switch (o) {
        case null      -> "nothing";
        case String s  -> "str:" + s;
        default        -> "other";
    };
}

Text blocks, var, and generics polish

These aren't the paradigm's core pillars, but they're the quiet tools that keep everyday code clean.

Text blocks (Java 15)

Multi-line string literals with """, incidental leading whitespace stripped relative to the closing delimiter:

String json = """
        {
          "id": 42,
          "name": "Ada"
        }
        """;                 // trailing newline present unless you end with \

Key operators: \ at end of line suppresses the newline (for when you break one logical line into several physical lines); \s forces a trailing space that stripping would otherwise remove. Text blocks are still ordinary Strings at runtime — no interpolation (string templates would have added that, but, as we said, were withdrawn).

var (Java 10/11)

var is local-variable type inference. It infers the static type of the initializer, so it's fully type-safe — not dynamic typing.

var list = new ArrayList<String>();   // ArrayList<String>
var entry = Map.entry("k", 1);        // Map.Entry<String, Integer>

Rules and gotchas: only for locals with an initializer, for/try-with-resources, and lambda parameters (Java 11); not for fields, method params, or return types. var x = null; and var x = () -> {} don't compile — there's no type to infer (you can't derive a type from null or a bare lambda). Prefer var when the type is obvious from the right-hand side; keep it explicit when it aids the reader.

Enhanced generics across the era

• Diamond <> inference (Java 7) was extended in Java 9 to work with anonymous classes. The "diamond" is that <> which lets you not repeat the type on the right.
• Improved target typing for generic method calls and lambdas throughout Java 8+ means you rarely need explicit witness types like Collections.<String>emptyList(). "Target typing" means the compiler infers the type from where the value is going.
• var interacts with generics for local try/loop variables, reducing the noise of long parameterized type names.

Virtual threads (Java 21) — the one-paragraph version

Thread.ofVirtual().start(...) and Executors.newVirtualThreadPerTaskExecutor() give you JVM-scheduled, cheap threads that unmount from their carrier OS thread on blocking I/O. "Unmount" means the virtual thread temporarily vacates its spot on the real OS thread so other work can run, then remounts when the I/O completes. They make the thread-per-request model scale to millions of concurrent tasks without reactive plumbing.

Common pitfalls and gotchas

Let's gather the top traps in one place — these are the ones that bite in interviews or real code:

• Records aren't deeply immutable. A record Config(Map<String,String> props) shares the map with the caller. Copy in the canonical constructor.
• Compact-constructor assignment trap. Writing this.x = x; in a compact constructor is a compile error; you mutate the parameter and let the compiler assign it.
• Exhaustiveness silently regained by default. If you add a default to a sealed switch "to be safe," you lose the compile error when a new subtype is added. For closed hierarchies, prefer no default so the compiler forces you to handle new cases.
• Guard ordering. A more general case Circle c before case Circle c when ... makes the guarded case unreachable — the compiler rejects it. Put guards first.
• instanceof binding scope is flow-sensitive; a binding introduced in a while condition is not in scope after a break that leaves the loop when the condition is false.
• var + diamond = var x = new HashMap<>(); infers HashMap<Object,Object> — the right side has nothing to constrain the type parameters. Specify them.
• Text block indentation is computed from the least-indented line including the closing """; misaligning the closing delimiter silently changes leading whitespace.

Best practices

• Model domain alternatives as sealed interface + record cases, then dispatch with pattern switch — no default, so exhaustiveness is compiler-enforced.
• Use records for every DTO, event, and value object; you get correct equals/hashCode/toString for free.
• Keep var for obvious initializers and long generic types; write the type where it documents intent.
• Prefer switch expressions over statements — they force every case to yield a value and eliminate fall-through bugs.
• Validate and defensively copy in record constructors; never expose mutable internals through accessors.

Interview Questions

Now it's time to drill everything through real senior-interview questions. Try answering each yourself first, then open the answer.

sealed interface I permits A, B {}
record A() implements I {}
record B() implements I {}
Object o = null;
String r = switch ((I) o) {
    case A a -> "A";
    case B b -> "B";
};
System.out.println(r);

public record Portfolio(List<String> tickers) {
    public List<String> tickers() { return tickers; }
}

record Pair(Object a, Object b) {}
Object p = new Pair("x", 42);
String s = switch (p) {
    case Pair(String a, Integer b) -> a + b;
    case Pair(var a, var b)        -> "other";
    default                        -> "none";
};

Senior notes & advanced edge cases

By now you know what records, sealed types, and pattern matching are and how they work. But the gap between a mid-level and a senior engineer lives exactly where the textbooks fall silent: where these features collide with serialization, frameworks, generics, separate compilation, and performance. This section is that hidden layer.

Record serialization: a hidden security upgrade

Let's start where few people look but interviewers pounce. Classic Java serialization has an infamous hole: on deserialize, the JVM builds the object without calling any constructor. Every validation you put in the constructor is bypassed — an attacker can send tampered bytes and materialize an object you could never construct with new (the foundation of many gadget-chain attacks).

Unlike a normal class, a record's deserialization goes through the canonical constructor. That means the same defensive copy and the same validation if you wrote in the constructor also run on the deserialized data, and invariants are preserved.

public record Percentage(int value) implements java.io.Serializable {
    public Percentage {
        if (value < 0 || value > 100)
            throw new IllegalArgumentException("out of range: " + value);
    }
}
// Even if an attacker sends tampered bytes with value=999,
// deserialization passes through the canonical constructor and throws right there.

Records in the real world of frameworks

Frameworks recognize records through reflection: Class::isRecord and Class::getRecordComponents, which returns an array of RecordComponent (name, type, accessor, annotations). This API is exactly what lets Jackson and Spring build records with no no-arg constructor and no setters.

• Jackson supports records natively since 2.12: it constructs the object via the canonical constructor. Mapping a JSON field name to a component usually needs @JsonProperty on the component, unless you compile with -parameters so parameter names are retained.
• Spring: records fit beautifully in @ConfigurationProperties (constructor binding) and in controller request bodies. For Spring Data, records are ideal for DTO / interface projections.

Generics & pattern matching: the erasure trap

Here's one of the subtlest senior questions. Why does this not compile?

Object o = List.of("a", "b");
switch (o) {
    case List<String> l -> ...   // compile error!
}

Because Java implements generics via erasure: at run time List<String> and List<Integer> are both just List, and the <String> information is gone. The compiler cannot check at run time "is this a List of String," so the pattern is not reifiable and is rejected. The right way:

case List<?> l -> ...             // allowed: a wildcard is reifiable

But when the type is inferable from context, Java lets you drop the type arguments in a record pattern and infers them:

record Box<T>(T content) {}
static String f(Box<String> b) {
    return switch (b) {
        case Box(var s) -> s.toUpperCase();  // s is inferred as String
    };
}

If you truly know the contents are Strings but the type isn't available to the compiler, you're forced to match case List<?> l and then cast by hand — a regression back to erasure unsafety. Design your way around this with sealed + record, not with a cast.

MatchException & separate compilation: the "crashes in prod" trap

This point is important enough to earn a full interview question below. An exhaustive switch over a sealed type needs no default at compile time. But the compiler injects a hidden default that throws MatchException at run time. Why? Because of separate compilation.

The diagram shows the scenario; the application class was compiled against library v1, but the library has moved to v2:

Before the diagram, one line: the library adds a new subtype, but the app is not recompiled.

flowchart LR
  subgraph LibV1["Lib v1"]
    S1["sealed Shape permits Circle, Rect"]
  end
  subgraph App["App compiled against v1"]
    SW["exhaustive switch on Shape<br/>(no default in source)"]
  end
  subgraph LibV2["Lib v2 (deployed, NOT recompiled with App)"]
    S2["sealed Shape permits Circle, Rect, Triangle"]
  end
  S1 --> SW
  LibV2 -. "new Triangle at runtime" .-> SW
  SW -- "no branch matches" --> MX["MatchException"]

If the library adds a Triangle and, at run time, a Triangle reaches that switch — which the app never had a branch for — the result is a MatchException. This is a migration-incompatible change.

Exhaustiveness, dominance, and the hidden default

Two compiler rules seniors should be able to name:

• Exhaustiveness: the compiler must prove the patterns cover every subtype of the sealed type (including nested record-pattern destructuring). Exhaustiveness works on nested patterns too: if Shape has three cases and one of them is itself sealed, the compiler follows it all the way down.
• Dominance: if a more general pattern comes before a more specific one, the second is unreachable and the compiler rejects it (the "guards first" rule from the chapter, generalized: case CharSequence c before case String s means String is never reached).

Records are not value types (yet): identity and Valhalla

A common misconception: "a record is immutable, so surely it's lightweight with no heap overhead." No. In current Java a record is still an ordinary object with identity: it's heap-allocated, has a header, and == on two records with identical contents returns false (their identity differs — always use equals, never ==).

Newer tools: unnamed variables and primitive patterns

• Unnamed variable and pattern _ (Java 22): when you don't need a binding but the syntax forces you to name something, write _. It shines in record patterns: case Point(var x, _) means "I only want x." Unlike a normal name, multiple _ are allowed in one pattern, and it also works in catch (Exception _) and lambda parameters.

case Box(_) -> "a box, contents irrelevant";
for (var _ : items) count++;          // just counting, value irrelevant

• Primitive type patterns (JEP 455): the ability to write case int i or case Integer i when i > 0 and instanceof over primitives. As of current Java (26) this is still in preview — so don't rely on it in production or in an interview answer; just know it's coming.