<div dir="auto"><div>The Thread Local example was more about a situation where wrapping a forked task would be useful. Another one I can think of is capturing the parent thread's name and logging the forked thread's name to make it slightly easier to track what threads are starting other threads.</div><div dir="auto"><br></div><div dir="auto">That being said I should have let myself wake up more this morning, the answer isn't adjusting the Structured Task Scope API, it's providing the bridge as some type of delegator. Then you get something like this</div><div dir="auto"><br></div><div dir="auto">var delegate = service.capture();</div><div dir="auto">// then somewhere in the structured task</div><div dir="auto">var subTaskA = scope.fork(delegate.wrapping(() -> {...}));</div><div dir="auto"><br></div><div dir="auto">This would let me bridge without breaking legacy code at the granularity I was thinking about, without overriding the ThreadFactory.</div><div dir="auto"><br></div><div dir="auto">I'll try playing around with that approach sometime this week/month and seeing what it feels like.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">-Peter</div><div dir="auto"><br><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Aug 18, 2025, 1:22 PM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/08/2025 16:53, Peter Eastham wrote:<br>
> Hello Loom Team,<br>
><br>
> While reading over the other thread concerning Joiners, I finally <br>
> loaded in the EA for Java 25 and took a look over the Java Doc. While <br>
> I'm liking what I'm seeing (and need to play around with it more), I'm <br>
> struggling to figure out how to bridge older approaches with this.<br>
><br>
> For example, let's say Library A heavily utilizes a ThreadLocal. <br>
> Because it's a library we can't migrate to a ScopedValue or <br>
> InheritableThreadLocal. Currently the best bridge I've found is to <br>
> provide a Configuration with a custom ThreadFactory. This is a little <br>
> heavy handed, as you're really only wanting to hydrate a ThreadLocal, <br>
> not manage the entire Thread.<br>
<br>
The ThreadLocal value may be mutable and/or otherwise unsafe to access <br>
from concurrent threads. ThreadLocals that are intended to be <br>
shared/inherited into other threads must be InheritableThreadLocals. <br>
InheritableThreadLocal has been mostly shunned by the eco system for a <br>
number of good reasons (performance being one). At the same <br>
time, InheritableThreadLocal does do what you want in a structured <br>
context, albeit with additional overhead when create threads for the <br>
subtasks, and possible side effects where the ITL is inherited further <br>
when subtasks happen to execute some code that creates a Thread.<br>
<br>
So your opening paragraph on integrating with existing code and <br>
libraries is important, I don't think it's feasible to be able to treat <br>
ThreadLocals as inheritable.<br>
<br>
-Alan<br>
</blockquote></div></div></div>