<i18n dev> RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3]

[Jim Laskey]

On Mon, 7 Mar 2022 00:33:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it?
>> 
>> A bit more closer look at the code and it appears to me that the use of :
>> 
>> DecimalFormatSymbols dfs = DFS;
>> 
>> and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a:
>> 
>> dfs = DecimalFormatSymbols.getInstance(locale);
>> 
>> on first access (when `DFS` is null) but that in itself should be harmless.
>> 
>> If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail?
>
> Initially, I thought of the same thing (not the `Formatter` but `DecimalFormatSymbols` itself, as it is also not thread safe), but I concluded it was OK, as there is no mutation going on. I agree with Jaikiran that some comments might help here.

Noted

-------------

PR: https://git.openjdk.java.net/jdk/pull/7703