ClassLoader.getResources(String)

[Alan Bateman]

On 07/02/2018 16:56, Stephen Colebourne wrote:
> :
> I was using maven to create a jar-with-dependencies file, so I could
> use jlink. With all the code in one jar file, there shouldn't be any
> access barriers to worry about.
>
> ClassLoader.getResources(String) worked just fine until Java 9. The
> two APIs are not comparable - the ClassLoader one returns all URLs
> found, whereas the Class one returns just one URL. Switching API would
> change behaviour.
ClassLoader.getResources searches the class path as it did in JDK 9 and 
older, it it just can't locate non-".class" resources in modules when 
they are encapsulated. Class loaders are oblivious as to who is 
ultimately attempting to load a class or locate a resource (the 
initiating and defining loader can be different, they can many class 
loaders in the delegation chain).

With the uber modular JAR scenario then all classes for several 
libraries are in the same module. This means that the names of resources 
in that module are unique. If several libraries have the same resource 
then I assume you drop all but one when you create this uber JAR (or 
maybe you are merging some of the configuration files, I can't tell). So 
I assume you could change this code to use Class.getResource and it will 
locate at-most-one resource with a specific name.

To do a proper migration means re-examining ResourceConfig of course. 
Using services is likely to be a lot cleaner and more robust than 
scanning for configuration files.

-Alan