JEP-360 Sealed types and non-accessible subtypes

[Brian Goetz]

> 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.

If all the types are public/exported, and you add a first non-exported one, then yes, this is binary-but-not-source-compatble (but the impact on clients is still pretty minimal, they need to add a default clause on their next recompilation.)  If you _already_ have at least one nonpublic/nonexported subtype, then adding a second does not risk breaking anything, since clients would _already_ be doing so.  

In any case, this is a deliberate tradeoff; it has to be possible to evolve sealed APIs somehow, otherwise it is too brittle.  This seemed the best place to draw this line.  

> 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.

We did consider this, but this also seemed like a bad tradeoff — making all APIs explicitly list all their subtypes — when they are declared RIGHT THERE — would be seen as just being mean, for little benefit.  So again, this seemed the best way to balance the various concerns.