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

[Naoto Sato]

On Fri, 4 Mar 2022 19:33:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 2016:
>> 
>>> 2014:     static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) {
>>> 2015:         DecimalFormatSymbols dfs = DFS;
>>> 2016:         if (dfs != null && dfs.getLocale() == locale) {
>> 
>> `Locale` should be compared using `equals()`.
>
> I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision.

I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO.

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

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