[sealed] Runtime checking of PermittedSubtypes

Alex Buckley alex.buckley at oracle.com
Wed Apr 22 22:48:29 UTC 2020

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 


More information about the amber-spec-experts mailing list