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
