ModuleLayer.Controller strongly references Module

[Michał Kłeczek]

> On 29 Nov 2021, at 10:29, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> It looks like ML.Controller.addExport(source, pn, target) does not update the target module ClassLoader view of exported packages in the default ClassLoader implementation (jdk.internal.loader.Loader).
>> What is the reasoning behind such implementation? I am wondering now how useful Controller.addExport() really is...
>> 
> The addXXX methods are about accessibility. In the case of addExports then maybe you want to export an internal package so that code in a module in the child layer can make use of (via reflection) public classes in that package.
> 
> You are right that the addXXX methods doesn't do any magic for visibility. For super advanced cases where someone is using their own class loaders then they need to ensure that the class loader delegation supports the readability graph. Same thing when they use addExports where they may need to their class loaders to adjust their delegation to support changes at run-time.

Thanks for explanation.
Unfortunately, I couldn’t find any good in-depth documentation covering Module, ModuleLayer and ClassLoader interaction. Could you point me to anything useful?

In my case I wanted to avoid implementing my own custom ClassLoader but actually doing that allows for easier management of ML.Controller lifetime: the ClassLoader can keep the reference to it.

In the end I ended up with one-to-one relationship between ML, Module and custom ClassLoader that form a cycle that can be GCed.

Thanks for help.

-- Michal