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