[sealed] Runtime checking of PermittedSubtypes

[Alex Buckley]

On 4/22/2020 1:43 PM, Remi Forax wrote:
>> 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.
>>
>> 2b doesn't need to load anything, because 2a has guaranteed that both classes
>> have the same defining loader. (We do the same thing with nestmates.)
>>
>> I'm a little unsure about 2a, though, because I don't have a great grasp of how
>> modules work—when I'm still deriving a class (JVMS 5.3.5), can I tell what my
>> runtime module will be?
> 
> From the class name which is qualified, you have the package name and from a package name and a classloader, you have the module.
> A module knows all the packages inside itself, during the modules resolution, each module advertise all its packages, so when a classloader on a resulting configuration, it knows the Map<Package, Module>.
> If the classloader doesn't find the module associated to a package, it means that it's a package from the classpath, so the package will be created lazily using the unamed module of the classloader.

As Remi says, by the time class loading happens, a layer has already 
been set up to map modules (and hence their packages) to loaders. JVMS 
5.3.6 discusses this, including the possibility that a class is "in a 
run-time module".

We made a big deal in Java 9 about how "Class Loading Doesn't Change" 
for the module system -- there's no additional argument to loadClass or 
defineClass to indicate module membership -- but it is legitimate in 
Java 15 for defineClass to start caring about module membership because 
it's done to respect sealing rather than to support the module system 
itself.

Alex