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

Masayoshi Okutsu masayoshi.okutsu at oracle.com
Wed Feb 12 16:07:44 PST 2014

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.

I also wonder if the Serbian locales with implicit Cyrl have the same 


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