StableValue vs Optional

[Maurizio Cimadamore]

Hi Mickael,
I think at a very high level, a stable value is just a supplier of some 
value, lazily computed. So, the most minimalistic type to model that 
would be a Supplier<T>. In fact, this is what the StableValue provides 
as well (StableValue has a factory that takes a supplier and gives you 
back a lazy supplier).

But, if you zoom in, a stable value is also this "weird" 
mutable-only-once cell, which is effectively a safe wrapper around a JVM 
@Stable field.

When I think of Optional, I don't think of state transitions. An 
optional either is empty, or it's not empty -- pretty much like a Maybe 
type in a functional language. But, at this more fundamental, particle 
level, 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), there are some use cases where 
clients might want to control mutation of a stable value more 
imperatively -- which is why just exposing a Supplier (or an Optional) 
is not enough to cover all possible uses.

The way I read what you write is that, maybe, it could be desirable to 
provide yet another view of a stable value -- e.g. like you can 
construct lazy lists, stable suppliers and functions, maybe being able 
to create a "lazy" optional backed by a stable value is a possibility. 
But I view this more as an interop move between two logically distinct 
APIs. In fact, if Optional had a supplier-accepting factory, then you 
could bridge the two APIs by passing a stable supplier to such a 
factory, and there's your lazy optional.

Maurizio

On 17/06/2025 10:36, Mickael Istria wrote:
> Hi all,
>
> (I'm new around here, so please excuse me for this late comment or in 
> case this was already discussed in some place I missed; I have seached 
> Jira and the mailing-list via search engine unsuccessfully).
>
> I just discovered the StableValue proposal of JEP-502, that's a 
> preview feature for Java 25. I really welcome such change as -like 
> most Java developers- I've had to repeat some boilerplate code to 
> create cached values.
> However, I have the impression that StableValue is a bit redundant 
> with Optional, and that maybe another approach based on Optional could 
> work.
>
> Concretely, I'm thinking of just adding some static constructor to 
> Optional that would be like `Optional<T> 
> Optional.supplyNullable(Supplier<T> supplier)`, one would be able to 
> use it in such way:
> ```
> Optional.supplyNullable(() -> {
>   String res;
>   ...compute res...
>   return res;
> })
> ```
> and for more complex cases
> ```
> Optional.supplyNullable(new Supplier<String>() {
>   private int state = 0;
>   @Override
>   String get() {
>     return stateful() + stateful() + stateless();
>   }
>
>   private String part1() {
>     return Integer.toString(state++);
>   }
>   private String part2() {
>     return System.getProperty("jvm.vendor");
>   }
> })
> ```
>
>
> and that would leave the ability to fully encapsulate/isolate the 
> field computation in the provided supplier (just like the StableValue) 
> and that would provide at least the immutability goal of StableValue. 
> I'm not much aware of the Optional internals to know whether it would 
> fit other requeirements (I actually didn't spot any other requirements 
> on the JEP)
> So I'm just sending that here so that this 
> `Optional.supplyNullable(,,,)` approach gets considered as an 
> alternative. I honestly don't know whether it'd be better, I just have 
> a strong feeling that it can be worth having it evaluated as an 
> alternative in the JEP before things get final.
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/8ffde3d4/attachment-0001.htm>