From masayoshi.okutsu at oracle.com Mon Sep 2 02:34:08 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 02 Sep 2013 18:34:08 +0900 Subject: java.util.Locale changes In-Reply-To: <522222A9.5080805@gmail.com> References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com> <521DFA57.2060502@oracle.com> <521E6098.9080801@oracle.com> <521F0526.7020904@oracle.com> <522222A9.5080805@gmail.com> Message-ID: <52245B90.7080106@oracle.com> In general, Set doesn't fit for the priority list purpose. For example, if the priority list of languages is { "fr", "de", "en" }, an Iterator from a Set must iterate the languages (ranges) in the order of the priority list, "fr", "de", and "en". It's likely that you will need to implement a special Set. Masayoshi On 2013/09/01 2:06, Christian Beikov wrote: > Well it at least adds the possibility to use a Set directly as source. > As stated before, this is just a remark because I thought one could > also want to use a different Collection than a List. Using the > Collection interface would also be enough. > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 29.08.2013 10:24, schrieb Masayoshi Okutsu: >> I took a look at the implementation. The matcher code just iterates >> the given priority list. isEmpty() is used, but it shouldn't be a >> problem. As far as an Iterable gives an Iterator which consistently >> iterates elements based on the priority or weight, the Iterable works. >> >> Use of Iterable does give more flexibility, but I'm not sure how much >> it would add value to the API use. You can implement your own >> Iterable, but would many developers implement an Iterable to give a >> language priority list? >> >> Masayoshi >> >> On 2013/08/29 5:42, Alan Bateman wrote: >>> On 28/08/2013 14:25, Masayoshi Okutsu wrote: >>>> (adding core-libs-dev) >>>> >>>> Hi Christian, >>>> >>>> RFC 4647 defines The Language Priority List [1]. The use of >>>> java.util.List would be a natural fit, which is the reason why List >>>> is used. But use of Iterable does work (as API design). The >>>> parameter name `priorityIterable' sounds a bit odd, though. >>>> >>>> Does use of Iterable add much value to the API? (Please note that >>>> List is also used in Locale.LanguageRange.) >>>> >>> It depends on the usages but Iterable would be a bit more flexible. >>> Does the locale matcher require to do anything except iterate over >>> the elements? The return could be looked at it but it depends on the >>> typical usage -- would the user of the API typically just iterate >>> over the matched Locales? >>> >>> -Alan. >> > From sean.coffey at oracle.com Mon Sep 2 08:47:11 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 16:47:11 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext Message-ID: <5224B2FF.7090904@oracle.com> Performance regression reported where a high number of threads calling TimeZone.getDefault can run into a bottleneck on AppContext accessor calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. Turns out that we're unnecessarily going through the AppContext in certain scenarios. Main aim is to use AppContext when using applets. We should check for presence of security manager (along with loading for AppContext class) in such cases. http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ This fix is not applicable to jdk8 as new code is currently being worked on there which eliminates AppContext use. Regards, Sean. From sean.coffey at oracle.com Mon Sep 2 11:06:49 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 19:06:49 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224B2FF.7090904@oracle.com> References: <5224B2FF.7090904@oracle.com> Message-ID: <5224D3B9.1050905@oracle.com> This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ regards, Sean. On 02/09/13 16:47, Se?n Coffey wrote: > Performance regression reported where a high number of threads calling > TimeZone.getDefault can run into a bottleneck on AppContext accessor > calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. > > Turns out that we're unnecessarily going through the AppContext in > certain scenarios. Main aim is to use AppContext when using applets. > We should check for presence of security manager (along with loading > for AppContext class) in such cases. > > http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ > > This fix is not applicable to jdk8 as new code is currently being > worked on there which eliminates AppContext use. > > Regards, > Sean. From chris.hegarty at oracle.com Mon Sep 2 11:15:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Sep 2013 19:15:16 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D3B9.1050905@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> Message-ID: <5224D5B4.7060900@oracle.com> On 09/02/2013 07:06 PM, Se?n Coffey wrote: > This might be a slightly easier one to read. (fast path logic code first) > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ The 'javaAWTAccess != null ' checks are redundant. It will always be the case, right? -Chris. > > regards, > Sean. > > > On 02/09/13 16:47, Se?n Coffey wrote: >> Performance regression reported where a high number of threads calling >> TimeZone.getDefault can run into a bottleneck on AppContext accessor >> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >> >> Turns out that we're unnecessarily going through the AppContext in >> certain scenarios. Main aim is to use AppContext when using applets. >> We should check for presence of security manager (along with loading >> for AppContext class) in such cases. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >> >> This fix is not applicable to jdk8 as new code is currently being >> worked on there which eliminates AppContext use. >> >> Regards, >> Sean. > From sean.coffey at oracle.com Mon Sep 2 11:31:14 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 19:31:14 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D5B4.7060900@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> Message-ID: <5224D972.4070003@oracle.com> On 02/09/13 19:15, Chris Hegarty wrote: > On 09/02/2013 07:06 PM, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > > The 'javaAWTAccess != null ' checks are redundant. It will always be > the case, right? if (System.getSecurityManager() == null || javaAWTAccess == null) { I'm covering for the case here where we may have a security manager but it's not the plugin one (which would have triggered loading of javaAWTAccess) - I'll double check. regards, Sean. > > -Chris. > >> >> regards, >> Sean. >> >> >> On 02/09/13 16:47, Se?n Coffey wrote: >>> Performance regression reported where a high number of threads calling >>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>> >>> Turns out that we're unnecessarily going through the AppContext in >>> certain scenarios. Main aim is to use AppContext when using applets. >>> We should check for presence of security manager (along with loading >>> for AppContext class) in such cases. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>> >>> This fix is not applicable to jdk8 as new code is currently being >>> worked on there which eliminates AppContext use. >>> >>> Regards, >>> Sean. >> From christian.beikov at gmail.com Mon Sep 2 12:02:36 2013 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Sep 2013 21:02:36 +0200 Subject: java.util.Locale changes In-Reply-To: <52245B90.7080106@oracle.com> References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com> <521DFA57.2060502@oracle.com> <521E6098.9080801@oracle.com> <521F0526.7020904@oracle.com> <522222A9.5080805@gmail.com> <52245B90.7080106@oracle.com> Message-ID: One could use a LinkedHashSet instead of List to avoid duplicates but still have an ordered sequence. In general, Set doesn't fit for the priority list purpose. For example, if the priority list of languages is { "fr", "de", "en" }, an Iterator from a Set must iterate the languages (ranges) in the order of the priority list, "fr", "de", and "en". It's likely that you will need to implement a special Set. Masayoshi On 2013/09/01 2:06, Christian Beikov wrote: > Well it at least adds the possibility to use a Set directly as source. As > stated before, this is just a remark because I thought one could also want > to use a different Collection than a List. Using the Collection interface > would also be enough. > > Mit freundlichen Gr??en, > ------------------------------**------------------------------** > ------------ > *Christian Beikov* > Am 29.08.2013 10:24, schrieb Masayoshi Okutsu: > >> I took a look at the implementation. The matcher code just iterates the >> given priority list. isEmpty() is used, but it shouldn't be a problem. As >> far as an Iterable gives an Iterator which consistently iterates elements >> based on the priority or weight, the Iterable works. >> >> Use of Iterable does give more flexibility, but I'm not sure how much it >> would add value to the API use. You can implement your own Iterable, but >> would many developers implement an Iterable to give a language priority >> list? >> >> Masayoshi >> >> On 2013/08/29 5:42, Alan Bateman wrote: >> >>> On 28/08/2013 14:25, Masayoshi Okutsu wrote: >>> >>>> (adding core-libs-dev) >>>> >>>> Hi Christian, >>>> >>>> RFC 4647 defines The Language Priority List [1]. The use of >>>> java.util.List would be a natural fit, which is the reason why List is >>>> used. But use of Iterable does work (as API design). The parameter name >>>> `priorityIterable' sounds a bit odd, though. >>>> >>>> Does use of Iterable add much value to the API? (Please note that List >>>> is also used in Locale.LanguageRange.) >>>> >>>> It depends on the usages but Iterable would be a bit more flexible. >>> Does the locale matcher require to do anything except iterate over the >>> elements? The return could be looked at it but it depends on the typical >>> usage -- would the user of the API typically just iterate over the matched >>> Locales? >>> >>> -Alan. >>> >> >> > From sean.coffey at oracle.com Mon Sep 2 12:07:42 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 20:07:42 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D5B4.7060900@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> Message-ID: <5224E1FE.5010805@oracle.com> Chris - you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. regards, Sean. On 02/09/13 19:15, Chris Hegarty wrote: > On 09/02/2013 07:06 PM, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > > The 'javaAWTAccess != null ' checks are redundant. It will always be > the case, right? > > -Chris. > >> >> regards, >> Sean. >> >> >> On 02/09/13 16:47, Se?n Coffey wrote: >>> Performance regression reported where a high number of threads calling >>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>> >>> Turns out that we're unnecessarily going through the AppContext in >>> certain scenarios. Main aim is to use AppContext when using applets. >>> We should check for presence of security manager (along with loading >>> for AppContext class) in such cases. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>> >>> This fix is not applicable to jdk8 as new code is currently being >>> worked on there which eliminates AppContext use. >>> >>> Regards, >>> Sean. >> From chris.hegarty at oracle.com Mon Sep 2 12:35:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 Sep 2013 20:35:03 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224E1FE.5010805@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> <5224E1FE.5010805@oracle.com> Message-ID: On 2 Sep 2013, at 20:07, Se?n Coffey wrote: > Chris - > > you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. Otherwise looks fine to me. -Chris. > > regards, > Sean. > > On 02/09/13 19:15, Chris Hegarty wrote: >> On 09/02/2013 07:06 PM, Se?n Coffey wrote: >>> This might be a slightly easier one to read. (fast path logic code first) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ >> >> The 'javaAWTAccess != null ' checks are redundant. It will always be the case, right? >> >> -Chris. >> >>> >>> regards, >>> Sean. >>> >>> >>> On 02/09/13 16:47, Se?n Coffey wrote: >>>> Performance regression reported where a high number of threads calling >>>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>>> >>>> Turns out that we're unnecessarily going through the AppContext in >>>> certain scenarios. Main aim is to use AppContext when using applets. >>>> We should check for presence of security manager (along with loading >>>> for AppContext class) in such cases. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>>> >>>> This fix is not applicable to jdk8 as new code is currently being >>>> worked on there which eliminates AppContext use. >>>> >>>> Regards, >>>> Sean. > From Alan.Bateman at oracle.com Mon Sep 2 13:07:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 21:07:12 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D3B9.1050905@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> Message-ID: <5224EFF0.4030405@oracle.com> On 02/09/2013 19:06, Se?n Coffey wrote: > This might be a slightly easier one to read. (fast path logic code first) > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ This is nicer (and I see Chris has already pointed out the redundant check). -Alan From sean.coffey at oracle.com Mon Sep 2 14:58:36 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 22:58:36 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224EFF0.4030405@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> Message-ID: <52250A0C.7000409@oracle.com> Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ regards, Sean. On 02/09/13 21:07, Alan Bateman wrote: > On 02/09/2013 19:06, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > This is nicer (and I see Chris has already pointed out the redundant > check). > > -Alan From chris.hegarty at oracle.com Tue Sep 3 00:25:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Sep 2013 08:25:22 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <52250A0C.7000409@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> <52250A0C.7000409@oracle.com> Message-ID: <7E7C8F10-16F9-4DB6-9473-0AFB35A769AE@oracle.com> On 2 Sep 2013, at 22:58, Se?n Coffey wrote: > Some minor modification (and further simplifying of conditions) : > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ Looks good to me. -Chris. > > regards, > Sean. > > On 02/09/13 21:07, Alan Bateman wrote: >> On 02/09/2013 19:06, Se?n Coffey wrote: >>> This might be a slightly easier one to read. (fast path logic code first) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ >> This is nicer (and I see Chris has already pointed out the redundant check). >> >> -Alan > From Alan.Bateman at oracle.com Tue Sep 3 01:15:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 09:15:38 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <52250A0C.7000409@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> <52250A0C.7000409@oracle.com> Message-ID: <52259AAA.5030807@oracle.com> On 02/09/2013 22:58, Se?n Coffey wrote: > Some minor modification (and further simplifying of conditions) : > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ This looks much better. -Alan. From naoto.sato at oracle.com Wed Sep 4 09:26:27 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 04 Sep 2013 09:26:27 -0700 Subject: [8]Request for Review: 8023943 : Method description fix for String.toLower/UpperCase() methods Message-ID: <52275F33.5050906@oracle.com> Hello, Please review this very simple doc fix: http://cr.openjdk.java.net/~naoto/8023943/webrev.00/ for the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023943 This is just a document correctness fix to replace Locale.ENGLISH with Locale.ROOT for String.toLower/Upper() methods. Naoto From masayoshi.okutsu at oracle.com Wed Sep 4 15:58:24 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 05 Sep 2013 07:58:24 +0900 Subject: [8]Request for Review: 8023943 : Method description fix for String.toLower/UpperCase() methods In-Reply-To: <52275F33.5050906@oracle.com> References: <52275F33.5050906@oracle.com> Message-ID: <5227BB10.8060709@oracle.com> Looks good to me. Masayoshi On 9/5/2013 1:26 AM, Naoto Sato wrote: > Hello, > > Please review this very simple doc fix: > > http://cr.openjdk.java.net/~naoto/8023943/webrev.00/ > > for the following bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023943 > > This is just a document correctness fix to replace Locale.ENGLISH with > Locale.ROOT for String.toLower/Upper() methods. > > Naoto From masayoshi.okutsu at oracle.com Thu Sep 5 23:05:04 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 06 Sep 2013 15:05:04 +0900 Subject: [8] RFR: 8024141: Unexpected timezone display name Message-ID: <52297090.5050305@oracle.com> Hi, Please review the following fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024141 The fix is to cache time zone name arrays in different sizes separately. The cache support and/or time zone name resources structure may need to be revisited for more efficient management. Maybe for the next release. Webrev: http://cr.openjdk.java.net/~okutsu/8/8024141/webrev.00/ Thanks, Masayoshi From yuka.kamiya at oracle.com Thu Sep 5 23:38:05 2013 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Fri, 06 Sep 2013 15:38:05 +0900 Subject: [8] RFR: 8024141: Unexpected timezone display name In-Reply-To: <52297090.5050305@oracle.com> References: <52297090.5050305@oracle.com> Message-ID: <5229784D.8080201@oracle.com> Hi, The fix looks good to me. Thanks, -- Yuka (2013/09/06 15:05), Masayoshi Okutsu wrote: > Hi, > > Please review the following fix: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024141 > > The fix is to cache time zone name arrays in different sizes separately. The cache support and/or time zone name resources structure may need to be revisited for more efficient management. Maybe for the next release. > > Webrev: > http://cr.openjdk.java.net/~okutsu/8/8024141/webrev.00/ > > Thanks, > Masayoshi > From naoto.sato at oracle.com Fri Sep 6 12:01:37 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 06 Sep 2013 12:01:37 -0700 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar Message-ID: <522A2691.6010908@oracle.com> Hello, Please review the fix for the following bug. At the moment, it's not yet reflected in the bug database, but the symptom is that sun.util.resources.en package is split between rt.jar and localedata.jar, which would make it problematic in Jigsaw environment http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 The following proposed fix is to move all "en" locales back to rt.jar. http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ Naoto From david.holmes at oracle.com Sun Sep 8 19:47:06 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Sep 2013 12:47:06 +1000 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522A2691.6010908@oracle.com> References: <522A2691.6010908@oracle.com> Message-ID: <522D36AA.9020304@oracle.com> Hi Naoto, On 7/09/2013 5:01 AM, Naoto Sato wrote: > Hello, > > Please review the fix for the following bug. At the moment, it's not yet > reflected in the bug database, but the symptom is that > sun.util.resources.en package is split between rt.jar and > localedata.jar, which would make it problematic in Jigsaw environment Can you clarify what the before and after conditions are here. I'm trying to determine if this has any impact on the compact profiles definitions, and also how it might impact locale-based testing for JRE's that do not have localedata.jar. Thanks, David > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 > > The following proposed fix is to move all "en" locales back to rt.jar. > > http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ > > Naoto From naoto.sato at oracle.com Mon Sep 9 14:17:54 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 09 Sep 2013 14:17:54 -0700 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522D36AA.9020304@oracle.com> References: <522A2691.6010908@oracle.com> <522D36AA.9020304@oracle.com> Message-ID: <522E3B02.4080100@oracle.com> Hi David, With this change, rt.jar would contain all the supported English locales in java.text and java.util packages (cf. http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html#util-text), whereas US English is the only supported locale at the moment w/o localedata.jar. As to the testing, if those compact profiles keep claiming to support only en_US, there should not be any testing impact even for locale-based testing. Naoto On 9/8/13 7:47 PM, David Holmes wrote: > Hi Naoto, > > On 7/09/2013 5:01 AM, Naoto Sato wrote: >> Hello, >> >> Please review the fix for the following bug. At the moment, it's not yet >> reflected in the bug database, but the symptom is that >> sun.util.resources.en package is split between rt.jar and >> localedata.jar, which would make it problematic in Jigsaw environment > > Can you clarify what the before and after conditions are here. I'm > trying to determine if this has any impact on the compact profiles > definitions, and also how it might impact locale-based testing for JRE's > that do not have localedata.jar. > > Thanks, > David > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 >> >> The following proposed fix is to move all "en" locales back to rt.jar. >> >> http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ >> >> Naoto From david.holmes at oracle.com Mon Sep 9 18:31:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Sep 2013 11:31:15 +1000 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522E3B02.4080100@oracle.com> References: <522A2691.6010908@oracle.com> <522D36AA.9020304@oracle.com> <522E3B02.4080100@oracle.com> Message-ID: <522E7663.4030203@oracle.com> On 10/09/2013 7:17 AM, Naoto Sato wrote: > Hi David, > > With this change, rt.jar would contain all the supported English locales > in java.text and java.util packages (cf. > http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html#util-text), > whereas US English is the only supported locale at the moment w/o > localedata.jar. Got it - thanks. No impact to the compact profiles. > As to the testing, if those compact profiles keep claiming to support > only en_US, there should not be any testing impact even for locale-based > testing. Some environments don't contain the optional localedata.jar so tests that require it need to be identified. This change might alter the list of tests. But that isn't your concern. Thanks, David > Naoto > > On 9/8/13 7:47 PM, David Holmes wrote: >> Hi Naoto, >> >> On 7/09/2013 5:01 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix for the following bug. At the moment, it's not yet >>> reflected in the bug database, but the symptom is that >>> sun.util.resources.en package is split between rt.jar and >>> localedata.jar, which would make it problematic in Jigsaw environment >> >> Can you clarify what the before and after conditions are here. I'm >> trying to determine if this has any impact on the compact profiles >> definitions, and also how it might impact locale-based testing for JRE's >> that do not have localedata.jar. >> >> Thanks, >> David >> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 >>> >>> The following proposed fix is to move all "en" locales back to rt.jar. >>> >>> http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ >>> >>> Naoto > From Alan.Bateman at oracle.com Tue Sep 10 08:44:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Sep 2013 16:44:57 +0100 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522A2691.6010908@oracle.com> References: <522A2691.6010908@oracle.com> Message-ID: <522F3E79.8050000@oracle.com> On 06/09/2013 20:01, Naoto Sato wrote: > Hello, > > Please review the fix for the following bug. At the moment, it's not > yet reflected in the bug database, but the symptom is that > sun.util.resources.en package is split between rt.jar and > localedata.jar, which would make it problematic in Jigsaw environment > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 > > The following proposed fix is to move all "en" locales back to rt.jar. > > http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ > > Naoto Thanks for doing this, it would otherwise be problematic to have packages split between the boot and extensions loader. I've looked through the changes (except the old build) and I don't see anything obviously wrong. The only question I have is on the footprint, meaning the number of classes that move from localedata.jar to rt.jar. Do you happen to know the size approximately? -Alan From naoto.sato at oracle.com Tue Sep 10 09:46:39 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 10 Sep 2013 09:46:39 -0700 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522F3E79.8050000@oracle.com> References: <522A2691.6010908@oracle.com> <522F3E79.8050000@oracle.com> Message-ID: <522F4CEF.1070003@oracle.com> Hi Alan, On 09/10/2013 08:44 AM, Alan Bateman wrote: > I've looked through the changes (except the old build) and I don't see > anything obviously wrong. The only question I have is on the footprint, > meaning the number of classes that move from localedata.jar to rt.jar. > Do you happen to know the size approximately? Here are the classes moved back from localedata.jar to rt.jar with this change: sun/text/resources/en/FormatData_en_AU.class sun/text/resources/en/FormatData_en_CA.class sun/text/resources/en/FormatData_en_GB.class sun/text/resources/en/FormatData_en_IE.class sun/text/resources/en/FormatData_en_IN.class sun/text/resources/en/FormatData_en_MT.class sun/text/resources/en/FormatData_en_NZ.class sun/text/resources/en/FormatData_en_PH.class sun/text/resources/en/FormatData_en_SG.class sun/text/resources/en/FormatData_en_ZA.class sun/util/resources/en/CalendarData_en_GB.class sun/util/resources/en/CalendarData_en_IE.class sun/util/resources/en/CalendarData_en_MT.class sun/util/resources/en/CurrencyNames_en_AU.class sun/util/resources/en/CurrencyNames_en_CA.class sun/util/resources/en/CurrencyNames_en_GB.class sun/util/resources/en/CurrencyNames_en_IE.class sun/util/resources/en/CurrencyNames_en_IN.class sun/util/resources/en/CurrencyNames_en_MT.class sun/util/resources/en/CurrencyNames_en_NZ.class sun/util/resources/en/CurrencyNames_en_PH.class sun/util/resources/en/CurrencyNames_en_SG.class sun/util/resources/en/CurrencyNames_en_ZA.class sun/util/resources/en/LocaleNames_en_MT.class sun/util/resources/en/LocaleNames_en_PH.class sun/util/resources/en/LocaleNames_en_SG.class sun/util/resources/en/TimeZoneNames_en_CA.class sun/util/resources/en/TimeZoneNames_en_GB.class sun/util/resources/en/TimeZoneNames_en_IE.class The approximate size increase of rt.jar would be around 30K bytes. Naoto From erik.joelsson at oracle.com Wed Sep 11 04:56:16 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Sep 2013 13:56:16 +0200 Subject: [8]RFR: 8024332: sun/util/resources/en split between rt.jar and localedata.jar In-Reply-To: <522A2691.6010908@oracle.com> References: <522A2691.6010908@oracle.com> Message-ID: <52305A60.2020504@oracle.com> I think the build changes look OK. /Erik On 2013-09-06 21:01, Naoto Sato wrote: > Hello, > > Please review the fix for the following bug. At the moment, it's not > yet reflected in the bug database, but the symptom is that > sun.util.resources.en package is split between rt.jar and > localedata.jar, which would make it problematic in Jigsaw environment > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024332 > > The following proposed fix is to move all "en" locales back to rt.jar. > > http://cr.openjdk.java.net/~naoto/8024332/webrev.00/ > > Naoto From michael.fang at oracle.com Sun Sep 22 21:40:39 2013 From: michael.fang at oracle.com (Michael Fang) Date: Sun, 22 Sep 2013 21:40:39 -0700 Subject: [8]Request for review: 8025215: jdk8 l10n resource file translation update 4 In-Reply-To: <51BFF32B.9030200@oracle.com> References: <51BFF32B.9030200@oracle.com> Message-ID: <523FC647.10806@oracle.com> Hello, Please help to review the changes for the following CR: https://bugs.openjdk.java.net/browse/JDK-8025215 A list of English resource files are sent to translation group for translation update periodically that's why these l10n resource files have been updated. You do not need to review the translation content at this time. We just need to make sure they do not break the build (which has been ensured with full test builds). Follow up i18n/l10n testing will be performed in promotion builds and i18n/l10n bugs will be reported and addressed. The webrev is available here: http://cr.openjdk.java.net/~mfang/8025215/ thanks, -michael From masayoshi.okutsu at oracle.com Thu Sep 26 02:33:32 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 26 Sep 2013 18:33:32 +0900 Subject: [8]RFR: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Message-ID: <5243FF6C.3030406@oracle.com> Hi, Please view the fix (workaround) for the following bug. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6902861 Added a workaround that Calendar.roll tries to stay in the same calendar year even when WEEK_OF_YEAR and YEAR are "out of sync". The real fix should be to add a new method, like rollWeeksInWeekYear(int amount), which handles rolling weeks within a week-based year rather than a calendar year. http://cr.openjdk.java.net/~okutsu/8/6902861/webrev.00/ Thanks, Masayoshi From xsoh.k7 at gmail.com Fri Sep 20 07:25:23 2013 From: xsoh.k7 at gmail.com (Suhail Alkowaileet) Date: Fri, 20 Sep 2013 14:25:23 -0000 Subject: Support Hijri calendar Message-ID: <523C5AD1.5040507@gmail.com> I would like to support the lunar Hijri calendar(see: https://en.wikipedia.org/wiki/Hijri ) to the jdk and I'm just asking should I do something before doing this? My plan is to clone the jdk8/l10n/jdk and add the appropriate files to of the Hijri and push them back. I'm going to use the Umm al-Qura calendar as the way of calculating(see: https://en.wikipedia.org/wiki/Hijri#Saudi_Arabia.27s_Umm_al-Qura_calendar ).