ScopedValue.runWhere not returning scope

[Robert Engels]

But x == y does not require immutability, .e.g:

final ScopedValue aScopedValue = …

Recorder r = aScopedValue.get();

r.recordSomeValue();

final Recorder = aScopedValue.get();

r.close() -> e.g. writes values to server…

so the scoped value is not immutable, only the reference is constant.

This doesn’t match the JEP or I am misunderstanding it.

>  final ScopedValue aScopedValue = ...;
>  final var x = aScopedValue.get();
>  // Any Java code at all...
>  final var y = aScopedValue.get();



> On Jun 10, 2024, at 12:29 PM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> On 6/10/24 17:25, Robert Engels wrote:
>> I think the question is more - what are the threads doing with this
>> object between the open and close. This is what controls whether or not
>> the object can be immutable - which from my reading is the general
>> design/limitation of a scoped variable.
> 
> Exactly. So something (what?) returns a Scope object. But that can't change
> the current scoped value context.
> 
> Here's a fundamental property of a scoped value:
> 
>  The result of aScopedValue.get() does not ever change within the execution
>  context of a method. Sure, its value might get overridden in the context of a
>  callee, but when that callee returns the scoped value has its original
>  value.
> 
>  So, in this code
> 
>  final ScopedValue aScopedValue = ...;
>  final var x = aScopedValue.get();
>  // Any Java code at all...
>  final var y = aScopedValue.get();
> 
>  assert(x == y); // Always succeeds
> 
> That is to say, you can read a scoped value, put it in a local, and use
> that local, and it is a hard guarantee that will have exactly the same
> effect as repeatedly calling aScopedValue.get() .
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>