<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>In general I don't disagree.</p>
<p><br>
</p>
<p>There is, however, at least _some_ cases where the imperative API
is less difficult to use.</p>
<p><br>
</p>
<p>In some cases you know that a class has a complex lifecycle --
perhaps it starts off in a simple "larval" state, where the
instance only exist in a single thread.</p>
<p><br>
</p>
<p>In this state, it's possible for the class to receive state
updates. If parts of the class state are stable, using `trySet`
might work very well. Perhaps only "friends" of this class can
call such mutator methods on the larval instance.<br>
</p>
<p><br>
At some point later in the class lifetime, it becomes "frozen",
and it is published to multiple threads.</p>
<p><br>
</p>
<p>Of course, this is a corner case -- but if our goal is to model
what `@Stable` can do, while surely a stable supplier, or using
`orElseSet` are better no-worry alternatives to get there, there
remain a number of use cases that would not be expressible if all
we had was the high-level API. In a way, a big part of what this
new API does is that it finds the right set of primitives, upon
which we can build all the other interesting high-level stuff.</p>
<p><br>
</p>
<p>I think your complaint is not that the primitive is wrong, but
that in calling the primitive StableValue we're giving the "good
name" to the stuff that is less likely to be widely used.</p>
<p><br>
</p>
<p>(Note: a very minimalistic API approach -- which we considered --
would have been to just provide extra stable factories in
Supplier/Function/IntFunction/List/Map and call it a day)</p>
<p><br>
</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 03/04/2025 12:20, Per-Ake Minborg
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR10MB428367CDBB3E227ED628F2E6DAAE2@DM6PR10MB4283.namprd10.prod.outlook.com">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; color: rgb(0, 0, 0);">
<span style="font-size: 12pt;">Hi Remi and thank you for the
feedback from </span>
<span style="font-size: 11pt;">JChateau</span><span style="font-size: 12pt;"> (what a wonderful name!). <br>
<br>
This is one of the issues we already have on the list for the
next round of preview. Now we know more folks are on the same
page.</span></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best, Per</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Remi
Forax <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
<b>Sent:</b> Wednesday, April 2, 2025 4:33 PM<br>
<b>To:</b> Per Minborg <a class="moz-txt-link-rfc2396E" href="mailto:pminborg@openjdk.org"><pminborg@openjdk.org></a><br>
<b>Cc:</b> compiler-dev <a class="moz-txt-link-rfc2396E" href="mailto:compiler-dev@openjdk.org"><compiler-dev@openjdk.org></a>;
core-libs-dev <a class="moz-txt-link-rfc2396E" href="mailto:core-libs-dev@openjdk.org"><core-libs-dev@openjdk.org></a>; hotspot-dev
<a class="moz-txt-link-rfc2396E" href="mailto:hotspot-dev@openjdk.org"><hotspot-dev@openjdk.org></a>; security-dev
<a class="moz-txt-link-rfc2396E" href="mailto:security-dev@openjdk.org"><security-dev@openjdk.org></a><br>
<b>Subject:</b> Re: RFR: 8351565: Implement JEP 502: Stable
Values (Preview)</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi Per,<br>
last week, at JChateau, we had a one hour session about
stable values, I've build the JDK with this PR so we can
discuss about it.<br>
<br>
To present the API, i start from the double check locking,
rewriting it to use the StableValue API.<br>
<br>
The main remark was that methods like orElseSet() or
isSet() are hard to used correctly.<br>
<br>
In my opinion, the current API is a mix of a high level
API and a low-level API but it's too easy to misuse the
low-level API.<br>
<br>
<br>
high level:<br>
- methods supplier(), list() and map()<br>
Those are easy to use<br>
<br>
low level:<br>
- methods: of, of(value), orElseSet, setOrThrow(), etc<br>
Those are hard to use properly.<br>
<br>
I think, not necessary in this PR, that the current API
should be separated into two different classes, one in
java.lang with the high level API (the static methods
other than Of() and one in java.util.concurrent with the
low level API where you have to know what you are doing
(like with any classes of java.util.concurrent).<br>
<br>
regards,<br>
Rémi<br>
<br>
----- Original Message -----<br>
> From: "Per Minborg" <a class="moz-txt-link-rfc2396E" href="mailto:pminborg@openjdk.org"><pminborg@openjdk.org></a><br>
> To: "compiler-dev" <a class="moz-txt-link-rfc2396E" href="mailto:compiler-dev@openjdk.org"><compiler-dev@openjdk.org></a>,
"core-libs-dev" <a class="moz-txt-link-rfc2396E" href="mailto:core-libs-dev@openjdk.org"><core-libs-dev@openjdk.org></a>,
"hotspot-dev"<br>
> <a class="moz-txt-link-rfc2396E" href="mailto:hotspot-dev@openjdk.org"><hotspot-dev@openjdk.org></a>, "security-dev"
<a class="moz-txt-link-rfc2396E" href="mailto:security-dev@openjdk.org"><security-dev@openjdk.org></a><br>
> Sent: Thursday, March 13, 2025 12:20:10 PM<br>
> Subject: RFR: 8351565: Implement JEP 502: Stable
Values (Preview)<br>
<br>
> Implement JEP 502.<br>
> <br>
> The PR passes tier1-tier3 tests.<br>
> <br>
> -------------<br>
> <br>
> Commit messages:<br>
> - Use acquire semantics for reading rather than
volatile semantics<br>
> - Add missing null check<br>
> - Simplify handling of sentinel, wrap, and unwrap<br>
> - Fix JavaDoc issues<br>
> - Fix members in StableEnumFunction<br>
> - Address some comments in the PR<br>
> - Merge branch 'master' into implement-jep502<br>
> - Revert change<br>
> - Fix copyright issues<br>
> - Update JEP number<br>
> - ... and 231 more: <a href="https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6" moz-do-not-send="true" class="moz-txt-link-freetext">
https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6</a><br>
> <br>
> Changes: <a href="https://git.openjdk.org/jdk/pull/23972/files" moz-do-not-send="true" class="moz-txt-link-freetext">https://git.openjdk.org/jdk/pull/23972/files</a><br>
> Webrev: <a href="https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00" moz-do-not-send="true">https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00</a><br>
> Issue: <a href="https://bugs.openjdk.org/browse/JDK-8351565" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8351565</a><br>
> Stats: 3980 lines in 30 files changed: 3949 ins; 18
del; 13 mod<br>
> Patch: <a href="https://git.openjdk.org/jdk/pull/23972.diff" moz-do-not-send="true" class="moz-txt-link-freetext">https://git.openjdk.org/jdk/pull/23972.diff</a><br>
> Fetch: git fetch <a href="https://git.openjdk.org/jdk.git" moz-do-not-send="true" class="moz-txt-link-freetext">https://git.openjdk.org/jdk.git</a>
pull/23972/head:pull/23972<br>
> <br>
> PR: <a href="https://git.openjdk.org/jdk/pull/23972" moz-do-not-send="true" class="moz-txt-link-freetext">https://git.openjdk.org/jdk/pull/23972</a><br>
</div>
</span></font></div>
</blockquote>
</body>
</html>