Question about java.system.class.loader and the module system

[Volker Simonis]

Hi Alan,

thanks for the quick response. Please find my answers inline

On Wed, Mar 3, 2021 at 1:38 PM Alan Bateman <Alan.Bateman at 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
>
>