JEP draft: Scope Locals

[David Lloyd]

On Wed, May 12, 2021 at 9:43 AM Andrew Haley <aph at redhat.com> wrote:

> There's been considerable discussion about scope locals on the loom-dev
> list,
> and it's now time to open this to a wider audience. This subject is
> important
> because. although scope locals were motivated by the the needs of Loom,
> they
> have many potential applications outside that project.
>

I didn't get a chance to mention earlier, but I think scope locals are
shaping up really great so far: simple yet powerful.  I know this will be a
really useful addition to the JDK.  There are several projects both within
and without Red Hat that I have authored or have contributed to which use a
very compatible pattern (that is, using a lexically constrained binding
strategy for context association) and are perfect candidates to switch over
to use this feature.

That said, I have one minor comment about the API. :-)

I think it would be really nice if the snapshot class could hold its
run/call method rather than making it a static method of `ScopeLocal`. This
reads more naturally to me (and is nicer to write):

    var snap = ScopeLocal.snapshot();
    return executor.submit(() -> snap.call(aCallable));

Than this:

    var snap = ScopeLocal.snapshot();
    return executor.submit(() -> ScopeLocal.callWithSnapshot(aCallable, snap
));

This kind of lexically bound contextual pattern can be found in several of
our existing projects (including those listed below [1] [2]).  In writing
these projects, we took it a step further than just Runnable and Callable
and added variants which accept `Consumer<T>` plus a `T` to pass in, a
`Function<T, R>` plus a `T` to pass in, and `BiConsumer` and `BiFunction`
variants as well which accept two arguments to pass in.  The practical
reason here is that we could then pass in a method handle with explicit
arguments rather than relying on lambda capture, which can be expensive in
certain circumstances.  The overall benefit vs cost of doing this is
probably debatable, but I thought the idea might be interesting at any rate.

Anyway that's it.  I love this feature and am excited to see it get into
the JDK!

[1] WildFly Elytron "Scoped" API, used by client and server authentication
contexts (WildFly's version of JAAS Subject):
https://github.com/wildfly-security/wildfly-elytron/blob/1.x/auth/server/base/src/main/java/org/wildfly/security/auth/server/Scoped.java
[2] WildFly Common "Contextual" API used for transaction, configuration,
and other context propagation:
https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/wildfly/common/context/Contextual.java

-- 
- DML • he/him