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

Masayoshi Okutsu masayoshi.okutsu at oracle.com
Tue Feb 18 15:26:31 UTC 2014

What I meant is that zh-hans-cn and zh-cn should be treated as 
equivalents. I thought it would be possible to utilize the locale 
matching mechanism to do it, but I realize the locale matching of BCP47 
doesn't work that way. One solution would be to add another method for 
matching tag lookup which does NOT follow the BCP47 spec. But probably 
it's too expensive. LocaleServiceProvider.isSupportedLocale could be 
changed to do it.


On 2/18/2014 1:39 AM, Naoto Sato wrote:
> Any other comments? If there is no strong opinion against pushing this 
> change, I just want to push it to the repo.
> Naoto
> 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 build-dev mailing list