New candidate JEP: 506: Scoped Values

[Andrew Haley]

On 15/04/2025 17:17, Adam Gent wrote:
> I actually have problems with the API. I don't think its worth allowing null in a Scoped Value.
> 
> I covered this in a reddit commenthttps://www.reddit.com/r/java/comments/1jzd8df/scoped_values_final_in_jdk_25/mn8ofdc/
> 
> For those that do not want to go to reddit the gist is I think if we do not allow null in a Scoped Value it makes the API less bloated and easier to use with pattern matching. That is `get` just like a non null value map will return `null` you can do the following and not need the `orElse` or `orElseThrow` and the inevitable plethora of methods that are on `Optional`:
> 
> String username = switch(scopedValue.get()) {
>    case User u -> u.getUsername();
>    case null -> throw new SomeException("User Missing");
> }
> 
> I had posted earlier about now allowing null but did not get much feedback perhaps because I didn't have enough clarity on why I think it is a good idea not to allow null.

We've been around this several times.

A problem with allowing an unbound scoped value to return null is that
ScopedValue::get() now introduces nulls even where they don't appear
in the program. We will be able to fix nullable scoped values in the
future with non-nullable types, so ScopedValue<String!>,get() will never
return null.

I suppose we could make ScopedValue<String!>.get() return String?
instead of String!, so calls to get() always lose non-nullability,
but that doesn't strike me as a great idea either.

https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ScopedValue.html
doesn't strike me as a very verbose API.

Andrew.