> From: Alan Bateman <alan.bate...@oracle.com> > To: Thomas Watson/Austin/IBM@IBMUS, jigsaw-dev@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
