if, switch and the switch expression

For this lesson, we'll start with if, walk through the classic switch and its fall-through behaviour, then build up to switch expressions, pattern matching, record patterns, guards and case null. Along the way we'll open the bytecode, because "how does a switch on a String work?" is a favourite follow-up that most candidates can't answer.

01Picture it first: two kinds of switch

Think of the classic switch as a row of doors in a corridor. You enter at the matching door and keep walking through every door after it until something (break, return, throw) stops you. The modern arrow switch is a set of separate rooms: you enter exactly one, do its work, and leave.

Fig. 1

Classic colon-label switch falls through into later cases until a break, while an arrow switch runs exactly one arm and must cover every possible value

Before we get to switch, a word on if. The condition must be a real boolean, so if (count) doesn't compile the way it would in C. The classic trap is if (flag = true): it compiles for a boolean flag, assigns, and is always taken. And a dangling else binds to the nearest if, which is why most style guides insist on braces even for one-line bodies.

02Under the hood: the classic switch statement

public class Classic {
    static int classic(int x) {
        int count = 0;
        switch (x) {
            case 1:
                count++;            // no break: falls into case 2
            case 2:
                count++;
            case 3:
                count++;
                break;
            default:
                count = -1;
        }
        return count;
    }

    static int httpCode(String method) {
        switch (method) {           // NullPointerException if method is null
            case "GET":  return 200;
            case "POST": return 201;
            default:     return 405;
        }
    }

    public static void main(String[] args) {
        System.out.println(classic(1) + " " + classic(2) + " " + classic(9)); // 3 2 -1
        System.out.println(httpCode("POST"));                                  // 201
    }
}

Notice three things:

• Fall-through is the default. classic(1) enters at case 1 and runs three increments. It's occasionally useful for grouping (case 'a': case 'e':), but forgetting a break is one of the oldest bugs in C-family languages.
• Labels must be compile-time constants of the selector's type, with no duplicates. long, float, double and boolean selectors are not allowed in Java 21.
• A null selector throws NullPointerException in every switch unless it has an explicit case null (Java 21).

Now the bytecode. The JVM has two dedicated instructions, and javac picks one with a cost heuristic that weighs table size against the number of labels.

Fig. 2

tableswitch indexes straight into a jump table for dense keys, while lookupswitch searches sorted key and offset pairs for sparse keys

• tableswitch: used when the case values are dense, like 1, 2, 3, 4. It stores a low, a high and one jump offset per value in between. The JVM checks bounds and indexes into the table: O(1).
• lookupswitch: used when values are sparse, like 1, 1000, 100000. It stores sorted key/offset pairs, and the JVM may binary search them: O(log n).

A String switch is compiled in two stages. javac calls hashCode() and does a lookupswitch on the hash; inside each hash bucket it calls equals() to confirm the match (two different strings can share a hash, like "Aa" and "BB", both 2112) and records a case index; then a second switch on that index runs your code. That's why a null selector throws: the very first instruction is method.hashCode().

For an enum from another class, javac traditionally generates a synthetic $SwitchMap$ array that maps each constant's ordinal() to a case index. That indirection means reordering the enum's constants later won't silently break already-compiled switches.

03Switch expressions, arrows and yield (Java 14)

JEP 361 made switch expressions standard in Java 14. You get three upgrades at once: arrow labels that never fall through, multiple constants per label separated by commas, and the ability to use the whole switch as a value.

import java.time.DayOfWeek;

public class Expressions {
    static String kind(DayOfWeek day) {
        return switch (day) {                       // no default needed: all 7 covered
            case SATURDAY, SUNDAY -> "weekend";
            case FRIDAY -> {
                String mood = "almost weekend";
                yield mood.toUpperCase();           // yield returns a value from a block
            }
            case MONDAY, TUESDAY, WEDNESDAY, THURSDAY -> "weekday";
        };
    }

    public static void main(String[] args) {
        System.out.println(kind(DayOfWeek.FRIDAY));   // ALMOST WEEKEND
    }
}

yield is the keyword for "this is the value of the switch" inside a block arm. You can't use return there, because return would leave the enclosing method. A switch expression must be exhaustive: every possible selector value needs an arm. For enums, covering every constant is enough and you can drop default. If someone later adds a constant and doesn't recompile your class, the switch throws MatchException at runtime in Java 21 (older releases threw IncompatibleClassChangeError), so stale code fails loudly instead of returning garbage.

You can also use arrows in a switch statement. It still won't fall through, and a statement that only uses old-style constants doesn't have to be exhaustive.

04Pattern matching, record patterns, guards and null (Java 21)

Java 21 finalised pattern matching for switch (JEP 441) and record patterns (JEP 440). The selector can now be any reference type, and labels can test the type, take records apart and add a when guard.

public class Shapes {
    sealed interface Shape permits Circle, Square, Rect {}
    record Circle(double r) implements Shape {}
    record Square(double side) implements Shape {}
    record Rect(double w, double h) implements Shape {}

    static double area(Shape s) {
        return switch (s) {                                  // exhaustive: sealed
            case Circle c -> Math.PI * c.r() * c.r();
            case Square(double side) -> side * side;         // record pattern
            case Rect(double w, double h) when w == h -> w * w;  // guard
            case Rect(double w, double h) -> w * h;
        };
    }

    static String describe(Object o) {
        return switch (o) {
            case null -> "nothing";                          // no NPE
            case Integer i when i > 100 -> "big number";
            case Integer i -> "number " + i;
            case String str -> "text of length " + str.length();
            default -> "something else";
        };
    }

    public static void main(String[] args) {
        System.out.println(area(new Rect(2, 3)));            // 6.0
        System.out.println(describe(null));                  // nothing
        System.out.println(describe(42));                    // number 42
    }
}

Notice four rules the compiler enforces for you:

• Sealed hierarchies make default unnecessary. Because Shape permits exactly three records, covering them all is exhaustive. Add a fourth permitted type and every switch that misses it stops compiling. That's the real payoff.
• Dominance. Labels are tried top to bottom, so a broader pattern can't sit above a narrower one. case CharSequence cs before case String s is a compile error: "this case label is dominated by a preceding case label". Guarded cases go before the unguarded case of the same type.
• case null is the only way to stop a switch from throwing on null. You can combine it as case null, default ->.
• Pattern switches must be exhaustive even as statements. Once a switch uses patterns or case null, missing coverage is a compile error.

Under the hood, a pattern switch doesn't compile to a chain of instanceof checks. javac emits an invokedynamic to SwitchBootstraps.typeSwitch, which returns the index of the first matching label, followed by a tableswitch on that index. The runtime is free to optimise the type test without javac baking in a strategy.

05Real world: where switches go wrong

My default for new code is a switch expression with arrows whenever each branch produces a value, and an arrow switch statement when it performs actions. I keep if/else for conditions that aren't about one value, such as ranges or combinations of flags.

06Advanced: choosing the right branch tool

07How to say it in the interview

When I ask about switch, I'm listening for three things: do you know about fall-through and that arrows remove it, can you explain exhaustiveness and why sealed types make it powerful, and can you say something true about how a String switch compiles. If you also mention case null and dominance, you've shown me you've used Java 21 for real.

Here's how this might look on the whiteboard: