Request Review: JDK-6479237 (cl) Add support for classloader names

[Thomas Watson]

It sounds like I am doing a similar experiment as David.  Recently I ran 
into an issue with Class.getResource method.

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.

Tom



> From: "David M. Lloyd" <david.lloyd at redhat.com>
> To: Alan Bateman <Alan.Bateman at oracle.com>, jigsaw-dev at openjdk.java.net
> Date: 10/26/2016 10:44 AM
> Subject: Re: Request Review: JDK-6479237 (cl) Add support for 
> classloader names
> Sent by: "jigsaw-dev" <jigsaw-dev-bounces at openjdk.java.net>
> 
> On 10/26/2016 10:39 AM, Alan Bateman wrote:
> > On 26/10/2016 16:28, David M. Lloyd wrote:
> >
> >> :
> >>
> >> Some background is in order I guess.  I've been reworking a couple of
> >> our projects to support both Java 9 and Java 8, using MR JARs and 
also
> >> without MR JARs.  In the MR JAR case it's been easiest (so far) to
> >> push off the JDK-version-specific stuff into a nonpublic 
"JDKSpecific"
> >> class which gets replaced under Java 9. However, because the
> >> ClassLoader change requires a new constructor to be called, I 
actually
> >> have to put the whole ClassLoader implementation into the MR
> >> supplement, which is pretty clunky at best and might introduce some
> >> tricky build difficulties at worst.
> > Can you introduce an intermediate ClassLoader into the type hierarchy?
> > The 8 version will just invoke super(), the 9+ version will invoke
> > super(name). That would keep the JDK-specific code to a minimum.
> 
> Hmm, that's an idea.  I'll give it a shot, thanks.
> 
> -- 
> - DML
>