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

[Erik Joelsson]

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.

/Erik

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