<i18n dev> [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol

Naoto Sato naoto.sato at oracle.com
Mon Feb 17 08:39:49 PST 2014

Any other comments? If there is no strong opinion against pushing this 
change, I just want to push it to the repo.


On 2/12/14, 4:43 PM, Naoto Sato wrote:
> On 2/12/14, 4:07 PM, Masayoshi Okutsu wrote:
>> The problem in the bug report is that the currency symbol is taken from
>> the HOST locale provider where it is expected to come from the JRE
>> locale provider. Hans/Hant of zh locales of JRE locales are all
>> implicit. So I don't think zh locales with explicit Script have to be
>> listed as available locales.
> First of all, this is specific to Chinese locales. Once the host adapter
> knows that the underlying Windows' default locale is Simplified Chinese,
> it creates the supported locales list with
> ResourceBundle.Control.getCandidateLocales() method. This method has a
> special behavior for Chinese to include Hans/Hant locales as special
> cases. This is the reason that those implicit Hans/Hant are included in
> the supported locales list.
> So my first attempt was as you mentioned, just remove those explicit
> Hans/Hant locales from the supported list, but it turned out that this
> issue is not limited only to the host adapter, but other SPI based
> implementations can also cause this problem. So, I switched the fix to
> include Hans/Hant into JRE's supported locales list.
>> I also wonder if the Serbian locales with implicit Cyrl have the same
>> problem.
> No. It does not happen with Serbian with the said reason above.
> Naoto
>> Thanks,
>> Masayoshi
>> On 2/11/2014 2:00 AM, Naoto Sato wrote:
>>> I thought about it and probably it would make sense to utilize locale
>>> matching mechanism in LocaleProviderAdapter, where it selects the most
>>> preferred adapter. However, on the JRE's adapter side, it still needs
>>> to declare that Hans/Hant locales in the supported locales list. This
>>> fix is to address this latter part.
>>> Naoto
>>> On 2/10/14, 12:23 AM, Masayoshi Okutsu wrote:
>>>> I wonder if we can utilize the locale matching mechanism rather than
>>>> tweaking the makefile. zh-CN and zh-Hans-CN can be treated as
>>>> equivalents for looking up the JRE locales.
>>>> Masayoshi
>>>> On 2/5/2014 11:54 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>> Please review this fix:
>>>>> http://cr.openjdk.java.net/~naoto/8027289/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8027289
>>>>> The fix is to add Chinese locales with explicit scripts (Hans/Hant) in
>>>>> JRE's locale provider adapter's supported locales if corresponding
>>>>> implicit Chinese locales are supported.
>>>>> For build-dev engineers, I post this to your alias because the fix is
>>>>> in a make file.
>>>>> Naoto

More information about the i18n-dev mailing list