Locale API is broken in a few ways that should be avoided, with some
examples of error prone issues below:
The constructors don’t validate the parameters at all, they just “trust” it 100%.
Locale locale = new Locale("en_AU"); toString() : "en_au" getLanguage() : "en_au" locale.getCountry : "" locale = new Locale("somethingBad#!34, too long, and clearly not a locale ID"); toString() : "somethingbad#!34, too long, and clearly not a locale id" getLanguage() : "somethingbad#!34, too long, and clearly not a locale id" getCountry() : ""
As you can see, the full string is interpreted as language, and the country is empty.
new Locale("zh", "tw", "#Hant") you get:
toString() : zh_TW_#Hant getLanguage() : zh getCountry() : TW getScript() : getVariant() : #Hant
Locale.forLanguageTag("zh-hant-tw") you get a different result:
toString() : zh_TW_#Hant getLanguage() : zh getCountry() : TW getScript() : Hant getVariant() :
We can see that while the
toString() value for both locales are equivalent,
the individual parts are different. More specifically, the first locale is
#Hant is supposed to be the script for the locale rather than
There’s no reliable way of getting a correct result through a
constructor, so we should prefer using
Locale.forLanguageTag() (and the IETF
BCP 47 format) for correctness.
Note: You might see a
.replace("_", "-") appended to a suggested fix for
the error prone checker for this bug pattern. This is sanitization measure to
handle the fact that
Locale.forLanguageTag() accepts the “minus form” of a tag
en-US) but not the “underscore form” (
en_US). It will silently default to
Locale.ROOT if the latter form is passed in.
This poses the inverse of the constructor problem
Locale myLocale = Locale.forLanguageTag("zh-hant-tw") String myLocaleStr = myLocale.toString() // zh_TW_#Hant Locale derivedLocale = ??? // Not clean way to get a correct locale from this string
toString() implementation for
Locale isn’t necessarily incorrect in
It is intended to be “concise but informative representation that is easy for a person to read” (see documentation at Object.toString()).
So it is not intended to produce a value that can be turned back into a
Locale. It is not a serialization format.
It often produces a value that looks like a locale identifier, but it is not.
Suppress false positives by adding the suppression annotation
@SuppressWarnings("UnsafeLocaleUsage") to the enclosing element.