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

Erik Joelsson erik.joelsson at oracle.com
Mon Feb 17 23:35:22 PST 2014

My understanding is that these changes are needed. From a build 
perspective, while making complicated make logic even more complicated, 
it's really not that bad imho. So OK from me.


On 2014-02-17 17:39, 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 i18n-dev mailing list