> On 29 Nov 2021, at 10:29, Alan Bateman <alan.bate...@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
