On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> an
On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> an
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any stage during boot.
>
> Also, Scoped Value's constructor
On Tue, 1 Jul 2025 15:41:45 GMT, Alan Bateman wrote:
>> Andrew Haley has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - 8360884: Better scoped values
>> - 8360884: Better scoped values
>
> src/java.base/share/classes/java/lang/ScopedValu
On Tue, 1 Jul 2025 11:15:54 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> an
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any stage during boot.
>
> Also, Scoped Value's constructor
On Tue, 1 Jul 2025 08:21:10 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/ScopedValue.java line 802:
>>
>>> 800: return x;
>>> 801: }
>>> 802: };
>>
>> There's something a bit uncomfortable about initializing hashGe
On Mon, 30 Jun 2025 15:55:03 GMT, Alan Bateman wrote:
> There's something a bit uncomfortable about initializing hashGenerator in
> ScopedValue's class initializer, then changing it in Constants class
> initializer. Iimmediately clear what the memory model issues. It doesn't of
> course matter
On Mon, 30 Jun 2025 13:09:57 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> a
On Fri, 27 Jun 2025 15:44:16 GMT, Chen Liang wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move THREAD_LOCAL_RANDOM_ACCESS into class Cache.Constants
>
> src/java.base/share/classes/java/lang/ScopedValue.java lin
On Mon, 30 Jun 2025 13:09:57 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> a
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any stage during boot.
>
> Also, Scoped Value's constructor
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any stage during boot.
>
> Also, Scoped Value's constructor
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty().
Just a bit more context here. There are several places where a class
initializer may create a ScopedValue. This must be ver
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any s
On Fri, 27 Jun 2025 15:12:57 GMT, Chen Liang wrote:
> I looked at the existing code: the reason ScopedValue creation requires
> getProperty in Cache is that `generateKey` uses `Cache.primarySlot(x)` and
> `Cache.secondarySlot(x)`. Why did you choose to factor out `getProperty` into
> a new cla
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any s
Scoped values cannot be used early in the JDK boot process because of some
dependencies on System.getProperty(). This repen dency should be removed in a
way that allows scoped values to be created (but not necessarily bound) at any
stage during boot.
Also, Scoped Value's constructor has a synch
18 matches
Mail list logo