How does classloading work with multiple child layers?

[Alan Bateman]

On 14/04/2020 20:48, Alex Sviridov wrote:
> Hello everybody,
>   
> I try to understand how classloading works when there are multiple child layers
> and have a problem.
>   
> Let's consider the following situation. There are three layers.
> BootLayer (moduleA)
>       |
>       |_______Child1(moduleB)
>                  |
>                  |__________ Child2(moduleC)
>   
> Child1 is the child of the BootLayer, Child2 is the child of the Child1.
>   
> Child1 and Child2 were created with the same code:
> ClassLoader parentClassLoader = ClassLoader.getSystemClassLoader();
> ModuleLayer layer = parentLayer.defineModulesWithOneLoader(cf, parentClassLoader);
>   
> As you see the parent class loader of both child layers is SystemClassLoader.
>   
> I am a beginner at classloading, but I've read about parent-first delegation model. However, if for both child layers SystemClassLoader is used, then why they see classes from other layers? I mean, why does moduleC
> see classes from moduleB if the parentClass is SystemClassLoader (SystemClassLoader as I understand
> delegates to BootLayer, but not to Child1 layer). Could anyone explain?
>
Module layers are an advanced topic. ClassLoaders are also an advanced 
topic. When working with module layers and using the 
defineModulesWithXXX methods to create the module layers, then you 
mostly don't need to be too concerned with class loaders. They are still 
used to load classes but they are mostly in the background (and not in 
your face).

You also don't need to be too concerned with the "parent class loader" 
that you specify to the defineOneWithOneLoader method. It's not used 
when loading classes from modules, it's only when for cases where the 
code in moduleB or moduleC tries to load a class that is not in a 
module, maybe Class.forName("Foo") where Foo is on the class path. So 
probably best to ignore the parent class loader when starting out.

The API docs [1] explain how the delegation works with modules but maybe 
it's not clear enough for what is needed here. In your example, support 
L1 is the class loader for module B in child layer 1, and L2 is the 
class loader for module C in child layer 2. Further suppose the module 
declarations are:

module moduleC {
     requires moduleB;
}

module moduleB {
     exports b;
}

The configuration for Child1 is very simple: one moduleB that reads 
java.base

The configuration for Child2 is also very simple: one moduleC that reads 
moduleB and java.base.

When Child1 is created it will create L1 and map moduleB to L1. When 
code in moduleB tries to resolve a reference to a class in its own 
module then it will be loaded by L1 (no delegation). When moduleB 
references a class in java.base then L1 will delegate to the boot loader.

When Child2 is created it will create L2 and map moduleC to L2. When 
code in moduleC tried to resolve a reference to a class in its own 
module then it will be loaded by L1 (no delegation). When moduleC 
references a b.* class then it will be delegate to L2 to resolve the 
reference. When moduleC references a class in java.base then L1 will 
delegate to the boot loader.

If you draw this out then you should see that the class loader 
delegation is "direct delegation" and exactly mirrors the edges in the 
readability graph (Configuration object).

Hopefully this is enough to get your started. It really needs diagrams 
and graphs to explain some of these details probably. As I said, you can 
mostly ignore class loader details when working with module layers.

-Alan

[1] 
https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/ModuleLayer.html#defineModulesWithOneLoader(java.lang.module.Configuration,java.util.List,java.lang.ClassLoader)