ScopeLocals: the next generation

[Andrew Haley]

We've been working on both the specification and the implementation of
ScopeLocals.

The new version is simplified in some ways: for example, the
"innovative" approach to inheritance has gone, to be replaced with a
simpler mechanism that supports only inheritance in a structured
concurrency context.

Partly in response to feedback from developers, we have added a new
form of ScopeLocal.bind() which uses try-with-resources rather than a
Lambda call. Its use looks like this:

public class BinderExample {
     ScopeLocal<Integer> SL1 = ScopeLocal.newInstance();

     public Object TWR_bind_ScopeLocal() throws Exception {
         try (var unused1 = ScopeLocal.where(SL1, 42).bind()) {
             // .. code that (eventually) uses SL1
         }
     }
}


Of course it's up to you whether or not you use ScopeLocal bind() in a
try-with-resources construct: there's nothing we can do to enforce
that. However, if you try to close ScopeLocal bindings out of order,
an exception will be thrown.

Also, there is an additional restriction: try-with-resources
ScopeLocals can only be bound once in a dynamic scope, and if any
attempt is made to re-bind a ScopeLocal in an inner nested scope an
exception will be thrown. Because of the additional checking for
correct usage we have to do, the try-with-resources version of bind()
is slower than the Lambda form, but it's there for the cases where
developers will find it useful.

Please have a look if you're interested, and please let us have any
feedback. Thanks,

-- 
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