<i18n dev> RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v7]

[Per Minborg]

On Mon, 13 Oct 2025 14:41:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/LazyConstant.java
>>   
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 287:
> 
>> 285:      */
>> 286:     @Override
>> 287:     boolean equals(Object obj);
> 
> There is a tension here (same for hashCode). A lazy constant is a mutable cell that can be updated only once, given some computing function. When you compare two lazy constants, you can either compare the mutable cell (e.g. the pointer to the memory location where the constant will be eventually stored), or you can compare the constants. Here, the javadoc decides to opt for comparing the constants -- but this might be problematic, as now `equals` can throw exceptions too (and/or result in blocking, as you say in the javadoc). So, I'm not too sure what's the best option here -- do we have an idea of how frequent it is to want to compare two lazy constants "by value" ?
> 
> (for reference, we have no precedent for this: `ClassValue`, `ScopedValue` and `ThreadLocal` do not redefine equals/hashCode).

I have reverted back to the default Object::hashCode and Object::equals methods

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2435655625