JEP-360 Sealed types and non-accessible subtypes

[Brian Goetz]

>> If all the types are public/exported, and you add a first non-exported one, then yes, this is binary-but-not-source-compatble
> While formally adding a subtype might be a compatible change (as the default case is always there) - in practice this is a breaking change
> (I cannot upgrade to a new version of the library _without_ any code changes - ie. by just replacing a jar file).
> Such a change is actually equivalent to removing a method.

I don’t think that word means what you think it means …  I suggest you review the definitions of source-compatible and binary-compatible?

Adding such a class is a _binary-compatible_ change, as existing classifies will load, constant pool entries will resolve, and existing callsites will link.  

It is possible that this is not _source-compatible_, in the event that there are explicitly exhaustive switches.  But in these cases, there is a straightforward remediation for the clients.  

Virtually any change may be _behaviorally incompatible_ (every bug fix is in this category).