<i18n dev> RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly
Roger Riggs
rriggs at openjdk.java.net
Fri Mar 4 20:04:02 UTC 2022
On Fri, 4 Mar 2022 19:50:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:
>> 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.
As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7703
More information about the i18n-dev
mailing list