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.bate...@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.
