<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link id="MDHR_textcomplete" rel="stylesheet" href="moz-extension://aa8b6de7-3f78-465d-87c7-03091dbf00e6/vendor/textcomplete.css">
</head>
<body>
<p>Hi Mickael,<br>
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).</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 17/06/2025 10:36, Mickael Istria
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com">
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>(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).</div>
<div><br>
</div>
<div>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.</div>
<div>However, I have the impression that StableValue is a bit
redundant with Optional, and that maybe another approach based
on Optional could work.</div>
<div><br>
</div>
<div>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:</div>
<div>```</div>
<div>Optional.supplyNullable(() -> {<br>
String res;<br>
...compute res...<br>
return res;<br>
})</div>
<div>```</div>
<div>and for more complex cases</div>
<div>```</div>
<div>Optional.supplyNullable(new Supplier<String>() {</div>
<div> private int state = 0;</div>
<div> @Override</div>
<div> String get() {</div>
<div> return stateful() + stateful() + stateless();</div>
<div> }</div>
<div><br>
</div>
<div> private String part1() {</div>
<div> return Integer.toString(state++);</div>
<div> }</div>
<div>
<div> private String part2() {</div>
<div> return System.getProperty("jvm.vendor");</div>
<div> }</div>
</div>
<div>})</div>
<div>```</div>
<div><br>
</div>
<div><br>
</div>
<div>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)</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Mickael Istria<br>
</div>
<a href="https://www.eclipse.org/eclipseide" target="_blank" moz-do-not-send="true">Eclipse IDE</a>
developer, for <a href="https://developers.redhat.com/" target="_blank" moz-do-not-send="true">Red Hat</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<ul class="dropdown-menu textcomplete-dropdown" style="display: none; position: absolute; z-index: 1000;" contenteditable="false" popover="auto">
</ul>
</body>
</html>