JEP proposed to target JDK 26: 526: Lazy Constants (Second Preview)

[Maurizio Cimadamore]

Hi Sergey

On 07/11/2025 01:23, Sergey Bylokhov wrote:
> Hello,
>
> It might be worth clarifying in the JEP text that a LazyConstant field 
> should also be declared as final.
>
> For example, consider this case:
>
>     private LazyConstant<OrderController> ORDERS = LazyConstant.of(...);
>
> The value is initialized lazily, but since ORDERS isn’t final, can the 
> JVM reliably inline it?
>
> In the “Flexible initialization with lazy constants” section, the 
> table currently lists and compares three cases:
>
> 1. "final field"
> 2. "LazyConstant"
> 3. "non-final field"
>
> It might be useful to clarify that a LazyConstant field has all the 
> benefits of a final field only if the field itself is declared as 
> final. Otherwise, it behaves more like a non-final field, despite 
> using a LazyConstant object.

I think there's enough bread crumbs for the readed.

The table compares how many times, and when assignment occurs. No need 
to mention final here.

The first part that brings up constant folding is the para that starts with:

 > There is, furthermore, mechanical sympathy...

This para includes this sentence:

 > This allows the JVM to treat the content of a lazy constant as a true 
constant, provided that the field which refers to the lazy constant is 
|final|

Which seems "close enough" to the performance claim.

Also, in the "Risks and assumptions" section at the end of the JEP, 
there is a further note:

 > The JVM can apply constant-folding optimizations only when it can 
trust that |final| fields can be updated only once.


> BTW how is it expected to work if the LazyConstant is created and 
> stored in a local variable?
I don't know if we have benchmark for this. Per do you have anything?
>
> Also, there’s a small cosmetic issue in the code examples, the use of 
> the private modifier is inconsistent. In some examples it is included, 
> while in others it is omitted.

Thanks, we will fix.

Cheers
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20251107/397c01f2/attachment-0001.htm>