JEP-360 Sealed types and non-accessible subtypes

[Brian Goetz]

> I am not sure I understand the second case. What I suggest is
> 
> public sealed interface A {}
> 
> would mean only types in the same module as A can implement/extend it.

Yes, I fully understand that this is what you are suggesting.  It was suggested in the early design of the feature, we considered about it, explored the pros and cons, and we decided it was not the best interpretation.  

> Generated class file does not need to contain any list of permitted subtypes
> - having an empty set means "any in the same module”.

Yes, obviously we could make the classfile format and runtime behavior more complex by having multiple modes for the PermittedSubtypes attribute (explicit list, package-only, module-only), and we did consider it, but I think the return-on-complexity is negative here. 

By saying “any class in the package/module”, you gain some flexibility as the author of the class, but it comes at a cost: then _no one_ gets the benefit of compile-time exhaustiveness checking.  (From an ecosystem perspective, this benefits some individual class authors, at the cost of _all_ users — which is likely to be worse for everyone in the aggregate.)  

By going the other way — always requiring an explicit list in the classfile, and then inferring it at compile time where we can _reliably_ do so, everyone gets the benefits of exhaustiveness checking (and more explicit documentation), at the cost of potentially a little more work for a subset of API authors.  That seems a far better tradeoff, so that’s the way we went.