<i18n dev> RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]
naoto.sato at oracle.com
Tue Jun 14 00:14:05 UTC 2016
On 13/06/2016 16:20, Brent Christian wrote:
> Hi, Naoto. Thank you for having a look.
> On 13/06/2016 14:43, Naoto Sato wrote:
>> On 6/13/16 1:58 PM, Brent Christian wrote:
>>> 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(), mapLookup() is called to map
>>> the language to a default country, per this comment:
>>> * If the locale name (without .encoding at 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
> The new code has the same behavior as the existing code.
> OS X's Region preference is reflected as the locale's "format", through
> the "user.country.format" system property, and
> The region is not reflected in the base "user.country" property or
> Locale.getDefault(). As the existing source comment indicates, the
> country is mapped to the default for the language, in this case, "US".
> It seemed a bit strange to me, too, but my testing indicates this has
> been the behavior since jdk 7u4.
I think that is a bug. It should adopt "UK" for the default/display
locale too. Probably this should be addressed in a separate bug.
More information about the i18n-dev