History
The switch construct evolved from a C-style control flow statement into a full expression capable of yielding values in Java 14. With Java 17, sealed classes and interfaces were introduced to restrict inheritance, and pattern matching for switch emerged as a preview feature, culminating in standardization in Java 21. This evolution shifted the switch from a simple jump table based on discrete constants to a sophisticated pattern matching mechanism that must guarantee completeness when used as an expression.
The Problem
When switch operates as an expression (using the arrow syntax -> or yield), it must produce a value for every possible input to satisfy Java's static type system. Unlike traditional switch statements that may silently skip unhandled cases or fall through, an expression requires absolute certainty that all execution paths return a value. Sealed hierarchies explicitly enumerate all permitted subtypes, creating a closed universe that makes total coverage theoretically verifiable at compile-time. The compiler must reconcile this closed world with open patterns (like type patterns or null cases) to ensure no runtime MatchException occurs due to uncovered types.
The Solution
The compiler performs dominance and exhaustiveness analysis during the attribution phase of compilation. It treats the permits clause of a sealed class as a finite, closed set of types. For each pattern in the switch, it subtracts the matched types from the universe of permitted types. If any permitted subtype remains unmatched after the last pattern, and no unconditional default or total type pattern exists, the compiler rejects the code with an error. This analysis respects pattern dominance rules (where specific patterns must precede more general ones) and generates synthetic machinery to handle null inputs separately from type patterns.
sealed interface Payment permits Credit, Debit, Crypto {} record Credit() implements Payment {} record Debit() implements Payment {} record Crypto() implements Payment {} // Compile-time error if Crypto case is missing double fee = switch (payment) { case Credit c -> 0.02; case Debit d -> 0.01; // Missing Crypto case causes: "switch expression does not cover all possible values" };
Problem Description
In a payment processing microservice, we needed to calculate fees based on instrument types: Credit, Debit, BankTransfer, and Crypto. The domain model used a sealed interface PaymentInstrument permitting exactly these four implementations. A junior developer implemented the fee calculator using a switch expression but inadvertently omitted the Crypto case, assuming it would implicitly yield zero. When cryptocurrency payments were enabled in production, this omission caused a MatchException at runtime, crashing the transaction pipeline and requiring an emergency rollback.
Different Solutions Considered
Solution A: Default case fallback
We could add a default -> 0.0 clause to handle any unmatched instrument. This approach offers immediate safety by preventing the crash. However, it obscures business intent by silently absorbing unhandled types. If a new instrument type were later added to the sealed hierarchy, the default clause would hide it from fee calculations, potentially causing revenue leakage or compliance violations.
Solution B: Enum-based type mapping
Migrating to an enum InstrumentType would enable compile-time exhaustiveness checking via constant enumeration. However, this creates a parallel taxonomy requiring each payment instrument to expose redundant type metadata. It sacrifices the polymorphic richness of sealed classes, where each subtype carries unique data fields like card numbers or blockchain addresses, forcing unnatural data denormalization.
Solution C: Compiler-enforced exhaustive patterns We implement the switch expression with explicit cases for all four permitted types, leveraging the compiler's sealed hierarchy analysis. This approach treats missing cases as compilation errors, forcing codebase updates whenever the sealed permits change. It eliminates runtime surprises by shifting verification left into the build phase.
Chosen Solution and Result
We selected Solution C and configured the build pipeline to treat compiler warnings about non-exhaustive switch expressions as fatal errors. When the product team later added BuyNowPayLater as a fifth permitted subtype, the CI/CD pipeline immediately flagged seventeen locations where fee calculations were incomplete. This forced a coordinated update across tax, compliance, and accounting modules before deployment, ensuring the new instrument received proper financial logic. The compile-time guarantees prevented silent defaults and maintained type safety across distributed teams.
How does null handling interact with exhaustiveness checking in pattern switches?
Many candidates incorrectly assume that covering all subtypes of a sealed class satisfies exhaustiveness requirements. However, switch expressions treat null selectors as distinct from type patterns; a separate case null clause or total pattern is mandatory. Without explicit null handling, the compiler generates a synthetic null check that throws NullPointerException, meaning the expression is technically exhaustive for types but not for the null value itself.
Why does adding a default clause to a switch over a sealed hierarchy potentially violate the principle of sealed types?
Candidates often add default as a defensive coding habit without recognizing that it undermines the closed-world assumption of sealed classes. A default clause matches any type, including those added to the permits list in future releases, effectively converting compile-time exhaustiveness verification into a runtime catch-all. This reintroduces the exact fragility that sealed classes were designed to eliminate by allowing unhandled new types to execute unintended logic silently.
What happens when a switch expression over a sealed type encounters a type that is permitted but not visible to the current module?
This scenario involves visibility boundaries where a sealed class permits a package-private subtype in another package or module that is not exported to the current compilation unit. The compiler cannot verify exhaustiveness because the complete set of permitted types is unknown at the usage site, resulting in a compilation error despite all locally visible types being handled. Resolving this requires either adding a default clause (defeating exhaustiveness) or adjusting JPMS module exports to make the permits visible, highlighting the interaction between module accessibility and pattern matching.