<i18n dev> RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Naoto Sato 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()[1], 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
>> country?
> 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
> Locale.getDefault(Locale.FORMAT).
> 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 mailing list