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
