Java 17 introduced sealed classes, a language feature that restricts which subclasses can extend an interface or base class. This restriction enables the compiler to verify whether a switch statement covers all possible cases, eliminating the need for a default clause when all permitted subtypes are accounted for. The mechanism mirrors algebraic data types found in functional programming languages such as Haskell or ML.

When a sealed type is used internally within a codebase that is recompiled together, the exhaustiveness check provides strong compile-time guarantees. However, when the sealed type is part of a public API, adding a new permitted subclass can break existing consumers that have not been recompiled. Even though the compiler flags missing cases during compilation, runtime errors may occur if only the sealed type is updated and dependent code is not rebuilt.

The risk arises because the compiler cannot enforce recompilation of all dependent modules. Consequently, a new case introduced in a sealed interface may trigger a runtime exception in applications that rely on pattern matching without a default clause. This issue is particularly relevant for libraries that expose sealed types for external use, as changes to the set of permitted subtypes constitute a breaking API modification that typically requires a major version increment under semantic versioning.

The feature proves most valuable in internal implementations where all components are rebuilt in lockstep, offering greater type safety and reduced runtime failure modes. Its utility diminishes when applied to public interfaces, where the added complexity of maintaining exhaustiveness across module boundaries can introduce subtle bugs that surface only at runtime.