> On Apr 22, 2020, at 1:38 PM, Dan Smith <daniel.sm...@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.)
