JEP-360 Sealed types and non-accessible subtypes

[Kłeczek, Michał]

Thanks for detailed answer.

On 01/12/2019 18:28:50, "Brian Goetz" <brian.goetz at oracle.com> wrote:

>
>>  Introduction of exhaustiveness check also means adding a new permitted subtype is an incompatible change
>>  - similar to adding a value to existing enum.
>
>Yes, this is exactly analogous to the enum case.  When the compiler identifies that a switch is exhaustive, it compiles in a default case anyway, which throws the obvious exception.
I think there is a subtle difference here. The subtlety is that 
traditionally adding a subtype does not require any change in the client 
code depending on the super type (as per Liskov Substitution Principle).
I am wondering how surprising it will be that adding a non-public class 
(in the same compilation unit as the sealed super type) breaks existing 
clients.
Maybe - if exhaustiveness check is so important - it is better to force 
explicit declaration of permitted subtypes - at least that would make it 
clear that adding one is an API change.

Thanks,
Michal