Hi Alan, thanks for the quick response. Please find my answers inline
On Wed, Mar 3, 2021 at 1:38 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 03/03/2021 10:43, Volker Simonis wrote: > > : > > > > My question now is if this is an inherent property of the module > > system or merely an implementation detail? I.e. would it be possible > > to put the application module into its own layer and initialize that > > only later when the custom system class loader will be available? I > > think this would be relatively easy if the custom class loader can be > > found on the class path. If the custom class loader is in a module > > itself, that module would have to be in the boot layer to make it > > accessible to the default system class loader. > The ability to set a custom class loader as the system class loader is > somewhat legacy feature. There was consideration given to deprecating > and removing it a few years ago but we ended up leaving it "as is" in > case there are still application servers using it. So it should work the > same in JDK 16 as it did in JDK 8/older releases. That is, it will be > created with the built-in application class loader as parent and the > custom system class loader will be the default parent class loader for > delegation. > > You are correct that an initial module on the application module path > will be loaded by the built-in application class loader. All modules on > the application module path are mapped to the built-in application class > loader. If an initial module is specified to the java launcher (--module > or -m) then it just locates the module in the boot layer and invokes its > main class. There is no role for a custom system class loader here. > > If you are looking to deploy a custom system class loader in a module on > the module path then it should work as long as you export the package > with the custom class loader to java.base. I'm not sure if you really > want to do this or whether it's a means to an end. Maybe it would be > easier to start with a summary on what you are looking it do? Are you > looking to intercept all attempts to load classes? Is there a java agent > in the picture too? I have currently no specific use case in mind. I was just doing some experiments and was hoping that I can intercept the loading of all application classes by defining a custom system class loader. I'm aware that I can use the JVMTI "ClassFileLoadHook" to intercept the loading of ALL classes, but that's just a little more complicated :) > > The current API documentation of the system class loader [1] mentions > > that the system class loader "is typically the class loader used to > > start the application". Shouldn't that be updated to mention that this > > will not be the case for modular applications? > The javadoc is correct because it will be rare to deploy with > java.system.class.loader set to a custom class loader. Assuming it is > not set then you should find that the initial class will be defined by > this class loader. This goes for both the class path and module path cases. Maybe I should have been more specific. I meant that the paragraph on "java.system.class.loader" should contain one more sentence mentioning that setting it will only have the desired effects for the loading of application classes for non-modularized applications. Thank you and best regards, Volker > > > -Alan > >
