Switch Expressions in Java — Arrow Syntax, yield, Exhaustiveness

Switch expressions (Java 14, JEP 361) fix the long-standing problems with Java's switch statement.

Three big improvements

1. Arrow syntax

• case A -> result — no break, no fall-through
• Multiple labels: case A, B, C -> result
• Each case is independent

2. Returns a value

• Switch becomes an expression — usable in return, field initializers, method args
• No need to declare a variable outside and mutate inside

3. Exhaustive

• Compiler verifies all cases covered
• Adding a new enum constant or sealed subtype → compile error in every switch
• Massive maintenance win

`yield` for multi-statement cases

• Use a block when you need multiple statements
• yield returns the value from the block to the switch expression
• case X -> { log.info(...); yield value; }
• yield vs return — yield exits the case block; return exits the method

Exhaustiveness rules

For enums — listing all constants is exhaustive

• No default needed
• Adding a new constant → compile error in every switch
• This is the biggest win for evolving codebases

For sealed types (Java 17+) — listing all permitted subtypes is exhaustive

• No default needed
• Foundation for ADT-style matching

For other types (int, String, etc.) — must include default

• Compiler can't enumerate all values

Arrow in statements too

• switch (event) { case CLICK -> handleClick(event); ... } — no return value
• Still no fall-through, still no break
• Useful for side-effect-only dispatch

Forbidden mixing

• Cannot mix arrow and colon cases in one switch
• Compile error
• Pick one style per switch

Switch statement vs expression — which to use

Switch expression — when you want a value

• Exhaustive (compiler-checked)
• Cleaner
• One-liner for many cases

Switch statement (arrow) — side effects only

• No value, but still safe (no fall-through)
• For event dispatch, etc.

Switch statement (colon + break) — legacy or fall-through needed

• Rare; usually a smell
• Old code; not for new

Java 21 pattern matching — the deeper payoff

Type patterns

• case Integer i -> ... — binds i to the matched type
• case String s -> ...
• case null -> ... — null is its own case

Record deconstruction (JEP 440)

• case Point(int x, int y) -> ... — destructure inline
• Nested: case Line(Point(int x1, int y1), Point(int x2, int y2)) -> ...

`when` guards

• case Integer i when i > 100 -> "large"
• Add a predicate to a type pattern

Sealed types + pattern switch = ADT matching

• Compiler verifies exhaustiveness over the closed hierarchy
• No default needed
• Same expressive power as Scala/Kotlin sealed match

Migration tips

• IDEs auto-convert old switch — generally safe
• Verify edge cases (especially intentional fall-through, which is rare)
• Remove default from enum/sealed switches — keep exhaustiveness check
• Use default -> throw new IllegalStateException(...) only as a defensive marker for impossible cases

Best practices

• Always prefer expression over statement when value is needed
• Use arrow everywhere — avoid colon
• yield only when you need a block
• Don't add default to enum/sealed switches
• Group related labels with commas
• Extract complex case logic to methods

Recommendation: Use switch expressions with arrow syntax as your default for any 'compute a value based on a discriminator' pattern. They eliminate fall-through bugs, force exhaustiveness, and make the intent ("this is computing a result") obvious. For enum discriminators, leave off default so the compiler will alert you when new constants are added — this is the most powerful maintenance feature. For sealed types (Java 17+), do the same; combined with pattern matching for switch in Java 21, you get full ADT-style matching with compile-time exhaustiveness, putting Java on par with Scala and Kotlin for type-driven dispatch. Use `yield` only when a case needs multiple statements; otherwise the arrow alone is cleanest. Never mix arrow and colon styles in the same switch — compile error. Trust your IDE to convert legacy switch statements; it's usually a safe refactor that improves clarity. The deeper lesson: switch is no longer just a control structure — it's a first-class expression and the gateway to Java's modern pattern-matching family.