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

[Maurizio Cimadamore]

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 188:

> 186:  *          arbitrary depth can be used, which provides constant components.
> 187:  *          More generally, a lazy constant can hold other lazy constants of
> 188:  *          arbitrary depth and still provide transitive constancy.

I'm not sure the term "constancy" is common to mean constant-ness. I think it might be better to use the term "constant-folding" -- and then define "constant-folding" in the above "performance" section:

>  A lazy constant can never change after it has been initialized. Therefore,
> a JVM implementation may, for an initialized lazy constant, elide all future reads
>  of that lazy constant, and instead directly use any constant that it has previously
>  observed

Then you can add "we call this optimization constant-folding".

src/java.base/share/classes/java/lang/LazyConstant.java line 192:

> 190:  *          The {@code LazyConstant} type is not {@link Serializable}.
> 191:  *          <p>
> 192:  *          It is not recommended putting lazy constants into equality-based collections

Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok?

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

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