ScopedValue polyfill follow-up [try-with-resources]

[Ron Pressler]

Hi.

If method call `f()` returns an `AutoCloseable` whose `close` method doesn’t block, allocate, or perform any other operation that may fail, it may seem as if the following pattern — of “just doing it right” — should always work:

    try (var x = f()) { … }

Unfortunately, that is not the case because the very call to `close` may immediately fail with a StackOverflowError. In some cases of try/finally, the JDK makes special accommodations for such a situation, while in others it’s deemed acceptable, as a VirtualMachineError may leave the thread in some inconsistent state anyway. However, the case of ScopedValue is especially sensitive and needs to behave appropriately even in the face of a VME. This is a general problem that we may address in the future.

P.S.

As you may imagine, it is rare for us to have not considered various ideas, especially when they seem reasonable. If we don’t do something that seems reasonable, either there’s a problem with it, or we’ve decided to postpone it for later (possibly because it may interact with some future planned feature). It is better to frame feedback in the form of “I’ve tried to feature and run into the following problem…” At the very least it helps us see what problems people actually run into as opposed to what problems people speculate that they or others may run into.


— Ron

> On 31 Mar 2025, at 18:59, Chapman Flack <chap at anastigmatix.net> wrote:
> 
> Hi,
> 
> On 02/09/25 06:58, hrgdavor at gmail.com (Davor Hrg) wrote:
>> OT Context can be used as autocloseable in try with resources.
>> ScopedValue is from what I can see meant to be wrapped in Runnable or
>> Callable.
>> 
>> My concern may be misguided, but I do want to ask if there is any overhead
>> to worry about with creating a lambda to create a scope,
>> 
>> runWhere(CTX, value,()->{
>>    //do something
>> });
>> 
>> versus try with resources
>> 
>> try (Scope ignored = Context.current().with(CTX.KEY, value).makeCurrent()) {
>>    //do something
>> }
> 
> 
> I would like to add my voice in favor of also offering a try-with-resources
> friendly method. My concern is not with overhead, but simply with enabling
> more flexibility in API design around the new feature.
> 
> I am very pleased with the addition of the CallableOp functional interface
> in the third preview. Unless I messed up my quick search in jshell just now,
> even in Java 24, CallableOp still seems to be the very first, solitary,
> only, public, unqualified-exported, functional interface with a generic
> thrown exception type in the whole transitive closure of java.se.
> 
> That means even if there were nothing else good about scoped values,
> just having CallableOp land as a standard functional interface in Java
> immediately makes cleaner designs possible when designing APIs for other
> things. (Maybe it could even be introduced in a less obscure place,
> right in java.util.function, perhaps?)
> 
> While it's easy enough to roll my own such interface and I've done so
> for countless internal uses, I've always been reluctant to expose it in
> an API that I design, because then I'd just be contributing to a
> proliferation of APIs expecting differently-named equivalent functional
> interfaces while waiting for Java to provide a standard one, and consigning
> anyone who needs make two or more such APIs interoperate to the drudgery
> of converting one lambda to another via method reference.
> 
> I note in passing that there is still an opportunity for Java to provide
> a subinterface of AutoCloseable with a generic thrown exception type.
> My search in Java 24 this morning turned up exactly zero of those. Again,
> I've rolled those too for my own use but never wanted to clutter an API
> with a one-off version.
> 
> When scoped values land, CallableOp will not be only convenient for code
> directly manipulating scoped values. It will also allow API design where
> library A can pass a CallableOp to library B to be executed in a certain
> mode of B's operation, which B may well implement using a scoped value
> under the hood but that's none of A's business.
> 
> The trouble is, in polyfilling such a design before non-preview scoped
> values land, there isn't yet any available standard functional interface
> that can stand in for CallableOp. A polyfill would have to roll its own
> and there would be disruption in switching later.
> 
> And that is why I would like to suggest offering the choice of two modes
> of operation for scoped values:
> 
> ScopedValue.where(V, foo).call(() -> {
>  ... do ...
>  ... some ...
>  ... work ...
>  return thing;
> });
> 
> or
> 
> try (var _ = ScopedValue.where(V, foo).makeCurrent() ) {
>  ... do ...
>  ... some ...
>  ... work ...
>  result = thing;
> }
> 
> The two are roughly equivalent in convenience and expressiveness, and
> could easily both be offered. (I've used Davor Hrg's name makeCurrent
> above, but others might work ... inScope() ?)
> 
> But while it is trivial to implement an API that works the first way
> on top of one that works the second way, it's impossible to do the reverse.
> 
> If there is now some library B whose API for "be in such-and-such mode
> for this bit of work I have to do" already has the first pattern, and
> that library now wants to migrate to using ScopedValue under the hood,
> it easily can. Even if B's API exposes some differently-named functional
> interface to the caller, it can easily cast a method reference to
> CallableOp under the hood and no client code disruption results.
> 
> On the other hand, if there is a library whose API for "be in such-and-such
> mode for this bit of work" already has the second pattern, and now that
> library wants to migrate to using ScopedValue under the hood ... IT CAN'T.
> 
> 
> And in the present state of affairs, I would suspect that more existing
> libraries use that second pattern than the first, because of the long-
> standing lack of a standard functional interface like CallableOp.
> 
> 
> Some discussion I've seen online elsewhere suggested there might have
> been a concern about supporting a try-with-resources pattern because
> nothing actually forces the programmer to call the method in a try-
> with-resources, and that could make it 'unsafe'.
> 
> But it seems to me that 'safety' divides into at least three categories:
> 
> 1. Safe - this construct can't be used in any way that would let
>   Bad Things happen. The call(CallableOp) pattern fits here.
> 
> 2. Unsafe - this construct's very existence could allow Bad Things
>   to get you even if you use it right. Nothing proposed fits here.
> 
> 3. So just do it right. Yeah, Bad Things could happen if you don't.
>   But you're the one writing the code, you know what a try-with-resources
>   looks like, and you're happy when your code works, so you'll do it right.
> 
> Case 3 to me seems benign enough that I wouldn't use it as a reason
> to make one whole pattern of API design unimplementable over scoped values.
> 
> I was not able to find a lot of earlier discussion in the list archives
> (I've only looked back a year). I did see a point made that a ScopedValue
> .get() can now be assured to produce the same value anywhere in a method,
> where a try-with-resources option would allow it to have a different
> value within a try block. That may perhaps complicate optimization, but
> maybe not insurmountably? In the archived discussion I saw, there was
> some talk of allowing arbitrary in()/out() of the scope, but I do not
> propose that. All I suggest is returning an AutoCloseable subtype with
> one close() method that closes it once and for all.
> 
> There may also be a simplifying consideration. In the example I outlined
> above where a library B uses scoped values under the hood, and may wrap
> a ScopedValue AutoCloseable in some AutoCloseable of its own that it
> returns to its caller A for use in a try-with-resources, then yes,
> different bytecode ranges in that A method may correspond to different
> scoped values for B. But chances are A has no access to B's scoped values
> anyway. And in any method of B called within that try block in A,
> B's scoped values will be unchanging.
> 
> Thanks for considering my suggestion, and I hope it has contributed
> something constructive to the discussion.
> 
> Regards,
> Chapman Flack