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.
