[sealed] Runtime checking of PermittedSubtypes

[Dan Smith]

> On Apr 22, 2020, at 1:38 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> Iterating on the JVMS changes for sealed types, I've been refining the details of the runtime check.
> 
> Two assertions, which I want to validate:
> 
> - The run-time modules of a subclass and a sealed superclass must be the same.
> - The defining class loaders of a subclass and a sealed superclass must be the same.
> 
> The first is a forced move, as discussed previously: the subclass and superclass must refer to each other, and mutual recursion is impossible between different modules (there are no module dependency loops).
> 
> The second is implied by the first: "A run-time module is implicitly bound to exactly one class loader, by the semantics of defineModules." (JVMS 5.3.6)


Another module system sanity check: is mutual recursion allowed between unnamed modules of different loaders? (Pre-9, mutual recursion between different loaders was certainly possible...)

If so, there's a design choice here about whether we will prohibit a class in unnamed module M1 from extending a sealed class in unnamed module M2.

> If this is true, then when we load the subclass, the superclass validation check should look like this:
> 
> 1) If the superclass is ACC_FINAL, error.
> 2) If the superclass has a PermittedSubtypes attribute, then:
> 2a) If the superclass belongs to a different run-time module, error.
> 2b) If the superclass doesn't have the subclass's name in its PermittedSubtypes, error.

If we're simulating resolution, which I think is the goal here, then I guess we also need:

2c) If the subclass isn't accessible to the superclass, error.

It's a little risky talking about the accessibility of a class that doesn't exist yet, but this currently amounts to testing for ACC_PUBLIC or same package name. (We'll want to revisit this if we eventually support ACC_PRIVATE classes in nests.)