On Wed, 12 Mar 2025 08:16:50 GMT, Per Minborg <pminb...@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
