ClassLoader.getResources vs Module.getResourceAsStream

[Michał Zegan]

What is then a recommendation for searching for all resources with name
x that i can access? Something like load all configuration including
some kind of extensions. I cannot list resources easily.

W dniu 14.07.2018 o 17:31, Alan Bateman pisze:
> On 14/07/2018 14:00, Michał Zegan wrote:
>> Hello.
>> When reading docs for jdk9 and jdk10 it seems that those methods work in
>> a bit different way when it goes to encapsulation:
>> Module.getResourceAsStream will retrieve the resource without a problem
>> if a package is opened to the caller module, probably including the fact
>> that it will find a resource when the calling module is the same as one
>> represented by the module object.
>> But, ClassLoader.getResources and other resource methods seem to require
>> unconditional package open.
>> Why? I don't quite understand that distinction.
> ClassLoaders, especially in a delegation chain, have no notion of "who"
> is trying to locate the resource. The ClassLoader.getResourceXXX methods
> are also not final. All told, the ClassLoader.getResourceXXX cannot
> reliably support qualified opens so this is why they are specified to
> only locate resources in modules when the package is open to all modules.
> 
> The general guideline is to use Class or Module getResourceXXX when you
> want to locate a resource in your own module or another specific module.
> Use ClassLoader.getResourceXXX when you want to search the class path.
> If you follow that then it makes it a lot easier to migrate existing
> code to modules.
> 
> -Alan