Upgrading an existing ClassLoader to support modules

[Thomas Watson]

> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Thomas Watson/Austin/IBM at IBMUS, jigsaw-dev at openjdk.java.net
> Date: 10/26/2016 01:58 PM
> Subject: Re: Upgrading an existing ClassLoader to support modules
> 
> On 26/10/2016 16:53, Thomas Watson wrote:
> 
> > :
> >
> > If you are mapping your own custom class loaders using
> > Layer.defineModules(Configuration, Function<String, ClassLoader>) then 
you
> > need to be sure to override the method 
ClassLoader.findResource(String,
> > String) for your custom class loaders when running on Java 9. 
Otherwise
> > you will find Class.getResource always returning null.  Sorry if this 
is
> > widely known here, but it surprised me.
> >
> (I've changed the subject line as this is not related to the patch to 
> add support for naming class loaders).
> 
> If you are upgrading an existing class loader to support load of classes 

> and resources from modules then you need to override the 2-arg findClass 

> and 2-arg findResource methods. Both methods do have javadoc to say this 

> (but you are right, you have to go look for it). Note that there is 
> deliberately no subtype of ClassLoader defining these two as abstract 
> methods, ditto for an interface that would add this support.
> 
> -Alan
> 

Thanks.  I'm curious when this method gets used.  I suspected it was by 
the built-in jdk.internal.loader.Loader loaders, but when I override this 
method I don't see it ever getting called.  It seems to be used by the 
package private method ClassLoader.loadClass(Module module, String name) 
but it is unclear when this is used.  In my experiment I have a Layer with 
mapped custom class loaders and then I have a child layer using the 
default jdk.internal.loader.Loader loaders.  I observe the 
jdk.internal.loader.Loader is successfully delegating to to my custom 
loaders in the parent layer.

Tom