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

Brent Christian brent.christian at oracle.com
Mon Jun 13 23:20:23 UTC 2016


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.

> 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.

Great, thanks.  I will fix that.

-Brent


More information about the i18n-dev mailing list