> 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
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
> 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
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
> 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).
>
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
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
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
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
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
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
11 matches
Mail list logo