StableValue vs Optional

Mickael Istria mistria at redhat.com
Tue Jun 17 12:55:58 UTC 2025


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.

>  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.

> 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.

Thanks again.
Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/9a0d9634/attachment.htm>


More information about the core-libs-dev mailing list