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" <[email protected]> > To: Alan Bateman <[email protected]>, [email protected] > Date: 10/26/2016 10:44 AM > Subject: Re: Request Review: JDK-6479237 (cl) Add support for > classloader names > Sent by: "jigsaw-dev" <[email protected]> > > 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 >
