Java Sealed Classes and Exhaustive Pattern Matching: Implications for API Design

Introduction to Sealed Classes

Java 17 introduced sealed classes and interfaces, which allow developers to explicitly define the permitted direct subtypes. This mechanism provides a way to restrict the inheritance hierarchy, ensuring that only specified classes can extend or implement a sealed type. For example, a sealed interface can declare specific record types as its only allowed implementations.

Exhaustive Pattern Matching

A key benefit of sealed types is their integration with switch expressions, enabling exhaustive pattern matching. The compiler can verify that all possible subtypes of a sealed type are handled in a switch expression. If all cases are covered, a default clause is not required. Forgetting a case without a default results in a compile-time error, ensuring comprehensive handling of all defined subtypes.

Implications for API Compatibility

While exhaustiveness checking is beneficial for code correctness, it introduces a new consideration for API evolution. Adding a new subtype to an existing sealed class or interface constitutes a breaking change. Consumers of the API that use switch expressions on the sealed type will fail to compile if they are not updated to handle the new subtype. This implies that such changes would necessitate a major version bump under semantic versioning.

Compile-time vs. Runtime Errors

The exhaustiveness check primarily occurs at compile-time. However, if a consumer application is not recompiled after a sealed type's definition changes (e.g., a new subtype is added), runtime issues can arise. If the consumer's compiled code encounters an instance of the newly added subtype that it was not compiled to handle, it could lead to unexpected runtime behavior or errors, as the switch expression would not have a matching case.