New candidate JEP: 506: Scoped Values

[Ron Pressler]

We gave this matter serious consideration (and even made some changes to the API as a result), reviewed all arguments on both sides of the question, and in the end we didn’t find the case against allowing null less convincing overall than the case for allowing it (especially since users will be able to choose a type argument that allows or disallows null values as they please, and potential extensions of pattern matching make the pattern-matching argument less compelling).

Even if this matter were still open, bringing up the very same arguments that were in front of us when we considered the matter would not lead to a different outcome.

— Ron


> On 15 Apr 2025, at 17:59, Adam Gent <dev at adamgent.com> wrote:
> 
> It is not really a hill I'm willing to die on but in theory you need to call `isBound` every time you call `get` in the same vain that you need to call `optional.isPresent` before blindly calling `optional.get`.
> 
> Consequently the Java ecosystem has tools such as Checkerframework and Intellij that will correctly provide warnings or failure if you blindly call `Optional.get` before `isPresent`. This is of course ditto for accessing `null` and that has even more widespread usage. Now ScopedValue will need this checking where is if it returned null or even Optional it could reuse existing static analysis.
> 
>> 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.
> 
> If Valhalla seems close enough maybe instead the `get` can just return an `Optional` which in theory with Valhalla will have less  wrapping cost and you get aforementioned helper methods for free including lazy orElse.
> 
> It is just in modern Java `null` being put in a container has been greatly avoided and I think this makes things simpler, easier and safer which If I recall was a goal of ScopedValue?
> 
> On Tue, Apr 15, 2025, at 12:47 PM, Andrew Haley wrote:
>> 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.