How Does Pattern Matching for switch Work?

Pattern matching for switch lets you write case labels that test the type of the value, not just its value. It spent several releases as a preview feature before becoming final, and it is now what you should target if you want to use it in production code.

Before it existed, switching over a sealed hierarchy meant a chain of instanceof tests, and switching over a type with several implementations meant the old constant-style switch, which could only compare against constants. Now you can write case Circle c -> and the compiler binds c with the right type, and the switch is checked for exhaustiveness.

There are three shapes of label. A type pattern — case String s -> — matches when the value is of that type and binds it. A guarded pattern — case String s when s.length() > 3 -> — matches a type and an extra condition, and the guard is only evaluated when the type test succeeds. And a constant pattern — case 1 -> — is the original behaviour, now expressed with the same arrow syntax.

Two more capabilities come with it. case null is now allowed as an explicit branch, so you can handle a null reference in a switch instead of guarding before the switch. And case Type t -> where Type is a supertype acts as a catch-all for anything not matched earlier, which replaces the old default branch in many cases.

The sample above is the same dispatch written as a chain of instanceof tests, so you can run it as it is. With the arrow form those tests become cases in one switch: each branch gets its own typed binding, a guard attaches a condition to a single case instead of a separate if, and the compiler checks the whole switch for exhaustiveness.

public class Main {
    public static void main(String[] args) {
        System.out.println(describe("hello"));
        System.out.println(describe(42));
        System.out.println(describe(3.5));
        System.out.println(describe(new int[]{1, 2, 3}));
    }

    // Type-based dispatch: one branch per type, checked in order.
    static String describe(Object o) {
        if (o instanceof String) {
            return "a String of length " + ((String) o).length();
        }
        if (o instanceof Integer) {
            return "an Integer holding " + o;
        }
        if (o instanceof Double) {
            return "a Double holding " + o;
        }
        if (o instanceof int[]) {
            return "an int array of length " + ((int[]) o).length;
        }
        return "something else";
    }
}

One detail is worth remembering for the interview. The order of the cases matters. A pattern for a supertype placed before a pattern for one of its subtypes makes the later branch unreachable, and the compiler rejects that as an error rather than a warning. That is dominance, and it is the rule that decides which case wins.

You write the type pattern in the case label and use the arrow form. If you switch over a sealed type or an enum, the compiler requires every possibility to be covered, so leaving out a case is a compile error rather than a silent fall-through.

public class Main {
    public static void main(String[] args) {
        System.out.println(describe("hello"));
        System.out.println(describe(42));
        System.out.println(describe(3.5));
        System.out.println(describe(java.util.List.of(1, 2)));
        System.out.println(describe(null));
    }

    static String describe(Object value) {
        if (value == null) {
            return "null";
        }
        if (value instanceof String) {
            return "a String of length " + ((String) value).length();
        }
        if (value instanceof Integer) {
            return "an Integer: " + value;
        }
        if (value instanceof Double) {
            return "a Double: " + value;
        }
        return "something else";
    }
}

The sample above shows the same dispatch as a chain of instanceof tests, so you can run it. With the arrow form those tests become cases in one switch, each branch getting its own typed binding, and a null case can be handled explicitly — in older Java a null would have thrown a NullPointerException before the switch even ran. A default branch is still required when the switch is over an Object, which is not a sealed type, so the compiler cannot prove exhaustiveness.

The rule to remember. When you switch over a sealed type, the compiler knows every subtype and requires each one to be handled, so no default is needed. When you switch over an enum, the same applies — but only if the enum is in the same compilation unit, otherwise the compiler cannot know its constants and demands a default. When you switch over an open type such as Object, you need a default.

Two rules decide what a pattern switch does, and both depend on the order of the cases.

Dominance says that an earlier case wins if it matches everything a later case would match. A type pattern for a supertype dominates a type pattern for one of its subtypes, so case Number n placed before case Integer i makes the Integer branch unreachable — and the compiler rejects it as an error, not a warning. The same applies to a constant pattern: case 1 -> before case Integer i -> would dominate it, because every Integer equal to 1 is already handled.

Exhaustiveness says that a switch expression must handle every possible value. For a sealed type the compiler proves it from the permitted list. For an enum it proves it from the constants, provided the enum is in the same compilation unit. For an open type it cannot prove anything, so a default branch is required.

A subtlety that catches people out is that a guarded pattern does not contribute to exhaustiveness. A branch like case Integer i when i > 0 -> only handles the positive integers, so a switch over a sealed type with such a branch still needs another branch covering the remaining integers. And in the same vein, a pattern that covers only part of a subtype — a guarded case Circle c when c.radius() > 5 — does not count as covering Circle for the purposes of exhaustiveness, which is why a sealed hierarchy with guarded patterns usually also needs a default.

The practical consequence is that the case order matters and the compiler enforces it. When you refactor a switch and the build breaks with an unreachable-case error, that is the dominance rule doing its job.