StableValue vs Optional

[Maurizio Cimadamore]

On 17/06/2025 13:55, Mickael Istria wrote:
> Thanks for your answer.
>
> > the most minimalistic type to model that would be a Supplier<T>.
>
> Indeed. I mentioned Optional, but as the discussion goes, what could 
> work instead of an Optional would be a constructor 
> `Supplier.cache(Supplier<T> computer)` that would cache the computed 
> value. That would be even better than Optional.

Note that this is already part of the StableValue API:

https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)

>
> >  a stable value is also this "weird" mutable-only-once cell, which 
> is effectively a safe wrapper around a JVM @Stable field.
>
> OK, for that part, as I have no knowledge of how @Stable works, I 
> fully trust you.

Some pointers:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java

(might be useful, as an exercise, to read through the documentation of 
that internal annotation, and connect the dots back to the StableValue API)

>
> > a stable value is very much a mutable beast, so we need an API that 
> is able to model this at-most-once mutation. While in most cases the 
> mutation is not really interesting (because clients are more 
> interested in the laziness aspects)
>
> Indeed, I admit that my comment was only built on the use-case of 
> lazily initialized values; which seem to be only a corner case of 
> StableValue's goal; and I agree that some more dedicated API to lazily 
> initialized value (eg `Supplier.cache(Supplier<T> computer)` or 
> `Optional.supplyNullable(Supplier<T> computer)` still could make sense 
> independently of StableValue which has a slightly broader scope.
Cheers
Maurizio
>
> Thanks again.
> Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/32bc9a9c/attachment-0001.htm>