[sealed] Module & package constraints

[Dan Smith]

I presented this as an outline of our choices, but to put a stake in the ground, here are my preferences.

> On Apr 23, 2020, at 12:27 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> 1) Is it legal to have a permitted subclass/subinterface that does not actually extend the permitting class or interface?

At compile time, no. Let's prohibit that.

At run time, delay any validation until a particular subclass is loaded.

> 2) What are the constraints on module membership?

At compile time, do nothing. Per (1), it's already impossible to successfully declare a sealed parent/child across a module boundary.

At run time, require the same run-time module. In the corner case of a parent/child split across class loaders (in unnamed modules), we say "sorry, don't do that." (I do think this will come up. Extension is an important way to communicate across class loader boundaries. But I think programs doing so need to accept that sealed types are not for them.)

> 3) What are the constraints on package membership?
> 
> The use case here is a class/interface extending a sealed class/interface, both in the same unnamed module.

At compile time, do nothing. Per (1), it's impossible to separately compile the parent and child, no matter what packages they are declared in.

At run time, there's nothing to enforce. I don't care how you've deployed your class files, as long as they successfully compiled and have the same module/loader.