Locale strings should be fairly simple, there's nice ISO standards covering this stuff. Yet despite all their good work in the last few years, the Java team has managed to confuse matters and make life awkward when it comes to something basic like this.

And they've done it in multiple releases! (at least between Java 7 and Java 10 anyway, I need to check this again with 11. I'm pretending Java 1.6 and earlier didn't exist for now)

scribble notes so far

en_GB format codes. Or ... en-GB. Both valid according to ISO standard.

Java has Locale class. Can construct based on a code. Can get a code String back from a Locale Object.

Importantly, the String you contruct with does not look like the String you get back from the constructed Locale object.

String englishEnglish = "en_GB";
Locale englishLoc = new Locale(englishEnglish);

if (englishLoc.toString().equals(englishEnglish)) {
// the world is a sane place
} else {
// what Java does
}

Yup, take a valid string representation of a locale, build a locale object from it, convert that object back into a string representation, you don't get back your original string.

Now you may be saying "ahh, that's because there are two valid ISO string representations of a locale, one uses underscores, the other uses dashes". Which is true. Except, Java only accepts the underscore version in a Locale constructor and only gives back the dashes version in a Locale.toString().

Which is just plain unhelpful.

Open up jshell (honest thanks for that one Java team!) and we can more easily see the same nonsense in Java 9 and 10.

|  Welcome to JShell -- Version 10
|  For an introduction type: /help intro

jshell> Locale.UK.toString();
$1 ==> "en_GB"

jshell> new Locale(Locale.UK.toString()).toString();
$2 ==> "en_gb"

To quote Gary Bernhardt - "WAT?!"

Previous Post Next Post