Should ClassLoader::getResouces return the same resource twice?

[Johannes Spangenberg]

The bidirectional delegation is an important point. Beside that, you 
also mentioned that your custom class loader stores additional information.

> Unfortunately, I cannot only remove the jars from my classloader and 
> delegate
> to the classloader provided by the ModuleLayer because we use a custom 
> classloader,
> and have some important information stored in it, so by removing the 
> jars from the classloader
> all applications would stop working.

If you really need this information as part of the class loader, I fear 
you need to create custom class loaders for your modules together with 
ModuleLayer.defineModules [1] instead of 
ModuleLayer.defineModulesWithOneLoader. The class loader for 
ModuleLayer.defineModulesWithOneLoader is not public. I guess you would 
need to reimplement it. Maybe you can find other locations to store the 
information.

[1] 
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/ModuleLayer.html#defineModules(java.lang.module.Configuration,java.util.List,java.util.function.Function)

Am 04.01.2021 um 12:38 schrieb Thiago Henrique Hupner:
> Yes, that's exactly it. Sorry for all the noise in the previous emails.
>
> I'm not using a URLClassLoader in my application, I've only used it
> as an example because it is very easy to override to return a specific
> value (and not have to implement all the other methods).
>
> So, I guess I will need to have a look at the application classloader
> and update my current classloader to be able to do the bidirectional
> delegation. Do you have any recommendations about where to look?
>
> Thanks!
>
> Em seg., 4 de jan. de 2021 às 05:48, Alan Bateman <Alan.Bateman at oracle.com>
> escreveu:
>
>> On 03/01/2021 13:10, Thiago Henrique Hupner wrote:
>>> :
>>>
>>> I hope made it a little more clear. By now it is clear that it is loading
>>> the same
>>> resource twice because the same jar is in the classloader and in the
>> module
>>> layer
>>> classloader.
>> If I read your mail correctly you've got a class path today and you want
>> to "move" the well behaved components to a module path, leaving the
>> remaining the components that can't work as automatic modules on the
>> class path. It's equivalent to specifying both a module path and class
>> path to the java command line launcher. You also mention that you have
>> to use a custom class loader. If that class loader were updated to
>> support modules and load classes into its unnamed module then you should
>> be able to get this to work. This is very advanced territory and would
>> be approximately equivalent to the application class loader in the JDK
>> where it supports both modules and the class path. I don't think your
>> current approach of using a URLClassLoader as a parent will work as it
>> doesn't support the bidirectional delegation that would be need to get
>> this to work.
>>
>> -Alan.
>>