ScopedValue: Capturing current bindings

[Robert Engels]

I think what a previous poster referred to was that a forked task had no ability to retain a scoped variable (eg hold a reference in a static).

Although this has direct applicability in solving issues with a reusable buffer - it requires assistance from something like Rusts borrow checker so that a reference cannot be retained and only the contents copied - a signal to the developer that this is an expensive operation so do you really want to do this?

Although helpful it complicates things immensely and doesn’t feel like Java. 



> On Jun 2, 2023, at 4:41 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> On 6/1/23 17:38, Attila Kelemen wrote:
>> The method `withCapturedContext` captures the current scoped value
>> bindings, then immediately calls its argument (task) with an instance of
>> `CapturedScopedValueContex` which will run tasks with the captured scope
>> value bindings (when calling its `inContext` method). However,
>> `CapturedScopedValueContext.inContext` validates if the captured scope
>> value bindings is the same as the current one, or the parent of the current
>> scoped value bindings, and if it is not, then fails with an ISE.
> 
> Thanks, that's clear enough.
> 
> OK, so it's possible for application code called from a framework to
> override the caller's context, as long as that context was a parent
> of the current context. That seems like a significant weakening of
> the guarantees that scoped values provide.
> 
> -- 
> 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
>