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