[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
itself.
Alex
More information about the amber-spec-experts
mailing list