Hi Brent,
On 6/13/16 1:58 PM, Brent Christian wrote:
Apple suggested changing the JDK initialization order so any access to
JRS happens only after the JLI_MemAlloc symbol is available. We believe
a better solution is to re-implement the JSR APIs in question, as a move
toward eventually dropping reliance on JSR altogether. The three main
changes are:
1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using
"CFLocaleCopyPreferredLanguages", which gives us the preferred language
as set in "System Preferences"->"Language & Text"->"Language" in the
form of "xx" (ie. just the language code - ex. "en", "fr", etc.). The
original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
this appears to be unnecessary. Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country, per this comment:
* If the locale name (without .encoding@variant, if any) matches
* any of the names in the locale_aliases list, map it to the
* corresponding full locale name. Most of the entries in the
* locale_aliases list are locales that include a language name but
* no country name, and this facility is used to map each language
* to a default country if that's possible.
I tried out a few locales, for English (en_US, en_GB), German (de_DE,
de_CH) and French (fr_FR, fr_CA). Language/country system properties
behave the same before and after this change, as does the
java.util.Locale test attached to the bug.
So does this mean the new code will not honor the "Region" in the OSX's
system preference? For example, what happens if the user sets "UK" for
the "Region" in the preference, then the new code return "US" for the
country?
Also, the array index "2" to assume the language length is 2 is not
correct, as there are three letter language codes. So the code should
literally look for "-" instead.
Naoto
