<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi David,<br>
I think what you suggest is outside the scope of the LazyConstant
API (as Per has already said).</p>
<p>The goal of LazyConstant is to provide an easy to use abstraction
for lazy initialization that addresses the 90% use case (e.g.
deferred initialization using a lambda).</p>
<p>There will be another, more imperative API that can be used to
build what you want.</p>
<p>But what we have learned when working on this project, is that if
we increase the scope/reach of LazyConstant to include more
imperative aspects, it ends up with confusion pretty quickly.</p>
<p>The design you proposed was considered -- and rejected. While it
holds together, the fact that the initialization action provided
at creation acts now as a "fallback" initialization action, and
can be overridden by use sites calling computeIfAbsent was deemed
surprising and/or confusing.</p>
<p>Regards<br>
Maurizio<br>
</p>
<div class="moz-cite-prefix">On 09/12/2025 14:46, david Grajales
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADFQZ77Z0dUBPn=054CzyqJQhpQgksaNeJ3a5FTB0XP-zKx22g@mail.gmail.com">
<div dir="ltr">I am glad my feedback was helpful and sparkled such
a great discussion. I would like to put 2 cents more, looking
for these to be helpful.
<div><br>
</div>
<div>My main concern with "orElse" is that most of the time (at
least for my how I would use this API in my job) most of the
time I need a reliable way to set the constant and use that
particular constant along the life cycle of the class, **not**
declaring an alternative local variable in replacement because
most of the time there is no good "burned in the code"
alternatives that I could use . The use cases I have for this
API are usually about deferred initialization of values that
often require some time costly operation, some of those may
involve calls to external services (IO operations) thus having
a "burned" constant in these cases is not useful. Instead I
propose a "computeIfAbsent" (I am not against orElse naming)
method that allows for alternative downstream conditional
initialization of the Lazy constant.</div>
<div><br>
</div>
<div>
<div style="background-color:rgb(30,30,30);color:rgb(212,212,212)">
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt">
<span style="color:rgb(71,162,237)">private class </span><span style="color:rgb(71,204,177)">Bar</span>{
LazyCosntan<Weather> <span style="color:rgb(140,215,255)">weatherUrl </span>= LazyCosntant.of(this<span style="font-size:9.8pt">::</span><span style="font-size:9.8pt;color:rgb(230,230,170)">checkAndGetWeatherUrl</span>);</pre>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt">
<span style="color:rgb(71,162,237)">public </span><span style="color:rgb(230,230,170)">Bar</span>(){}
<span style="color:rgb(71,162,237)">private </span><span style="color:rgb(71,204,177)">String </span><span style="color:rgb(230,230,170)">checkAndGetWeatherUrl</span>(){
<span style="color:rgb(204,133,198)">return </span><span style="color:rgb(71,204,177)">Executors</span>.<span style="color:rgb(255,198,109);font-style:italic">newVirtualThreadPerTaskExecutor</span>()
.submit(() -> <span style="color:rgb(105,152,86)">/*Some query to check if the weather server is up*/</span>);
}
<span style="color:rgb(71,162,237)">private </span><span style="color:rgb(71,204,177)">String </span><span style="color:rgb(230,230,170)">checkAndGetAltWeatherUrl</span>(){
<span style="color:rgb(204,133,198)">return </span><span style="color:rgb(71,204,177)">Executors</span>.<span style="color:rgb(255,198,109);font-style:italic">newVirtualThreadPerTaskExecutor</span>()
.submit(() -> <span style="color:rgb(105,152,86)">/*Some query to check if the alt weather server is up*/</span>);
}
<span style="color:rgb(71,162,237)">public </span>Weather <span style="color:rgb(230,230,170)">getWeather</span>(){
var url = <span style="color:rgb(140,215,255)">weatherUrl</span>.computeIfAbsent(<span style="color:rgb(71,162,237)">this</span>::<span style="color:rgb(230,230,170)">checkAndGetAltWeatherUrl</span>).get();</pre>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt"> <span style="color:rgb(105,152,86)">// logic to get the weather here using the lazy constants//
</span><span style="color:rgb(105,152,86)"> </span>}</pre>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt"> public void <span style="font-size:9.8pt;color:rgb(230,230,170)">sendWeather</span><span style="font-size:9.8pt">(){</span>
</pre>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt"><span style="font-size:9.8pt"> </span>var url = <span style="font-size:9.8pt;color:rgb(140,215,255)">weatherUrl</span><span style="font-size:9.8pt">.computeIfAbsent(</span><span style="font-size:9.8pt;color:rgb(71,162,237)">this</span><span style="font-size:9.8pt">::</span><span style="font-size:9.8pt;color:rgb(230,230,170)">checkAndGetAltWeatherUrl</span><span style="font-size:9.8pt">).get();</span></pre>
<div>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt"> <span style="color:rgb(71,204,177)">Executors</span>.<span style="color:rgb(255,198,109);font-style:italic">newVirtualThreadPerTaskExecutor</span>()
.submit(() -> <span style="color:rgb(105,152,86)">/*Send the weather url to somewhere else* using weatherUrl*/</span>);
}</pre>
</div>
<pre style="font-family:"JetBrains Mono",monospace;font-size:9.8pt">
}</pre>
</div>
</div>
<div><br>
</div>
<div>This pattern is very common, either for a trivial weather
or to check or a conf and alternatives in case the regular one
is not available (for example a conf file that may be missing
and one may set a method that downloads it from a remote
server first in case it is absent)</div>
<div><br>
</div>
<div>So for me the issue is not the concept of "orElse" but how
the current implementation returns me an alternative value
instead of SETTING an alternative value in case the regular
attempt fails or hasn't been called still because the program
followed an alternative path before the obvious regular
initialization path. If the orElse (or any other name that
fits) changes the behaviour to set a value instead of
returning something it would be the best approach IMHO.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">El mar, 9 dic 2025 a la(s)
9:13 a.m., Anatoly Kupriyanov (<a href="mailto:kan.izh@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">kan.izh@gmail.com</a>)
escribió:<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>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">
<div dir="ltr" class="gmail_attr">On Tue, 9 Dec 2025 at
13:35, Red IO <<a href="mailto:redio.development@gmail.com" target="_blank" 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>
</div>
</blockquote>
</body>
</html>