from Hacker News

JEP 506: Scoped Values final for Java 25

by ludovicianul on 4/15/25, 11:17 AM with 9 comments

• by Pet_Ant on 4/15/25, 9:03 PM

  So it sort of looks like a DSL for a variant of ThreadLocal that gives you an idea of the lifeline of variable instead of just being global. Apparently with virtual threads they are expecting an increase in the number of running (virtual) threads several orders of magnitude larger than what was previously seen and that with ThreadLocals would just be too much.

  So the have added this:

  > ScopedVaule.where(CONTEXT, context).run(() -> Application.handle(request, response));

  Which stores the object referenced by `context` to the ScopedValue container `CONTEXT` ^ for the duration of the thread running `Application.handle(request,response)`.

  Not really sexy, but I understand how you might really benefit if you are processing lots of data, but for most enterprise CRUD apps this seems inapplicable.

  ^ I think this a "monad"? I'm not a functional programmer.

• by bhawks on 4/16/25, 6:18 AM

  Implicit parameter smuggling by any mechanism is just too much magic in my experience. Golang's context.Context solves the same problem, but explicitly in a way that has been widely adopted through their language ecosystem.

  That said - in Java I do think it would be near impossible for the ecosystem to adopt a similar mechanic, so from a practical standpoint this may be the only way to reliably propagate context.

• by djenndhxhd on 4/15/25, 4:14 PM

  Tramp parameters are a common occurrence, if not avoided with care.

  I see value in this proposal

• by skerit on 4/15/25, 3:21 PM

  Interesting proposal, I can see myself using this.