JDK-8027289 : [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2013-10-25
  • Updated: 2019-08-12
  • Resolved: 2014-02-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b04Fixed
Related Reports
Relates :  
JDK-8027313 - Use locale matcher methods for designating the best locale service provider
Relates :  
JDK-8010666 - Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter
Description
On pure windows zh_CN or windows MUI fully switched to zh_CN (for non-Unicode program: S. Chinses), run attached program:

java -Djava.locale.providers=JRE,HOST NumberFormatTest zh CN

The output is saved in file output.txt with UTF-8 encoding. The expected result is ���7,000.00, where currency symbol is \uffe5 from JRE adapter, but the actual result is ��7,000.00, where the currency symbol is \u00a5 from the host. The currency symbol from Host is returned even it's JRE,HOST in the providers list.

If java.locale.providers is not specified, or HOST is not in the list, the expected result, \uffe5 will be returned.

This problem does not happen in b80, but it happens in b90.
Comments
Verified in Jdk 9 b04.
17-03-2014
Revised the fix to include locales that explicitly claims Hans/Hant in JRE's provider, instead of removing them from HOST provider.
04-02-2014
Revised proposed fix.
06-12-2013
Stack trace where host adapter is responding "true" for zh-Hans-CN.
06-12-2013
Proposed fix: diff -r cd60848c87b2 src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java --- a/src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java +++ b/src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java @@ -39,6 +39,7 @@ import java.util.Collections; import java.util.Currency; import java.util.HashSet; +import java.util.Iterator; import java.util.Locale; import java.util.Map; import java.util.ResourceBundle.Control; @@ -123,6 +124,20 @@ l = Locale.forLanguageTag(formatLocale.replace('_', '-')); tmpSet.addAll(c.getCandidateLocales("", l)); } + + // for "zh" locales, remove Hans/Hant locales + Iterator<Locale> iter = tmpSet.iterator(); + while (iter.hasNext()) { + l = iter.next(); + if (l.getLanguage() == "zh" && + (l.getScript() == "Hans" && l.getCountry() == "CN" || + l.getScript() == "Hant" && + (l.getCountry() == "HK" || + l.getCountry() == "MO" || + l.getCountry() == "TW"))) { + iter.remove(); + } + } } else { nativeDisplayLanguage = ""; }
31-10-2013
Regression caused by JDK-8010666, introduced in b89 (for some reason, I cannot choose "b89" in the "Introduced in Build" field)
25-10-2013
The reason is that the Host Locale Provider claims to support zh-Hans-CN, because the default candidate lookup for zh_CN includes it. Also the logic to search for the zh_CN provider use that candidate list. But the JRE's supported locales list is static and does not include zh-Hans-CN, so Host adapter is used in this case.
25-10-2013