From naoto.sato at oracle.com Tue Feb 4 18:54:55 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 04 Feb 2014 18:54:55 -0800 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol Message-ID: <52F1A7FF.7010505@oracle.com> 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 From erik.joelsson at oracle.com Wed Feb 5 01:10:10 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 05 Feb 2014 10:10:10 +0100 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52F1A7FF.7010505@oracle.com> References: <52F1A7FF.7010505@oracle.com> Message-ID: <52F1FFF2.1040609@oracle.com> Hello Naoto, Looks fine from a build perspective. The logic of that makefile is quite hairy to begin with. /Erik On 2014-02-05 03:54, 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 From masayoshi.okutsu at oracle.com Mon Feb 10 00:23:37 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 10 Feb 2014 17:23:37 +0900 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52F1A7FF.7010505@oracle.com> References: <52F1A7FF.7010505@oracle.com> Message-ID: <52F88C89.9040201@oracle.com> 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 From magnus.ihse.bursie at oracle.com Mon Feb 10 01:24:22 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Feb 2014 10:24:22 +0100 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52F88C89.9040201@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> Message-ID: <52F89AC6.6020505@oracle.com> On 2014-02-10 09:23, 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. I think that would be good. Do you think it is possible? We are already doing too much scary things in the build wrt locales; I'd rather not add more. /Magnus > > 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 > From naoto.sato at oracle.com Mon Feb 10 09:00:38 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 10 Feb 2014 09:00:38 -0800 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52F88C89.9040201@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> Message-ID: <52F905B6.4000405@oracle.com> 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 > From masayoshi.okutsu at oracle.com Wed Feb 12 16:07:44 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 13 Feb 2014 09:07:44 +0900 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52F905B6.4000405@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> Message-ID: <52FC0CD0.2070604@oracle.com> 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 problem. 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 >> From naoto.sato at oracle.com Wed Feb 12 16:43:12 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 12 Feb 2014 16:43:12 -0800 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52FC0CD0.2070604@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> <52FC0CD0.2070604@oracle.com> Message-ID: <52FC1520.5030403@oracle.com> 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 >>> > From Alan.Bateman at oracle.com Mon Feb 17 06:40:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Feb 2014 14:40:52 +0000 Subject: RFR: JDK-8035067: Move jdk/src/share/classes/java/util/CurrencyData.properties to jdk/make/data In-Reply-To: <53021E8B.6050309@oracle.com> References: <53021E8B.6050309@oracle.com> Message-ID: <53021F74.8010505@oracle.com> On 17/02/2014 14:36, Erik Joelsson wrote: > Hello, > > I found another data file that belongs in make/data. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035067 > Webrev: http://cr.openjdk.java.net/~erikj/8035067/webrev.jdk.01/ This looks okay to me. Also cc'ing i18n-dev as this is where the currency data and API is maintained. -Alan. From naoto.sato at oracle.com Mon Feb 17 08:39:49 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 17 Feb 2014 08:39:49 -0800 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <52FC1520.5030403@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> <52FC0CD0.2070604@oracle.com> <52FC1520.5030403@oracle.com> Message-ID: <53023B55.9070709@oracle.com> 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 >>>> >> > From naoto.sato at oracle.com Mon Feb 17 09:38:56 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 17 Feb 2014 09:38:56 -0800 Subject: RFR: JDK-8035067: Move jdk/src/share/classes/java/util/CurrencyData.properties to jdk/make/data In-Reply-To: <53021F74.8010505@oracle.com> References: <53021E8B.6050309@oracle.com> <53021F74.8010505@oracle.com> Message-ID: <53024930.1070604@oracle.com> +1 Naoto On 2/17/2014 6:40 AM, Alan Bateman wrote: > On 17/02/2014 14:36, Erik Joelsson wrote: >> Hello, >> >> I found another data file that belongs in make/data. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8035067 >> Webrev: http://cr.openjdk.java.net/~erikj/8035067/webrev.jdk.01/ > This looks okay to me. Also cc'ing i18n-dev as this is where the > currency data and API is maintained. > > -Alan. From erik.joelsson at oracle.com Mon Feb 17 23:35:22 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Feb 2014 08:35:22 +0100 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <53023B55.9070709@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> <52FC0CD0.2070604@oracle.com> <52FC1520.5030403@oracle.com> <53023B55.9070709@oracle.com> Message-ID: <53030D3A.2000509@oracle.com> 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 >>>>> >>> >> From masayoshi.okutsu at oracle.com Tue Feb 18 07:26:31 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 19 Feb 2014 00:26:31 +0900 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <53023B55.9070709@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> <52FC0CD0.2070604@oracle.com> <52FC1520.5030403@oracle.com> <53023B55.9070709@oracle.com> Message-ID: <53037BA7.6040505@oracle.com> 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. Masayoshi 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 >>>>> >>> >> From naoto.sato at oracle.com Tue Feb 18 09:16:57 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 18 Feb 2014 09:16:57 -0800 Subject: [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol In-Reply-To: <53037BA7.6040505@oracle.com> References: <52F1A7FF.7010505@oracle.com> <52F88C89.9040201@oracle.com> <52F905B6.4000405@oracle.com> <52FC0CD0.2070604@oracle.com> <52FC1520.5030403@oracle.com> <53023B55.9070709@oracle.com> <53037BA7.6040505@oracle.com> Message-ID: <53039589.90605@oracle.com> On 2/18/14, 7:26 AM, Masayoshi Okutsu wrote: > What I meant is that zh-hans-cn and zh-cn should be treated as > equivalents. I think we can assume this only for the providers we own as we know it, but not for other providers. That's the whole reason Hans/Hant scripts were introduced. > 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. Hmm, that sounds a bit overkill to me. Anyway, it definitely sounds like an enhancement that may be addressed with 8027313, but my intention is to fix this particular bug, which apparently is not working as expected as of now. Naoto > > Masayoshi > > 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 >>>>>> >>>> >>> > From yong.huang at oracle.com Sun Feb 23 22:13:45 2014 From: yong.huang at oracle.com (Yong Huang) Date: Mon, 24 Feb 2014 14:13:45 +0800 Subject: [9] Review Request - JDK-8017142: Time display for Spanish(Chile, Ecuador ) locale doesn't show 24-hour format Message-ID: <530AE319.2070908@oracle.com> Hello, This is the review request for https://bugs.openjdk.java.net/browse/JDK-8017142. Webrev: http://cr.openjdk.java.net/~yhuang/8017142/webrev.00/ thanks, Yong From masayoshi.okutsu at oracle.com Sun Feb 23 23:50:08 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 24 Feb 2014 16:50:08 +0900 Subject: [9] Review Request - JDK-8017142: Time display for Spanish(Chile, Ecuador ) locale doesn't show 24-hour format In-Reply-To: <530AE319.2070908@oracle.com> References: <530AE319.2070908@oracle.com> Message-ID: <530AF9B0.7050609@oracle.com> Looks good to me. Masayoshi On 2/24/2014 3:13 PM, Yong Huang wrote: > Hello, > > This is the review request for > https://bugs.openjdk.java.net/browse/JDK-8017142. > > Webrev: http://cr.openjdk.java.net/~yhuang/8017142/webrev.00/ > > thanks, > Yong