Hacker News Reader

Comment by misja111 | Hacker News Reader

> Although Java will produce a compile-time error for a non-exhaustive switch when you compile the consumer (main in this case), it cannot do so if the consumer is not recompiled when the sealed type changes

I think this is quite bad. I think such a change should break binary compatibility between the consumer and the producer api jar. Now any consumer might or might not run into runtime errors when switching to a new producer jar that is binary compatible.

View on HN

That is nothing new or specific to this feature. Mismatched client and library code produced MethodNotFoundException for decades. You can't really fight against partially recompiled/updated code. The only Java attempt of checking some kind of integrity was `serialVersionUID" (for serialization) and getting "java.io.InvalidClassException" at runtime wasn't fun, even if somewhat useful.

"binary compatibility" in the JVM sense shows up during runtime, anyway. The Throwable should maybe have been a subclass of LinkageError (which indicates a binary compatibility problem; though I'm sure there's a good reason why it isn't): Right now the MatchException can easily be caught by mistake, which wouldn't be an issue if it were a MatchError.

However, it doesn't change the behavior much: LinkageErrors can also happen any time at runtime, not necessarily during startup. Just like the MatchException.

This already happens though without sealed classes in existing code. If you have an interface A with implementing classes B and C, you'll eventually run into an error if the library starts emitting class D.

Not if you program to the interface. This kind of pattern matching is syntactic sugar for `instanceof` checks and down-casts. That’s fine within a module boundary (using “module” in a loose sense), but across module boundaries I think programming to an interface should still be the preferred solution.

Reply on news.ycombinator.com