ScopeValue for Locale, Clock, ZoneId ... and others

[Roger Riggs]

Hi Omar,

Global variables have long been the domain of bugs and increase the 
maintenance cost of software creating undocumented or under-documented 
dependencies on external contexts.

Scoped variables are essentially global variables and are useful in 
specific contexts and with the explicit specification and documentation 
of their effects on APIs and behavior.

It could be interesting to look at some specific use cases and explore 
the scope and impact on usability and compatibility.

Regards, Roger

On 12/30/25 2:20 PM, Omar Aloraini wrote:
> Many objects fit into the contextual data that needs to be passed 
> between caller/callee whether they are part of the application code or 
> between application and library. The current state is that frameworks 
> such Spring define many "holder" classes which give access to the 
> underlying object stored in a ThreadLocal (e.g. LocaleContextHolder). 
> But could this be part of the JDK itself?
>
> I wish to write the following code:
>
> ```
> Locale locale = Locale.VALUE.get()
> ...
>
> I also wish to avoid propagating the value every time:
> ```
> getTranslation("key", locale)
> ```
>
> If every framework has a different scopedvalue we are no better than 
> where we started.
>
> Should every class define an instance of its ScopedValue as a field? 
> or should we have a generic holder keyed by the Class object itself? 
> Or should it be part of the ScopedValue API itself?
>
> ```
> ScopedValue.get(Locale.class)
> ScopedValue.where(Locale.class, Locale.ENGLISH)
> ```
>
> needless to say, for the highest payoff, this needs to be part of 
> java.base.