RFR: 8351565: Implement JEP 502: Stable Values (Preview)

Fri Apr 4 10:32:34 UTC 2025

In general I don't disagree.

There is, however, at least _some_ cases where the imperative API is 
less difficult to use.

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.

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.

At some point later in the class lifetime, it becomes "frozen", and it 
is published to multiple threads.

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.

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.

(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)

Maurizio

On 03/04/2025 12:20, Per-Ake Minborg wrote:
> Hi Remi and thank you for the feedback from JChateau (what a wonderful 
> name!).
>
> 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.
>
> Best, Per
> ------------------------------------------------------------------------
> *From:* Remi Forax <forax at univ-mlv.fr>
> *Sent:* Wednesday, April 2, 2025 4:33 PM
> *To:* Per Minborg <pminborg at openjdk.org>
> *Cc:* compiler-dev <compiler-dev at openjdk.org>; core-libs-dev 
> <core-libs-dev at openjdk.org>; hotspot-dev <hotspot-dev at openjdk.org>; 
> security-dev <security-dev at openjdk.org>
> *Subject:* Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
> Hi Per,
> 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.
>
> To present the API, i start from the double check locking, rewriting 
> it to use the StableValue API.
>
> The main remark was that methods like orElseSet() or isSet() are hard 
> to used correctly.
>
> 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.
>
>
> high level:
> - methods supplier(), list() and map()
>   Those are easy to use
>
> low level:
> - methods: of, of(value), orElseSet, setOrThrow(), etc
>   Those are hard to use properly.
>
> 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).
>
> regards,
> Rémi
>
> ----- Original Message -----
> > From: "Per Minborg" <pminborg at openjdk.org>
> > To: "compiler-dev" <compiler-dev at openjdk.org>, "core-libs-dev" 
> <core-libs-dev at openjdk.org>, "hotspot-dev"
> > <hotspot-dev at openjdk.org>, "security-dev" <security-dev at openjdk.org>
> > Sent: Thursday, March 13, 2025 12:20:10 PM
> > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
>
> > Implement JEP 502.
> >
> > The PR passes tier1-tier3 tests.
> >
> > -------------
> >
> > Commit messages:
> > - Use acquire semantics for reading rather than volatile semantics
> > - Add missing null check
> > - Simplify handling of sentinel, wrap, and unwrap
> > - Fix JavaDoc issues
> > - Fix members in StableEnumFunction
> > - Address some comments in the PR
> > - Merge branch 'master' into implement-jep502
> > - Revert change
> > - Fix copyright issues
> > - Update JEP number
> > - ... and 231 more: 
> https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6
> >
> > Changes: https://git.openjdk.org/jdk/pull/23972/files
> >  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 
> <https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00>
> >  Issue: https://bugs.openjdk.org/browse/JDK-8351565
> >  Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
> >  Patch: https://git.openjdk.org/jdk/pull/23972.diff
> >  Fetch: git fetch https://git.openjdk.org/jdk.git 
> pull/23972/head:pull/23972
> >
> > PR: https://git.openjdk.org/jdk/pull/23972
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250404/2a13e5cc/attachment.htm>