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 <fo...@univ-mlv.fr>
*Sent:* Wednesday, April 2, 2025 4:33 PM
*To:* Per Minborg <pminb...@openjdk.org>
*Cc:* compiler-dev <compiler-...@openjdk.org>; core-libs-dev
<core-libs-dev@openjdk.org>; hotspot-dev <hotspot-...@openjdk.org>;
security-dev <security-...@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" <pminb...@openjdk.org>
> To: "compiler-dev" <compiler-...@openjdk.org>, "core-libs-dev"
<core-libs-dev@openjdk.org>, "hotspot-dev"
> <hotspot-...@openjdk.org>, "security-dev" <security-...@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
