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

[Luca Kellermann]

On Wed, 12 Mar 2025 08:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
>
> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

>> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.
>
> The `toString()` function for stable value is inspired by `Optional` and some of the collections.

`Optional` doesn't have the issue of containing itself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991649915
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989329168