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

Reply via email to