Re: ModuleLayer.Controller strongly references Module

2021-11-29 Thread Michał Kłeczek
> On 29 Nov 2021, at 10:29, Alan Bateman 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

Re: ModuleLayer.Controller strongly references Module

2021-11-29 Thread Alan Bateman
On 28/11/2021 22:29, Michał Kłeczek 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

Re: ModuleLayer.Controller strongly references Module

2021-11-28 Thread Michał Kłeczek
> On 24 Nov 2021, at 21:01, Alan Bateman wrote: > > On 24/11/2021 18:14, Michał Kłeczek wrote: >> >> >> For sure it’s fun :) >> >> Regardless of “smart proxies” the lifetime of ML.Controller should be - if >> not fixed - at least be documented IMHO. Right now it’s a minefield. > > It's al

Re: ModuleLayer.Controller strongly references Module

2021-11-24 Thread Alan Bateman
On 24/11/2021 18:14, Michał Kłeczek wrote: For sure it’s fun :) Regardless of “smart proxies” the lifetime of ML.Controller should be - if not fixed - at least be documented IMHO. Right now it’s a minefield. It's also somewhat unusual so I think we'll need to think if this is the right thi

Re: ModuleLayer.Controller strongly references Module

2021-11-24 Thread Michał Kłeczek
> On 24 Nov 2021, at 13:33, Alan Bateman wrote: >> >> 1. Controller is created upon ML construction and returned from static >> ML.defineModules methods. >> 2. Created two controller liveness tests (they rely on System.gc() though - >> not sure if there are some tricks to test it reliably). >

Re: ModuleLayer.Controller strongly references Module

2021-11-24 Thread Alan Bateman
On 24/11/2021 12:19, Michał Kłeczek wrote: Hi Alan, (Disregard previous message - fat fingers) Attached is a first draft of the patch: 1. Controller is created upon ML construction and returned from static ML.defineModules methods. 2. Created two controller liveness tests (they rely on System

Re: ModuleLayer.Controller strongly references Module

2021-11-24 Thread Michał Kłeczek
Hi Alan, (Disregard previous message - fat fingers) Attached is a first draft of the patch: 1. Controller is created upon ML construction and returned from static ML.defineModules methods. 2. Created two controller liveness tests (they rely on System.gc() though - not sure if there are some t

Re: ModuleLayer.Controller strongly references Module

2021-11-24 Thread Michał Kłeczek
Hi Alan, Attached is a first draft of the patch. Controller is created upon ML construction and returned from static ML.defineModules methods. > On 22 Nov 2021, at 21:37, Alan Bateman wrote: >> > Assuming it's not exposed, and that there is no reference to the > ML.Controller for the boot lay

Re: ModuleLayer.Controller strongly references Module

2021-11-23 Thread Michał Kłeczek
Hi Alan, > On 22 Nov 2021, at 21:37, Alan Bateman wrote: > > On 22/11/2021 07:23, Michał Kłeczek wrote: >> >> Would it be too much to ask for accepting a patch adding a reference to >> ML.Controller to ModuleLayer? >> It wouldn’t require changes to the spec I think as the lifetime of >> ML.Co

Re: ModuleLayer.Controller strongly references Module

2021-11-22 Thread Alan Bateman
On 22/11/2021 07:23, Michał Kłeczek wrote: Would it be too much to ask for accepting a patch adding a reference to ML.Controller to ModuleLayer? It wouldn’t require changes to the spec I think as the lifetime of ML.Controller is unspecified. Assuming it's not exposed, and that there is no re

Re: ModuleLayer.Controller strongly references Module

2021-11-21 Thread Michał Kłeczek
From OpenJDK discuss: > On 21 Nov 2021, at 21:55, Alan Bateman wrote: > > On 21/11/2021 13:27, Michał Kłeczek wrote: >> Hello All, >> >> I am looking for a way to associate ModuleLayer.Controller with a Module (or >> ModuleLayer) in such a way that it won’t disable garbage collection of >> Mo