<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Maurizio,<div><br></div><div>It’s great to see Stable Values getting ready to start previewing, it’s a very useful piece of work.</div><div>But I have doubts about some of the descriptions in the "Alternatives" section.</div><div><br></div><div>In this section, the Class-holder idiom is described as "this makes applications slower to start up".</div><div>But I don't find this convincing because all the previous examples are using lambda, </div><div>and I believe that for the use case that is only called once, it has a larger startup overhead than the holder class.</div><div><br></div><div>I've looked at the source code, so I know that StableValue has methods like StableValue::trySet and StableValue::setOrThrow, </div><div>but I haven't seen them in the JEP draft. If they still exist today, can they be included in the description of the JEP?</div><div style="">For use cases where startup time is critical, they should have lower overhead than StableValue::orElseSet.</div><div><br></div><div>Glavo</div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2025 at 2:17 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">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">Hi all,<br>
Per and I have been busy polishing the Computed Constant API. So much so <br>
that it has now changed name to Stable Value API :-)<br>
<br>
<a href="https://openjdk.org/jeps/502" rel="noreferrer" target="_blank">https://openjdk.org/jeps/502</a><br>
<br>
The goal is still to provide a safe API around JVM's @Stable value <br>
annotation. But, as we experimented with the old API, we realized that <br>
its "lambda-oriented" design, while good, was too restrictive when <br>
clients wanted to "set" the computed constant in a more imperative fashion.<br>
<br>
In the new Stable Value API, stable values are created unset. They can <br>
be set imperatively, or more functionally using a method similar to <br>
Map::computeIfAbsent. If you squint, the old computed constants have not <br>
disappeared: a computed constant can be expressed as a supplier that <br>
wraps a stable value -- we call such a supplier a "stable supplier".<br>
<br>
Per's talk at Devoxx 2024 is a good companion to the new JEP, with lots <br>
of interesting live examples:<br>
<br>
<a href="https://www.youtube.com/watch?v=3fXHrK3yV9w" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=3fXHrK3yV9w</a><br>
<br>
Let us know what you think!<br>
<br>
Cheers<br>
Maurizio<br>
<br>
<br>
<br>
</blockquote></div>