<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>I believe there is definitively possible overthinking at play
here.</p>
<p>Some notes:</p>
<p>* in any case, we have at least _two_ primitives (either orElse +
get, or tryGet + get). That's because one primitives triggers
initialization, the other doesn't.<br>
* orElse is similar to what we do in ScopedValue. There's not many
other APIs that do this.<br>
* creating an optional is more expensive -- but with Valhalla
costs will likely go down and be comparable<br>
* returning an Optional might also be confusing because the
Optional is a _snapshot_ at some point in the lifecycle of the
lazy constant -- e.g. you can get an empty optional with tryGet(),
then call get(). Now the previously returned optional is not in
sync with the lazy constant (not sure how much this is a concern
-- but listing it here as a possible element of confusion)<br>
* in all possible worlds, it seems that `isInitialized` can be
derived, either from orElse, or from tryGet. That said, for a
construct called LazyConstant, I think asking whether the constant
is initialized or not seems a good method to have, and can also be
used to explain some of the behavior of the API (e.g. in the
javadoc). So I'm not sure I'd be ok with going the full way and
drop it.</p>
<p>Given all this, possible way forwards would be:</p>
<p>1. keep everything as is (after all, we got here for a reason)<br>
2. drop orElse, and keep just get/isInitialzied (on the basis that
the internal optimization of orElse is not really worth it. We can
also always add it at a later point compatibly)<br>
3. drop orElse and replace it with tryGet or some
Optional-returning equivalent</p>
<p>I don't have strong opinions on either of these. Perhaps, the "if
in doubt leave it out" angle should win (2).<br>
</p>
<p>Maurizio<br>
</p>
<p>On 09/12/2025 14:12, Anatoly Kupriyanov wrote:</p>
<blockquote type="cite" cite="mid:CAGwStpDwTkJXdRoevW=HEC4gz+rZ78oPzQPGgXbr1Z11K0bM+Q@mail.gmail.com">
<div dir="ltr">
<div>My idea is not an optional <i>interface</i>, but an
interface for something which is convertible to the Optional <i>type</i>.
In other words, neither the LazyConstant nor to
ScopedVariable <b>is not</b> an optional itself, but could be
converted to it uniformly.</div>
<div>Something like this:</div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace">interface
Optionable<T> {// need to think about the better
naming!</span></div>
<div><span style="font-family:monospace"> T orElse(T other);</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"> // and maybe even:</span></div>
<div><span style="font-family:monospace">
default Optional<T> asOptional() {</span></div>
<div><span style="font-family:monospace"> return
Optional.ofNullable(this.orElse(null));</span></div>
<div><span style="font-family:monospace"> };</span></div>
<div><span style="font-family:monospace">}</span></div>
<div><br>
</div>
<div>and then LazyConstant, ScopedVariable, etc could just
implement the interface to unify on the notion of "return a
user-provided value <br>
if some condition isn't met". Sounds like a decent path to
abolish nulls.</div>
<div><br>
</div>
<div>But I feel I am overthinking this...</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, 9 Dec 2025 at 13:35,
Red IO <<a href="mailto:redio.development@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">redio.development@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">I initially thought I agree with your
statement that orElse is a common pattern in the jdk. But
then I failed to come up with a second example. I then
searched the jdk github repo for the method. And I only
found Optional and it's specializations and
ClassHierarchyResolver.
<div dir="auto">So I would suggest yes, it's an often used
method ... of the Optional class. Not many apis seem to
expose it. The case of exposing an accessor that returns
an Optional on the other hand is incredibly common across
the jdk. This is exactly the case Optional was designed
for. In this sense Optional is the "Interface" you are
suggesting. </div>
<div dir="auto"><br>
</div>
<div dir="auto">My main argument against reusing orElse here
is that the context is a completely different one. </div>
<div dir="auto">An Optional orElse method is a pure function
that always returns the same value. It signals that the
value is not there.</div>
<div dir="auto">LazyConstant is different in this regard.
The LazyConstant orElse is not pure at all. It depends on
rather someone else already initialized the value or not.
It signals that the value is not there YET.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Great regards </div>
<div dir="auto">RedIODev </div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Dec 9, 2025, 13:51
Anatoly Kupriyanov <<a href="mailto:kan.izh@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kan.izh@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Right, the ScopedValue is another good example I've
forgotten. In that case I am even more inclined to
keep the `orElse` as it looks like a repeating pattern
across JDK libraries. Consistency is the way to go!</div>
<div>And maybe even consider having a new interface
for the method to make this pattern explicit?..</div>
<div><br>
</div>
<div>I am glad that `orElseSet` is removed, the
side-effecting is bad; also in other parts of JDK we
already have `computeIfAbsent` for the same idea. I
did not hear about it, and yeah, sounds like the
source of this confusion.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 9 Dec 2025 at
12:05, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 09/12/2025 11:59, Anatoly Kupriyanov wrote:<br>
> To be honest, I don't really see why this method
causes such confusion.<br>
<br>
In part I agree. E.g. when we added this, what we had
in mind was just<br>
<br>
<a href="https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T)" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T)</a><br>
<br>
E.g. other APIs have `orElse` method that return a
user-provided value <br>
if some condition isn't met.<br>
<br>
I believe the problem we're discussing here is likely
also related to <br>
the fact that the API used to have a side-effecting
`orElseSet`, which <br>
is now removed, and I wonder if, because of that,
folks are reading too <br>
much into what orElse does?<br>
<br>
Maurizio<br>
<br>
</blockquote>
</div>
<div><br clear="all">
</div>
<br>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">WBR, Anatoly.</div>
</blockquote>
</div>
</blockquote>
</div>
<div><br clear="all">
</div>
<br>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">WBR, Anatoly.</div>
</blockquote>
</body>
</html>