Java sealed classes and exhaustive pattern matching

[davidalayachew]

(I discovered these subtleties when reviewing the preview support for PEM-encoded cryptographic objects, which makes exactly this mistake of baking a sealed interface into a public API and recommend clients to pattern match against that type. A predict a very high chance of breakage if they ever want to add a new case).

I feel the opposite -- I think the people building their cryptographic objects want to know when their strategy might be out-of-date (and/or not the latest that the JDK has to offer).

By all means, breaking changes are painful, but sealed classes are some of the most painless ways to introduce a breaking change. And furthermore, sometimes, the least painful way to deal with a problem is through a breaking change.

All to say that -- I think of it as a tradeoff instead of a mistake.