TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Java’s sealed classes and interfaces let the compiler check whether a switch covers every permitted subtype, avoiding a default branch when all cases are handled. Neil Madden’s report explains that adding a subtype can break downstream code at compile time if rebuilt, or cause a MatchException at runtime if it is not.
Java’s sealed classes and interfaces allow exhaustive pattern matching, but adding a permitted subtype can break programs that switch over the type, security developer Neil Madden wrote in a report published April 24. The impact depends on whether consumers recompile: a rebuilt switch without the new case fails compilation, while an older compiled consumer may encounter a MatchException at runtime.
Sealed types let developers declare which subclasses or implementations are permitted. Madden’s example uses a sealed interface with two record implementations, then switches over values of that interface. Because the compiler can determine the permitted cases, the switch expression can omit a default branch when it covers both records. Leave one out and compilation fails.
That check can make changes to the type visible to consumers. If a library adds a third permitted subtype and a client recompiles its switch without handling it, the compiler reports a non-exhaustive switch. Madden says that, for teams following Semantic Versioning, adding such a subtype to a public API may need to be treated as a breaking change and released with a major version update.
Recompilation is not guaranteed, however. Madden describes changing the sealed interface and recompiling it without rebuilding the consumer. If that older consumer then processes the newly added subtype, Java can throw a MatchException. In that situation, the exhaustiveness check did not catch the mismatch during compilation because the consumer’s code was not compiled against the changed type.
When New Cases Break Client Code
The trade-off affects how teams design Java APIs. Exhaustive matching helps application and library developers catch missing cases when the relevant code is compiled together. But it also makes the set of permitted subtypes part of the contract clients depend on: adding a case can require changes in code maintained outside the library.
For library users, this means a dependency update may have different outcomes depending on how the application is built and deployed. A full rebuild can surface the issue as a compiler error; replacing a library while leaving client code unchanged can defer it until the new subtype reaches the switch. The report’s practical advice is to weigh those behaviors before exposing a sealed type as a public API.
Madden’s conclusion is his assessment, not a Java rule requiring a particular API design: sealed types may be more suitable inside a component, where its implementation can be rebuilt together, than across independently updated component boundaries.
Products Worth Considering
Bose QuietComfort Wireless Noise-Cancelling Over-Ear Headphones, Twilight Blue
LG UltraGear 27-inch QHD OLED Gaming Monitor, 240Hz
Logitech MX Ergo S Advanced Wireless Trackball Mouse USB-C – Graphite
As an affiliate, we earn on qualifying purchases.
Java’s Exhaustiveness Check
Java 17 introduced sealed classes, which make a type’s permitted subtypes explicit. Pattern matching in switch can use that information to check whether a switch expression accounts for all possible cases. The compiler can reject a missing case when compiling against the current definition.
Madden compares the model to algebraic data types in functional languages: a type has a defined set of alternatives. The analogy helps explain the benefit, but does not remove the versioning issue. The compiler’s check reflects the type definition available when the consumer is compiled; independently compiled components can be out of sync.
The report also notes that Java’s documentation describes the possibility of a MatchException in separate-compilation scenarios, as well as corner cases involving nulls in patterns. Madden says he noticed the API-design concern while reviewing preview support for PEM-encoded cryptographic objects. That is his example of a public sealed interface whose clients are encouraged to pattern match; it does not establish that a particular break has already occurred.
“adding a new sub-type to a sealed class/interface may break consumers of that code.”
— Neil Madden, in his April 24 report
Compatibility Depends on Rebuilding
The report describes a possible failure mode, not evidence that every sealed-type change will cause a runtime exception. The outcome depends on the type change, the consumer’s compiled code, and whether the application is rebuilt and exercised with the new subtype. The source does not quantify how often clients encounter this situation.
Nor does Madden’s example settle whether a particular library should make a type sealed. The appropriate choice depends on the API’s intended evolution and the control maintainers have over downstream code. The PEM-encoded cryptographic objects are cited as a design concern during review; the report does not say that a production break has already happened.
Reviewing Public Type Contracts
For Java teams adopting sealed types, the immediate step is to review whether a type is internal to a component or exposed for independent clients to consume. Library maintainers can assess whether adding permitted subtypes should be treated as a breaking API change, and document how clients should handle the type.
Consumers should account for both build paths: recompilation can reveal missing cases early, while a separately updated library can leave an older switch exposed to a runtime failure. Madden’s report does not announce a Java language change or a scheduled follow-up. The issue remains one of API design and release policy; the practical outcome will depend on how maintainers and clients manage future subtype additions.
Key Questions
What does exhaustive pattern matching mean in Java?
It means a switch covers every case the compiler can identify for a type, including the permitted subtypes of a sealed type. If all cases are covered, a default branch may not be needed.
Why can adding a subtype break a consumer?
A consumer’s switch may handle only the old set of subtypes. If the consumer is recompiled against the updated type, the compiler can reject the missing case. If it is not recompiled, processing the new case can result in a MatchException.
Does every sealed-type change cause a runtime error?
No. The runtime risk described by Madden applies when the type changes but consumer code is not recompiled, and the consumer encounters a subtype it does not handle. Rebuilding can instead expose the missing case at compile time.
Should sealed types be used in public Java APIs?
Madden advises caution when exposing sealed types across independently updated components. He considers them more useful within a component that can be rebuilt together, but that is his design assessment rather than a universal requirement.
Source: hn
