From yong.huang at oracle.com Mon Sep 1 06:03:18 2014 From: yong.huang at oracle.com (Yong Huang) Date: Mon, 01 Sep 2014 14:03:18 +0800 Subject: [9] Review Request - JDK-8055222: ISO 4217 Amendment #159 In-Reply-To: <5400F51A.7000907@oracle.com> References: <54003027.1080405@oracle.com> <5400F51A.7000907@oracle.com> Message-ID: <54040C26.3080806@oracle.com> Hi Naoto, Yea, I also need to change the locale name. Thank you for pointing it out. Besides country name, there is also the change in currency name "Cape Verde Escudo" -> "Cabo Verde Escudo". CurrencyNames.properties is generated based on CLDR and the currency name in it is "Cape Verdean escudo", same as what in latest CLDR. So I will leave CurrencyNames.properties unchanged, and only modify LocaleNames.properties. thanks, Yong On 2014/8/30 5:48, Naoto Sato wrote: > Hi Yong, > > The amendment also mentions to the name change "Cape Verde" -> "Cabo > Verde." Should the change also include it? > > Naoto > > On 8/29/14, 12:47 AM, Yong Huang wrote: >> Hello, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8055222 >> >> Webrev: http://cr.openjdk.java.net/~yhuang/8055222/webrev.00/ >> >> thanks, >> Yong From masayoshi.okutsu at oracle.com Mon Sep 1 06:46:22 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 01 Sep 2014 15:46:22 +0900 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <5400EB7B.1050303@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> Message-ID: <5404163E.4000805@oracle.com> Do we need availableLocalesTests() of Bug8038436.java? I think it's rather a burden to maintain the hard-coded tags in the test. Otherwise, the fix looks good to me. Thanks, Masayoshi On 8/30/2014 6:07 AM, Naoto Sato wrote: > I incorporated the suggestions from Mandy and Alan. Also one change > since the last webrev was to revert the hard-coding of the supported > locales list back to the one which dynamically generates the lists at > the build time. I initially thought static listing of locales would be > less complex as to the build script/makefile, but on second thought > it's less evil than possible future regressions. > > Please review: > http://cr.openjdk.java.net/~naoto/8038436/webrev.5/ > > Naoto > > On 8/28/14, 11:34 AM, Naoto Sato wrote: >> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the >> changes based on your suggestions as follows: >> >> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/ >> >> Here are the changes since webrev.3 >> >> - CLDRLocaleProviderAdapter.java: modified to throw >> UnsupportedOperationException with the actual exception set to its >> "cause." More descriptive comment on it. >> >> - *ProviderImpl.java: Removed changes to them. Initial thought was to >> make them performant by changing the langtags to static, but it turned >> out that wasn't necessary. >> >> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed >> to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for >> readability. String constants are wrapped for readability as well. Used >> getOrDefault() for getSupportedLocaleString(). >> >> - Added test cases for SecurityException and JRE's supported locales for >> each service. >> >> I'd appreciate it if someone in the build-dev could review the makefile >> changes. >> >> Naoto >> >> On 8/22/14, 11:46 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the changes for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8038436 >>> >>> The proposed changes are located at: >>> >>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/ >>> >>> The idea is to introduce an SPI so that supported locales are >>> dynamically searched at runtime, not depending on the existence of >>> physical jar files. >>> >>> I'd appreciate it if build folks could review the makefile related >>> changes, i18n forks to review locale framework files, and Mandy from >>> modularization point of view. >>> >>> Naoto From mark at macchiato.com Mon Sep 1 06:52:12 2014 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Mon, 1 Sep 2014 08:52:12 +0200 Subject: [9] Review Request - JDK-8055222: ISO 4217 Amendment #159 In-Reply-To: <54040C26.3080806@oracle.com> References: <54003027.1080405@oracle.com> <5400F51A.7000907@oracle.com> <54040C26.3080806@oracle.com> Message-ID: On Mon, Sep 1, 2014 at 8:03 AM, Yong Huang wrote: > Besides country name, there is also the change in currency name "Cape > Verde Escudo" -> "Cabo Verde Escudo". CurrencyNames.properties is generated > based on CLDR and the currency name in it is "Cape Verdean escudo", same as > what in latest CLDR. So I will leave CurrencyNames.properties unchanged, > and only modify LocaleNames.properties. > ?BTW, for a name of an entity in a given language, CLDR tries to use the most common, customary form* in that language*. "Cape Verde" is (at least for now) the most common name for CV in English, although of course the name can be different in other languages. Mark *? Il meglio ? l?inimico del bene ?* From erik.joelsson at oracle.com Mon Sep 1 09:15:29 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 01 Sep 2014 11:15:29 +0200 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <5400EB7B.1050303@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> Message-ID: <54043931.2000702@oracle.com> The reintroduction of the dynamic list looks ok from a build point of view. /Erik On 2014-08-29 23:07, Naoto Sato wrote: > I incorporated the suggestions from Mandy and Alan. Also one change > since the last webrev was to revert the hard-coding of the supported > locales list back to the one which dynamically generates the lists at > the build time. I initially thought static listing of locales would be > less complex as to the build script/makefile, but on second thought > it's less evil than possible future regressions. > > Please review: > http://cr.openjdk.java.net/~naoto/8038436/webrev.5/ > > Naoto > > On 8/28/14, 11:34 AM, Naoto Sato wrote: >> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the >> changes based on your suggestions as follows: >> >> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/ >> >> Here are the changes since webrev.3 >> >> - CLDRLocaleProviderAdapter.java: modified to throw >> UnsupportedOperationException with the actual exception set to its >> "cause." More descriptive comment on it. >> >> - *ProviderImpl.java: Removed changes to them. Initial thought was to >> make them performant by changing the langtags to static, but it turned >> out that wasn't necessary. >> >> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed >> to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for >> readability. String constants are wrapped for readability as well. Used >> getOrDefault() for getSupportedLocaleString(). >> >> - Added test cases for SecurityException and JRE's supported locales for >> each service. >> >> I'd appreciate it if someone in the build-dev could review the makefile >> changes. >> >> Naoto >> >> On 8/22/14, 11:46 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the changes for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8038436 >>> >>> The proposed changes are located at: >>> >>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/ >>> >>> The idea is to introduce an SPI so that supported locales are >>> dynamically searched at runtime, not depending on the existence of >>> physical jar files. >>> >>> I'd appreciate it if build folks could review the makefile related >>> changes, i18n forks to review locale framework files, and Mandy from >>> modularization point of view. >>> >>> Naoto From aleksej.efimov at oracle.com Mon Sep 1 14:10:44 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 01 Sep 2014 18:10:44 +0400 Subject: RFR: 8049343: (tz) Support tzdata2014g In-Reply-To: <53FEA567.9020601@oracle.com> References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com> <53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com> <53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com> <53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com> Message-ID: <54047E64.9020206@oracle.com> Masayoshi, I have addressed all your comments with proposed resolution. Thank you for such thorough analysis of this changes. Also the new tzdata is out (2014g) - I have updated the JBS bug by adding 2014g related change notes and renamed this bug appropriately + I'm renaming this thread. The new webrev contains new changes related to 2014g: - {"America/Grand_Turk", EST}, + {"America/Grand_Turk", AST}, The 2014e/f related changes, discussed previously, are still in place. New webrev can be found here: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 The bug for the incomplete localization of new/updated time zone names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004 With Best Regards, Aleksej On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: > src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: > > 239 String SLST[] = new String[] {"Greenwich Mean Time", "GMT", > 240 "Sierra Leone Summer Time", > "SLST", > 241 "Sierra Leone Time", "SLT"}; > > 251 String WART[] = new String[] {"Western Argentine Time", > "WART", > 252 "Western Argentine Summer > Time", "WARST", > 253 "Western Argentine Time", > "WART"}; > > It seems these are no longer used. > > - {"Antarctica/Macquarie", new String[] {"Macquarie Island > Time", "MIST", > - "Macquarie Island > Summer Time", "MIST", > + {"Antarctica/Macquarie", new String[] {"Macquarie Island > Standard Time", "MIST", > + "Macquarie Island > Daylight Time", "MIST", > > The daylight saving time abbreviation should be MIDT. > > Thanks, > Masayoshi > > On 8/27/2014 10:53 PM, Aleksej Efimov wrote: >> Masayoshi, >> Thank you for a detailed review - I tried to address all your >> comments. Please, see the updated review: >> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03 >> About the workarounds - I will start discussion with Sherman when the >> tzdata2014f (and I suppose the 2014g - it will be available soon >> according to tzdata mail-list [1]) integration will be complete. >> >> -Aleksej >> >> [1] tzdata2014g is coming: >> http://mm.icann.org/pipermail/tz/2014-August/021528.html >> >> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote: >>> Here are additional comments. >>> >>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: >>> >>> I'm concerned about the workarounds. It's not new in this update, >>> but this problem would make tzupdater data void until the workaround >>> is added to the next update release. Could you please work with >>> Sherman to eliminate the workaround (outside of this 2014f update)? >>> >>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>> >>> String LORD_HOWE[] = new String[] {"Lord Howe Standard >>> Time", "LHST", >>> - "Lord Howe Summer Time", >>> "LHST", >>> + "Lord Howe Summer Time", >>> "LHDT", >>> >>> The S-D convention is applied to Lord Howe as well. >>> >>> 567 {"Antarctica/Macquarie", new String[] {"Macquarie >>> Island Time", "MIST", >>> 568 "Macquarie Island Summer Time", "MIST", >>> 569 "Macquarie Island Time", "MIST"}}, >>> >>> This one should also follow the S-D convention, although this time >>> zone doesn't observe daylight saving time. >>> >>> >>> + String XJT[] = new String[] {"China Standard Time", "XJT", >>> + "China Daylight Time", "XJDT", >>> + "China Time", "XJT"}; >>> >>> Should the long names be based on Xinjiang? >>> >>> Africa/Freetown is now a link to Africa/Abidjan. Those should be the >>> same time zone. >>> >>> - {"America/Metlakatla", new String[] {"Metlakatla >>> Standard Time", "MeST", >>> - "Metlakatla >>> Daylight Time", "MeDT", >>> - "Metlakatla Time", >>> "MeT"}}, >>> + {"America/Metlakatla", new String[] {"Metlakatla >>> Standard Time", "PST", >>> + "Metlakatla >>> Daylight Time", "PDT", >>> + "Metlakatla Time", >>> "PT"}}, >>> >>> - {"Europe/Volgograd", new String[] {"Volgograd Time", >>> "VOLT", >>> - "Volgograd Summer >>> Time", "VOLST", >>> - "Volgograd Time", >>> "VOLT"}}, >>> + {"Europe/Volgograd", new String[] {"Volgograd Time", >>> "MSK", >>> + "Volgograd Summer >>> Time", "MSK", >>> + "Volgograd Time", >>> "MSK"}}, >>> >>> >>> The long names should be changed accordingly. >>> >>> Thanks, >>> Masayoshi >>> >>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote: >>>> Masayoshi, >>>> You're right that the "root names" should be changed as part of >>>> this update. The names were changed according to Australian >>>> official document here: >>>> http://australia.gov.au/about-australia/our-country/time >>>> The fixed version of the webrev can be found here: >>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 >>>> >>>> Thanks, >>>> Aleksej >>>> >>>> >>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: >>>>> We used to make name changes in the root (base) bundle as part of >>>>> time zone data maintenance and deter only translations. But if you >>>>> want to handle name changes later, that would be fine. It's your >>>>> call. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote: >>>>>> Masayoshi, >>>>>> I agree that we should change the long names to match the new >>>>>> short names introduced by tzdata. >>>>>> But I suggest to log a different CR for such activity to handle >>>>>> long name changes and their translations (this activity is >>>>>> slightly out of tzdata update scope). Does it make sense? >>>>>> >>>>>> -Aleksej >>>>>> >>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote: >>>>>>> I think the long names of the Australia time zones should be >>>>>>> revisited to be consistent with the abbreviation changes. The >>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] >>>>>>> convention rather than the S[tandard] and S[ummer time] one. The >>>>>>> long names, such as "Eastern Summer Time (Queensland)", no >>>>>>> longer make sense. >>>>>>> >>>>>>> On the other hand, you will need to access impact of the name >>>>>>> changes, including abbreviations. Also, if you change the long >>>>>>> names, their translations will need to be changed as well. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e >>>>>>>> related changes included too) [1] fix to JDK9: >>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ >>>>>>>> >>>>>>>> The tzdata2014f changes are extensive and relates mostly to >>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone >>>>>>>> were added. >>>>>>>> Almost complete list of changes can be found in the JBS bug >>>>>>>> description [1], plus some changes wasn't documented in tzdata >>>>>>>> release notes - for such cases raw tzdata diff was used for the >>>>>>>> names modifications. >>>>>>>> >>>>>>>> Two issues with JSR310 implementation were discovered during >>>>>>>> integration process: >>>>>>>> First issue is related to the internal representation of the >>>>>>>> '24:00' value. The JSR310 implementation treats this value as a >>>>>>>> next day 00:00 time. The workaround already exists in JSR310 >>>>>>>> code for similar entries and this failure is resolved in >>>>>>>> similar way [2] as part of this update. >>>>>>>> For the second issue JDK-8051641 [3] was filled and >>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only >>>>>>>> one that fails with this tzdata. >>>>>>>> Other time zone related tests [4] passes without failures. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Aleksej >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343 >>>>>>>> [2] >>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch >>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641 >>>>>>>> [4] TZ related test sets: test/sun/util/calendar >>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ >>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar >>>>>>>> test/closed/java/util/TimeZone >>>>>>> >>>>>> >>>>> >>>> >>> >> > From masayoshi.okutsu at oracle.com Tue Sep 2 06:03:42 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 02 Sep 2014 15:03:42 +0900 Subject: RFR: 8049343: (tz) Support tzdata2014g In-Reply-To: <54047E64.9020206@oracle.com> References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com> <53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com> <53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com> <53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com> <54047E64.9020206@oracle.com> Message-ID: <54055DBE.3060804@oracle.com> Aleksej, I don't see the America/Grand_Turk change in webrev.04. I wonder if the webrev wasn't updated correctly. Thanks, Masayoshi On 9/1/2014 11:10 PM, Aleksej Efimov wrote: > Masayoshi, > > I have addressed all your comments with proposed resolution. Thank you > for such thorough analysis of this changes. > > Also the new tzdata is out (2014g) - I have updated the JBS bug by > adding 2014g related change notes and renamed this bug appropriately + > I'm renaming this thread. > The new webrev contains new changes related to 2014g: > - {"America/Grand_Turk", EST}, > + {"America/Grand_Turk", AST}, > > > The 2014e/f related changes, discussed previously, are still in place. > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 > > The bug for the incomplete localization of new/updated time zone names > was filed: https://bugs.openjdk.java.net/browse/JDK-8057004 > > With Best Regards, > Aleksej > > On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: >> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >> >> 239 String SLST[] = new String[] {"Greenwich Mean Time", "GMT", >> 240 "Sierra Leone Summer >> Time", "SLST", >> 241 "Sierra Leone Time", "SLT"}; >> >> 251 String WART[] = new String[] {"Western Argentine Time", >> "WART", >> 252 "Western Argentine Summer >> Time", "WARST", >> 253 "Western Argentine Time", >> "WART"}; >> >> It seems these are no longer used. >> >> - {"Antarctica/Macquarie", new String[] {"Macquarie Island >> Time", "MIST", >> - "Macquarie Island >> Summer Time", "MIST", >> + {"Antarctica/Macquarie", new String[] {"Macquarie Island >> Standard Time", "MIST", >> + "Macquarie Island >> Daylight Time", "MIST", >> >> The daylight saving time abbreviation should be MIDT. >> >> Thanks, >> Masayoshi >> >> On 8/27/2014 10:53 PM, Aleksej Efimov wrote: >>> Masayoshi, >>> Thank you for a detailed review - I tried to address all your >>> comments. Please, see the updated review: >>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03 >>> About the workarounds - I will start discussion with Sherman when >>> the tzdata2014f (and I suppose the 2014g - it will be available soon >>> according to tzdata mail-list [1]) integration will be complete. >>> >>> -Aleksej >>> >>> [1] tzdata2014g is coming: >>> http://mm.icann.org/pipermail/tz/2014-August/021528.html >>> >>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote: >>>> Here are additional comments. >>>> >>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: >>>> >>>> I'm concerned about the workarounds. It's not new in this update, >>>> but this problem would make tzupdater data void until the >>>> workaround is added to the next update release. Could you please >>>> work with Sherman to eliminate the workaround (outside of this >>>> 2014f update)? >>>> >>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>>> >>>> String LORD_HOWE[] = new String[] {"Lord Howe Standard >>>> Time", "LHST", >>>> - "Lord Howe Summer >>>> Time", "LHST", >>>> + "Lord Howe Summer >>>> Time", "LHDT", >>>> >>>> The S-D convention is applied to Lord Howe as well. >>>> >>>> 567 {"Antarctica/Macquarie", new String[] {"Macquarie >>>> Island Time", "MIST", >>>> 568 "Macquarie Island Summer Time", "MIST", >>>> 569 "Macquarie Island Time", "MIST"}}, >>>> >>>> This one should also follow the S-D convention, although this time >>>> zone doesn't observe daylight saving time. >>>> >>>> >>>> + String XJT[] = new String[] {"China Standard Time", "XJT", >>>> + "China Daylight Time", "XJDT", >>>> + "China Time", "XJT"}; >>>> >>>> Should the long names be based on Xinjiang? >>>> >>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be >>>> the same time zone. >>>> >>>> - {"America/Metlakatla", new String[] {"Metlakatla >>>> Standard Time", "MeST", >>>> - "Metlakatla Daylight Time", "MeDT", >>>> - "Metlakatla Time", "MeT"}}, >>>> + {"America/Metlakatla", new String[] {"Metlakatla >>>> Standard Time", "PST", >>>> + "Metlakatla Daylight Time", "PDT", >>>> + "Metlakatla Time", "PT"}}, >>>> >>>> - {"Europe/Volgograd", new String[] {"Volgograd Time", >>>> "VOLT", >>>> - "Volgograd Summer >>>> Time", "VOLST", >>>> - "Volgograd Time", >>>> "VOLT"}}, >>>> + {"Europe/Volgograd", new String[] {"Volgograd Time", >>>> "MSK", >>>> + "Volgograd Summer >>>> Time", "MSK", >>>> + "Volgograd Time", >>>> "MSK"}}, >>>> >>>> >>>> The long names should be changed accordingly. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote: >>>>> Masayoshi, >>>>> You're right that the "root names" should be changed as part of >>>>> this update. The names were changed according to Australian >>>>> official document here: >>>>> http://australia.gov.au/about-australia/our-country/time >>>>> The fixed version of the webrev can be found here: >>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> >>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: >>>>>> We used to make name changes in the root (base) bundle as part of >>>>>> time zone data maintenance and deter only translations. But if >>>>>> you want to handle name changes later, that would be fine. It's >>>>>> your call. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote: >>>>>>> Masayoshi, >>>>>>> I agree that we should change the long names to match the new >>>>>>> short names introduced by tzdata. >>>>>>> But I suggest to log a different CR for such activity to handle >>>>>>> long name changes and their translations (this activity is >>>>>>> slightly out of tzdata update scope). Does it make sense? >>>>>>> >>>>>>> -Aleksej >>>>>>> >>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote: >>>>>>>> I think the long names of the Australia time zones should be >>>>>>>> revisited to be consistent with the abbreviation changes. The >>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] >>>>>>>> convention rather than the S[tandard] and S[ummer time] one. >>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no >>>>>>>> longer make sense. >>>>>>>> >>>>>>>> On the other hand, you will need to access impact of the name >>>>>>>> changes, including abbreviations. Also, if you change the long >>>>>>>> names, their translations will need to be changed as well. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Masayoshi >>>>>>>> >>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e >>>>>>>>> related changes included too) [1] fix to JDK9: >>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ >>>>>>>>> >>>>>>>>> The tzdata2014f changes are extensive and relates mostly to >>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone >>>>>>>>> were added. >>>>>>>>> Almost complete list of changes can be found in the JBS bug >>>>>>>>> description [1], plus some changes wasn't documented in tzdata >>>>>>>>> release notes - for such cases raw tzdata diff was used for >>>>>>>>> the names modifications. >>>>>>>>> >>>>>>>>> Two issues with JSR310 implementation were discovered during >>>>>>>>> integration process: >>>>>>>>> First issue is related to the internal representation of the >>>>>>>>> '24:00' value. The JSR310 implementation treats this value as >>>>>>>>> a next day 00:00 time. The workaround already exists in JSR310 >>>>>>>>> code for similar entries and this failure is resolved in >>>>>>>>> similar way [2] as part of this update. >>>>>>>>> For the second issue JDK-8051641 [3] was filled and >>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only >>>>>>>>> one that fails with this tzdata. >>>>>>>>> Other time zone related tests [4] passes without failures. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Aleksej >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343 >>>>>>>>> [2] >>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch >>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641 >>>>>>>>> [4] TZ related test sets: test/sun/util/calendar >>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ >>>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar >>>>>>>>> test/closed/java/util/TimeZone >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From aleksej.efimov at oracle.com Tue Sep 2 13:41:13 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 02 Sep 2014 17:41:13 +0400 Subject: RFR: 8049343: (tz) Support tzdata2014g In-Reply-To: <54055DBE.3060804@oracle.com> References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com> <53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com> <53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com> <53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com> <54047E64.9020206@oracle.com> <54055DBE.3060804@oracle.com> Message-ID: <5405C8F9.7090606@oracle.com> Masayoshi, Sorry for the confusion - for some reason (most probably this change was added after webrev generation) I forgot to include it. Now it's in place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 Thank you, Aleksej On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote: > Aleksej, > > I don't see the America/Grand_Turk change in webrev.04. I wonder if > the webrev wasn't updated correctly. > > Thanks, > Masayoshi > > On 9/1/2014 11:10 PM, Aleksej Efimov wrote: >> Masayoshi, >> >> I have addressed all your comments with proposed resolution. Thank >> you for such thorough analysis of this changes. >> >> Also the new tzdata is out (2014g) - I have updated the JBS bug by >> adding 2014g related change notes and renamed this bug appropriately >> + I'm renaming this thread. >> The new webrev contains new changes related to 2014g: >> - {"America/Grand_Turk", EST}, >> + {"America/Grand_Turk", AST}, >> >> >> The 2014e/f related changes, discussed previously, are still in place. >> >> New webrev can be found here: >> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 >> >> The bug for the incomplete localization of new/updated time zone >> names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004 >> >> With Best Regards, >> Aleksej >> >> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: >>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>> >>> 239 String SLST[] = new String[] {"Greenwich Mean Time", >>> "GMT", >>> 240 "Sierra Leone Summer >>> Time", "SLST", >>> 241 "Sierra Leone Time", "SLT"}; >>> >>> 251 String WART[] = new String[] {"Western Argentine Time", >>> "WART", >>> 252 "Western Argentine Summer >>> Time", "WARST", >>> 253 "Western Argentine Time", >>> "WART"}; >>> >>> It seems these are no longer used. >>> >>> - {"Antarctica/Macquarie", new String[] {"Macquarie >>> Island Time", "MIST", >>> - "Macquarie >>> Island Summer Time", "MIST", >>> + {"Antarctica/Macquarie", new String[] {"Macquarie >>> Island Standard Time", "MIST", >>> + "Macquarie >>> Island Daylight Time", "MIST", >>> >>> The daylight saving time abbreviation should be MIDT. >>> >>> Thanks, >>> Masayoshi >>> >>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote: >>>> Masayoshi, >>>> Thank you for a detailed review - I tried to address all your >>>> comments. Please, see the updated review: >>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03 >>>> About the workarounds - I will start discussion with Sherman when >>>> the tzdata2014f (and I suppose the 2014g - it will be available >>>> soon according to tzdata mail-list [1]) integration will be complete. >>>> >>>> -Aleksej >>>> >>>> [1] tzdata2014g is coming: >>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html >>>> >>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote: >>>>> Here are additional comments. >>>>> >>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: >>>>> >>>>> I'm concerned about the workarounds. It's not new in this update, >>>>> but this problem would make tzupdater data void until the >>>>> workaround is added to the next update release. Could you please >>>>> work with Sherman to eliminate the workaround (outside of this >>>>> 2014f update)? >>>>> >>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>>>> >>>>> String LORD_HOWE[] = new String[] {"Lord Howe Standard >>>>> Time", "LHST", >>>>> - "Lord Howe Summer >>>>> Time", "LHST", >>>>> + "Lord Howe Summer >>>>> Time", "LHDT", >>>>> >>>>> The S-D convention is applied to Lord Howe as well. >>>>> >>>>> 567 {"Antarctica/Macquarie", new String[] {"Macquarie >>>>> Island Time", "MIST", >>>>> 568 "Macquarie Island Summer Time", "MIST", >>>>> 569 "Macquarie Island Time", "MIST"}}, >>>>> >>>>> This one should also follow the S-D convention, although this time >>>>> zone doesn't observe daylight saving time. >>>>> >>>>> >>>>> + String XJT[] = new String[] {"China Standard Time", "XJT", >>>>> + "China Daylight Time", "XJDT", >>>>> + "China Time", "XJT"}; >>>>> >>>>> Should the long names be based on Xinjiang? >>>>> >>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be >>>>> the same time zone. >>>>> >>>>> - {"America/Metlakatla", new String[] {"Metlakatla >>>>> Standard Time", "MeST", >>>>> - "Metlakatla Daylight Time", "MeDT", >>>>> - "Metlakatla Time", "MeT"}}, >>>>> + {"America/Metlakatla", new String[] {"Metlakatla >>>>> Standard Time", "PST", >>>>> + "Metlakatla Daylight Time", "PDT", >>>>> + "Metlakatla Time", "PT"}}, >>>>> >>>>> - {"Europe/Volgograd", new String[] {"Volgograd Time", >>>>> "VOLT", >>>>> - "Volgograd Summer >>>>> Time", "VOLST", >>>>> - "Volgograd Time", >>>>> "VOLT"}}, >>>>> + {"Europe/Volgograd", new String[] {"Volgograd Time", >>>>> "MSK", >>>>> + "Volgograd Summer >>>>> Time", "MSK", >>>>> + "Volgograd Time", >>>>> "MSK"}}, >>>>> >>>>> >>>>> The long names should be changed accordingly. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote: >>>>>> Masayoshi, >>>>>> You're right that the "root names" should be changed as part of >>>>>> this update. The names were changed according to Australian >>>>>> official document here: >>>>>> http://australia.gov.au/about-australia/our-country/time >>>>>> The fixed version of the webrev can be found here: >>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 >>>>>> >>>>>> Thanks, >>>>>> Aleksej >>>>>> >>>>>> >>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: >>>>>>> We used to make name changes in the root (base) bundle as part >>>>>>> of time zone data maintenance and deter only translations. But >>>>>>> if you want to handle name changes later, that would be fine. >>>>>>> It's your call. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote: >>>>>>>> Masayoshi, >>>>>>>> I agree that we should change the long names to match the new >>>>>>>> short names introduced by tzdata. >>>>>>>> But I suggest to log a different CR for such activity to handle >>>>>>>> long name changes and their translations (this activity is >>>>>>>> slightly out of tzdata update scope). Does it make sense? >>>>>>>> >>>>>>>> -Aleksej >>>>>>>> >>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote: >>>>>>>>> I think the long names of the Australia time zones should be >>>>>>>>> revisited to be consistent with the abbreviation changes. The >>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] >>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. >>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no >>>>>>>>> longer make sense. >>>>>>>>> >>>>>>>>> On the other hand, you will need to access impact of the name >>>>>>>>> changes, including abbreviations. Also, if you change the long >>>>>>>>> names, their translations will need to be changed as well. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Masayoshi >>>>>>>>> >>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e >>>>>>>>>> related changes included too) [1] fix to JDK9: >>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ >>>>>>>>>> >>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to >>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone >>>>>>>>>> were added. >>>>>>>>>> Almost complete list of changes can be found in the JBS bug >>>>>>>>>> description [1], plus some changes wasn't documented in >>>>>>>>>> tzdata release notes - for such cases raw tzdata diff was >>>>>>>>>> used for the names modifications. >>>>>>>>>> >>>>>>>>>> Two issues with JSR310 implementation were discovered during >>>>>>>>>> integration process: >>>>>>>>>> First issue is related to the internal representation of the >>>>>>>>>> '24:00' value. The JSR310 implementation treats this value as >>>>>>>>>> a next day 00:00 time. The workaround already exists in >>>>>>>>>> JSR310 code for similar entries and this failure is resolved >>>>>>>>>> in similar way [2] as part of this update. >>>>>>>>>> For the second issue JDK-8051641 [3] was filled and >>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only >>>>>>>>>> one that fails with this tzdata. >>>>>>>>>> Other time zone related tests [4] passes without failures. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Aleksej >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343 >>>>>>>>>> [2] >>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch >>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641 >>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar >>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone >>>>>>>>>> test/java/time\ test/java/util/Formatter >>>>>>>>>> test/closed/java/util/Calendar test/closed/java/util/TimeZone >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From naoto.sato at oracle.com Tue Sep 2 17:31:52 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 02 Sep 2014 10:31:52 -0700 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <5401C7F6.9010804@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> <5401C7F6.9010804@oracle.com> Message-ID: <5405FF08.6070708@oracle.com> On 8/30/14, 5:47 AM, Alan Bateman wrote: > On 29/08/2014 22:07, Naoto Sato wrote: >> I incorporated the suggestions from Mandy and Alan. Also one change >> since the last webrev was to revert the hard-coding of the supported >> locales list back to the one which dynamically generates the lists at >> the build time. I initially thought static listing of locales would be >> less complex as to the build script/makefile, but on second thought >> it's less evil than possible future regressions. >> >> Please review: >> http://cr.openjdk.java.net/~naoto/8038436/webrev.5/ >> > I think this looks okay and I assume you'll create another issue to > re-examine the error handling as I do think that does need to be looked > at again (my main concern is that it will silently failover and that > could be very hard to diagnose). Created an issue: https://bugs.openjdk.java.net/browse/JDK-8057075 > > One comment on the test Bug8038436 is that it sets java.ext.dirs on the > assumption that the locale and cldr data wouldn't be found. I suspect > this will need to be re-worked once we get to the point of linking > modules into the image. It may be that the ext directory is empty by > default (localdata.jar and cldrdata.jar will not exist). Yes. Will address this when I work on 8048588. Naoto From naoto.sato at oracle.com Tue Sep 2 17:57:58 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 02 Sep 2014 10:57:58 -0700 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <5404163E.4000805@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> <5404163E.4000805@oracle.com> Message-ID: <54060526.3000505@oracle.com> On 8/31/14, 11:46 PM, Masayoshi Okutsu wrote: > Do we need availableLocalesTests() of Bug8038436.java? I think it's > rather a burden to maintain the hard-coded tags in the test. I think it's worthy to have such test that have golden data in it. I don't think there would be much changes in JRE providers' supported locales, as they will be in maintenance mode. > > Otherwise, the fix looks good to me. Thank you for the review! Naoto > > Thanks, > Masayoshi > > On 8/30/2014 6:07 AM, Naoto Sato wrote: >> I incorporated the suggestions from Mandy and Alan. Also one change >> since the last webrev was to revert the hard-coding of the supported >> locales list back to the one which dynamically generates the lists at >> the build time. I initially thought static listing of locales would be >> less complex as to the build script/makefile, but on second thought >> it's less evil than possible future regressions. >> >> Please review: >> http://cr.openjdk.java.net/~naoto/8038436/webrev.5/ >> >> Naoto >> >> On 8/28/14, 11:34 AM, Naoto Sato wrote: >>> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the >>> changes based on your suggestions as follows: >>> >>> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/ >>> >>> Here are the changes since webrev.3 >>> >>> - CLDRLocaleProviderAdapter.java: modified to throw >>> UnsupportedOperationException with the actual exception set to its >>> "cause." More descriptive comment on it. >>> >>> - *ProviderImpl.java: Removed changes to them. Initial thought was to >>> make them performant by changing the langtags to static, but it turned >>> out that wasn't necessary. >>> >>> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed >>> to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for >>> readability. String constants are wrapped for readability as well. Used >>> getOrDefault() for getSupportedLocaleString(). >>> >>> - Added test cases for SecurityException and JRE's supported locales for >>> each service. >>> >>> I'd appreciate it if someone in the build-dev could review the makefile >>> changes. >>> >>> Naoto >>> >>> On 8/22/14, 11:46 AM, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the changes for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8038436 >>>> >>>> The proposed changes are located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/ >>>> >>>> The idea is to introduce an SPI so that supported locales are >>>> dynamically searched at runtime, not depending on the existence of >>>> physical jar files. >>>> >>>> I'd appreciate it if build folks could review the makefile related >>>> changes, i18n forks to review locale framework files, and Mandy from >>>> modularization point of view. >>>> >>>> Naoto > From mandy.chung at oracle.com Tue Sep 2 18:48:55 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 02 Sep 2014 11:48:55 -0700 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <5400EB7B.1050303@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> Message-ID: <54061117.2050509@oracle.com> On 8/29/14 2:07 PM, Naoto Sato wrote: > I incorporated the suggestions from Mandy and Alan. Also one change > since the last webrev was to revert the hard-coding of the supported > locales list back to the one which dynamically generates the lists at > the build time. I initially thought static listing of locales would be > less complex as to the build script/makefile, but on second thought > it's less evil than possible future regressions. > > Please review: > http://cr.openjdk.java.net/~naoto/8038436/webrev.5/ > Looks okay. This patch looks simpler which is good. GensrcCLDR.gmk and GensrcLocaleDataMetaInfo.gmk generate sources for java.base and jdk.localedata. I think we should re-examine to modify the tool e.g. to take an input parameter specifying which locales or module the source is generated for. This will make the i18 build better fit the new modular build logic such that Gensrc-java.base.gmk generates the source for java.base and a new Gensrc-jdk.localedata.gmk generates the source for jdk.localedata. Can you re-examine the build logic when you work on JDK-8048588? I see that you file JDK-8057075 which is good. As you recalled, it took us quite some time to diagnose the security permission issue your test case ran into and didn't realize the silent failover is an existing behavior. Mandy From naoto.sato at oracle.com Tue Sep 2 20:16:42 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 02 Sep 2014 13:16:42 -0700 Subject: [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata In-Reply-To: <54061117.2050509@oracle.com> References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com> <5400EB7B.1050303@oracle.com> <54061117.2050509@oracle.com> Message-ID: <540625AA.2070604@oracle.com> On 9/2/14, 11:48 AM, Mandy Chung wrote: > GensrcCLDR.gmk and GensrcLocaleDataMetaInfo.gmk generate sources for > java.base and jdk.localedata. I think we should re-examine to modify > the tool e.g. to take an input parameter specifying which locales or > module the source is generated for. This will make the i18 build > better fit the new modular build logic such that Gensrc-java.base.gmk > generates the source for java.base and a new Gensrc-jdk.localedata.gmk > generates the source for jdk.localedata. Can you re-examine the > build logic when you work on JDK-8048588? Yes, it will be considered with 8048588. Naoto From naoto.sato at oracle.com Tue Sep 2 20:28:11 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 02 Sep 2014 13:28:11 -0700 Subject: [9] Review Request - JDK-8055222: ISO 4217 Amendment #159 In-Reply-To: References: <54003027.1080405@oracle.com> <5400F51A.7000907@oracle.com> <54040C26.3080806@oracle.com> Message-ID: <5406285B.2020301@oracle.com> Hi Mark, I understand that the English name for "CV" should be customary "Cape Verde" in English, but for the root locale, should the name adopt ISO 3166's bare name, where they switched it from "Cape Verde" to "Cabo Verde"? https://www.iso.org/obp/ui/#iso:code:3166:CV Naoto On 8/31/14, 11:52 PM, Mark Davis ?? wrote: > > On Mon, Sep 1, 2014 at 8:03 AM, Yong Huang > wrote: > > Besides country name, there is also the change in currency name > "Cape Verde Escudo" -> "Cabo Verde Escudo". CurrencyNames.properties > is generated based on CLDR and the currency name in it is "Cape > Verdean escudo", same as what in latest CLDR. So I will leave > CurrencyNames.properties unchanged, and only modify > LocaleNames.properties. > > > ?BTW, for a name of an entity in a given language, CLDR tries to use the > most common, customary form/in that language/. "Cape Verde" is (at least > for now) the most common name for CV in English, although of course the > name can be different in other languages. > > Mark > / > / > /? Il meglio ? l?inimico del bene ?/ > ////// From yong.huang at oracle.com Wed Sep 3 02:33:53 2014 From: yong.huang at oracle.com (Yong Huang) Date: Wed, 03 Sep 2014 10:33:53 +0800 Subject: [9] Review Request - JDK-8055222: ISO 4217 Amendment #159 In-Reply-To: <5406285B.2020301@oracle.com> References: <54003027.1080405@oracle.com> <5400F51A.7000907@oracle.com> <54040C26.3080806@oracle.com> <5406285B.2020301@oracle.com> Message-ID: <54067E11.6040007@oracle.com> Hi Naoto, Mark, Thank you for all the comments. I will keep "Cape Verde" unchanged in LocaleNames.properties since CLDR is de facto standard of locale data. So far I assume that the request has been approved and I will commit and push back the change in http://cr.openjdk.java.net/~yhuang/8055222/webrev.00/ without any modification. If I need to make any change, please feel free to tell me. thanks, Yong On 2014/9/3 4:28, Naoto Sato wrote: > Hi Mark, > > I understand that the English name for "CV" should be customary "Cape > Verde" in English, but for the root locale, should the name adopt ISO > 3166's bare name, where they switched it from "Cape Verde" to "Cabo > Verde"? > > https://www.iso.org/obp/ui/#iso:code:3166:CV > > Naoto > > On 8/31/14, 11:52 PM, Mark Davis ?? wrote: >> >> On Mon, Sep 1, 2014 at 8:03 AM, Yong Huang > > wrote: >> >> Besides country name, there is also the change in currency name >> "Cape Verde Escudo" -> "Cabo Verde Escudo". CurrencyNames.properties >> is generated based on CLDR and the currency name in it is "Cape >> Verdean escudo", same as what in latest CLDR. So I will leave >> CurrencyNames.properties unchanged, and only modify >> LocaleNames.properties. >> >> >> ?BTW, for a name of an entity in a given language, CLDR tries to use the >> most common, customary form/in that language/. "Cape Verde" is (at least >> for now) the most common name for CV in English, although of course the >> name can be different in other languages. >> >> Mark >> / >> / >> /? Il meglio ? l?inimico del bene ?/ >> ////// From michael.fang at oracle.com Wed Sep 3 06:07:52 2014 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 02 Sep 2014 23:07:52 -0700 Subject: RFR: 8049343: (tz) Support tzdata2014g In-Reply-To: <54047E64.9020206@oracle.com> References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com> <53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com> <53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com> <53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com> <54047E64.9020206@oracle.com> Message-ID: <5406B038.4070807@oracle.com> Aleksej, Yes, I agree the translation update of the time zone names can be handled separately as JDK-8057004. thanks, -michael On 14?09?01? 07:10 ??, Aleksej Efimov wrote: > Masayoshi, > > I have addressed all your comments with proposed resolution. Thank you > for such thorough analysis of this changes. > > Also the new tzdata is out (2014g) - I have updated the JBS bug by > adding 2014g related change notes and renamed this bug appropriately + > I'm renaming this thread. > The new webrev contains new changes related to 2014g: > - {"America/Grand_Turk", EST}, > + {"America/Grand_Turk", AST}, > > > The 2014e/f related changes, discussed previously, are still in place. > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 > > The bug for the incomplete localization of new/updated time zone names > was filed: https://bugs.openjdk.java.net/browse/JDK-8057004 > > With Best Regards, > Aleksej > > On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: >> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >> >> 239 String SLST[] = new String[] {"Greenwich Mean Time", "GMT", >> 240 "Sierra Leone Summer >> Time", "SLST", >> 241 "Sierra Leone Time", "SLT"}; >> >> 251 String WART[] = new String[] {"Western Argentine Time", >> "WART", >> 252 "Western Argentine Summer >> Time", "WARST", >> 253 "Western Argentine Time", >> "WART"}; >> >> It seems these are no longer used. >> >> - {"Antarctica/Macquarie", new String[] {"Macquarie Island >> Time", "MIST", >> - "Macquarie Island >> Summer Time", "MIST", >> + {"Antarctica/Macquarie", new String[] {"Macquarie Island >> Standard Time", "MIST", >> + "Macquarie Island >> Daylight Time", "MIST", >> >> The daylight saving time abbreviation should be MIDT. >> >> Thanks, >> Masayoshi >> >> On 8/27/2014 10:53 PM, Aleksej Efimov wrote: >>> Masayoshi, >>> Thank you for a detailed review - I tried to address all your >>> comments. Please, see the updated review: >>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03 >>> About the workarounds - I will start discussion with Sherman when >>> the tzdata2014f (and I suppose the 2014g - it will be available soon >>> according to tzdata mail-list [1]) integration will be complete. >>> >>> -Aleksej >>> >>> [1] tzdata2014g is coming: >>> http://mm.icann.org/pipermail/tz/2014-August/021528.html >>> >>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote: >>>> Here are additional comments. >>>> >>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: >>>> >>>> I'm concerned about the workarounds. It's not new in this update, >>>> but this problem would make tzupdater data void until the >>>> workaround is added to the next update release. Could you please >>>> work with Sherman to eliminate the workaround (outside of this >>>> 2014f update)? >>>> >>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>>> >>>> String LORD_HOWE[] = new String[] {"Lord Howe Standard >>>> Time", "LHST", >>>> - "Lord Howe Summer >>>> Time", "LHST", >>>> + "Lord Howe Summer >>>> Time", "LHDT", >>>> >>>> The S-D convention is applied to Lord Howe as well. >>>> >>>> 567 {"Antarctica/Macquarie", new String[] {"Macquarie >>>> Island Time", "MIST", >>>> 568 "Macquarie Island Summer Time", "MIST", >>>> 569 "Macquarie Island Time", "MIST"}}, >>>> >>>> This one should also follow the S-D convention, although this time >>>> zone doesn't observe daylight saving time. >>>> >>>> >>>> + String XJT[] = new String[] {"China Standard Time", "XJT", >>>> + "China Daylight Time", "XJDT", >>>> + "China Time", "XJT"}; >>>> >>>> Should the long names be based on Xinjiang? >>>> >>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be >>>> the same time zone. >>>> >>>> - {"America/Metlakatla", new String[] {"Metlakatla >>>> Standard Time", "MeST", >>>> - "Metlakatla >>>> Daylight Time", "MeDT", >>>> - "Metlakatla >>>> Time", "MeT"}}, >>>> + {"America/Metlakatla", new String[] {"Metlakatla >>>> Standard Time", "PST", >>>> + "Metlakatla >>>> Daylight Time", "PDT", >>>> + "Metlakatla >>>> Time", "PT"}}, >>>> >>>> - {"Europe/Volgograd", new String[] {"Volgograd Time", >>>> "VOLT", >>>> - "Volgograd Summer >>>> Time", "VOLST", >>>> - "Volgograd Time", >>>> "VOLT"}}, >>>> + {"Europe/Volgograd", new String[] {"Volgograd Time", >>>> "MSK", >>>> + "Volgograd Summer >>>> Time", "MSK", >>>> + "Volgograd Time", >>>> "MSK"}}, >>>> >>>> >>>> The long names should be changed accordingly. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote: >>>>> Masayoshi, >>>>> You're right that the "root names" should be changed as part of >>>>> this update. The names were changed according to Australian >>>>> official document here: >>>>> http://australia.gov.au/about-australia/our-country/time >>>>> The fixed version of the webrev can be found here: >>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> >>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: >>>>>> We used to make name changes in the root (base) bundle as part of >>>>>> time zone data maintenance and deter only translations. But if >>>>>> you want to handle name changes later, that would be fine. It's >>>>>> your call. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote: >>>>>>> Masayoshi, >>>>>>> I agree that we should change the long names to match the new >>>>>>> short names introduced by tzdata. >>>>>>> But I suggest to log a different CR for such activity to handle >>>>>>> long name changes and their translations (this activity is >>>>>>> slightly out of tzdata update scope). Does it make sense? >>>>>>> >>>>>>> -Aleksej >>>>>>> >>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote: >>>>>>>> I think the long names of the Australia time zones should be >>>>>>>> revisited to be consistent with the abbreviation changes. The >>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] >>>>>>>> convention rather than the S[tandard] and S[ummer time] one. >>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no >>>>>>>> longer make sense. >>>>>>>> >>>>>>>> On the other hand, you will need to access impact of the name >>>>>>>> changes, including abbreviations. Also, if you change the long >>>>>>>> names, their translations will need to be changed as well. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Masayoshi >>>>>>>> >>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e >>>>>>>>> related changes included too) [1] fix to JDK9: >>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ >>>>>>>>> >>>>>>>>> The tzdata2014f changes are extensive and relates mostly to >>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone >>>>>>>>> were added. >>>>>>>>> Almost complete list of changes can be found in the JBS bug >>>>>>>>> description [1], plus some changes wasn't documented in tzdata >>>>>>>>> release notes - for such cases raw tzdata diff was used for >>>>>>>>> the names modifications. >>>>>>>>> >>>>>>>>> Two issues with JSR310 implementation were discovered during >>>>>>>>> integration process: >>>>>>>>> First issue is related to the internal representation of the >>>>>>>>> '24:00' value. The JSR310 implementation treats this value as >>>>>>>>> a next day 00:00 time. The workaround already exists in JSR310 >>>>>>>>> code for similar entries and this failure is resolved in >>>>>>>>> similar way [2] as part of this update. >>>>>>>>> For the second issue JDK-8051641 [3] was filled and >>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only >>>>>>>>> one that fails with this tzdata. >>>>>>>>> Other time zone related tests [4] passes without failures. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Aleksej >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343 >>>>>>>>> [2] >>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch >>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641 >>>>>>>>> [4] TZ related test sets: test/sun/util/calendar >>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ >>>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar >>>>>>>>> test/closed/java/util/TimeZone >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From masayoshi.okutsu at oracle.com Thu Sep 4 06:33:36 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 04 Sep 2014 15:33:36 +0900 Subject: RFR: 8049343: (tz) Support tzdata2014g In-Reply-To: <5405C8F9.7090606@oracle.com> References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com> <53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com> <53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com> <53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com> <54047E64.9020206@oracle.com> <54055DBE.3060804@oracle.com> <5405C8F9.7090606@oracle.com> Message-ID: <540807C0.9000204@oracle.com> The fix looks OK to me. Thanks, Masayoshi On 9/2/2014 10:41 PM, Aleksej Efimov wrote: > Masayoshi, > Sorry for the confusion - for some reason (most probably this change > was added after webrev generation) I forgot to include it. Now it's in > place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 > > Thank you, > Aleksej > > On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote: >> Aleksej, >> >> I don't see the America/Grand_Turk change in webrev.04. I wonder if >> the webrev wasn't updated correctly. >> >> Thanks, >> Masayoshi >> >> On 9/1/2014 11:10 PM, Aleksej Efimov wrote: >>> Masayoshi, >>> >>> I have addressed all your comments with proposed resolution. Thank >>> you for such thorough analysis of this changes. >>> >>> Also the new tzdata is out (2014g) - I have updated the JBS bug by >>> adding 2014g related change notes and renamed this bug appropriately >>> + I'm renaming this thread. >>> The new webrev contains new changes related to 2014g: >>> - {"America/Grand_Turk", EST}, >>> + {"America/Grand_Turk", AST}, >>> >>> >>> The 2014e/f related changes, discussed previously, are still in place. >>> >>> New webrev can be found here: >>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04 >>> >>> The bug for the incomplete localization of new/updated time zone >>> names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004 >>> >>> With Best Regards, >>> Aleksej >>> >>> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: >>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>>> >>>> 239 String SLST[] = new String[] {"Greenwich Mean Time", >>>> "GMT", >>>> 240 "Sierra Leone Summer >>>> Time", "SLST", >>>> 241 "Sierra Leone Time", >>>> "SLT"}; >>>> >>>> 251 String WART[] = new String[] {"Western Argentine >>>> Time", "WART", >>>> 252 "Western Argentine >>>> Summer Time", "WARST", >>>> 253 "Western Argentine >>>> Time", "WART"}; >>>> >>>> It seems these are no longer used. >>>> >>>> - {"Antarctica/Macquarie", new String[] {"Macquarie >>>> Island Time", "MIST", >>>> - "Macquarie Island Summer Time", "MIST", >>>> + {"Antarctica/Macquarie", new String[] {"Macquarie >>>> Island Standard Time", "MIST", >>>> + "Macquarie Island Daylight Time", "MIST", >>>> >>>> The daylight saving time abbreviation should be MIDT. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote: >>>>> Masayoshi, >>>>> Thank you for a detailed review - I tried to address all your >>>>> comments. Please, see the updated review: >>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03 >>>>> About the workarounds - I will start discussion with Sherman when >>>>> the tzdata2014f (and I suppose the 2014g - it will be available >>>>> soon according to tzdata mail-list [1]) integration will be complete. >>>>> >>>>> -Aleksej >>>>> >>>>> [1] tzdata2014g is coming: >>>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html >>>>> >>>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote: >>>>>> Here are additional comments. >>>>>> >>>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: >>>>>> >>>>>> I'm concerned about the workarounds. It's not new in this update, >>>>>> but this problem would make tzupdater data void until the >>>>>> workaround is added to the next update release. Could you please >>>>>> work with Sherman to eliminate the workaround (outside of this >>>>>> 2014f update)? >>>>>> >>>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: >>>>>> >>>>>> String LORD_HOWE[] = new String[] {"Lord Howe Standard >>>>>> Time", "LHST", >>>>>> - "Lord Howe Summer >>>>>> Time", "LHST", >>>>>> + "Lord Howe Summer >>>>>> Time", "LHDT", >>>>>> >>>>>> The S-D convention is applied to Lord Howe as well. >>>>>> >>>>>> 567 {"Antarctica/Macquarie", new String[] >>>>>> {"Macquarie Island Time", "MIST", >>>>>> 568 "Macquarie Island Summer Time", "MIST", >>>>>> 569 "Macquarie Island Time", "MIST"}}, >>>>>> >>>>>> This one should also follow the S-D convention, although this >>>>>> time zone doesn't observe daylight saving time. >>>>>> >>>>>> >>>>>> + String XJT[] = new String[] {"China Standard Time", "XJT", >>>>>> + "China Daylight Time", "XJDT", >>>>>> + "China Time", "XJT"}; >>>>>> >>>>>> Should the long names be based on Xinjiang? >>>>>> >>>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be >>>>>> the same time zone. >>>>>> >>>>>> - {"America/Metlakatla", new String[] {"Metlakatla >>>>>> Standard Time", "MeST", >>>>>> - "Metlakatla Daylight Time", "MeDT", >>>>>> - "Metlakatla Time", "MeT"}}, >>>>>> + {"America/Metlakatla", new String[] {"Metlakatla >>>>>> Standard Time", "PST", >>>>>> + "Metlakatla Daylight Time", "PDT", >>>>>> + "Metlakatla Time", "PT"}}, >>>>>> >>>>>> - {"Europe/Volgograd", new String[] {"Volgograd Time", >>>>>> "VOLT", >>>>>> - "Volgograd Summer Time", "VOLST", >>>>>> - "Volgograd Time", "VOLT"}}, >>>>>> + {"Europe/Volgograd", new String[] {"Volgograd Time", >>>>>> "MSK", >>>>>> + "Volgograd Summer Time", "MSK", >>>>>> + "Volgograd Time", "MSK"}}, >>>>>> >>>>>> >>>>>> The long names should be changed accordingly. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote: >>>>>>> Masayoshi, >>>>>>> You're right that the "root names" should be changed as part of >>>>>>> this update. The names were changed according to Australian >>>>>>> official document here: >>>>>>> http://australia.gov.au/about-australia/our-country/time >>>>>>> The fixed version of the webrev can be found here: >>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 >>>>>>> >>>>>>> Thanks, >>>>>>> Aleksej >>>>>>> >>>>>>> >>>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: >>>>>>>> We used to make name changes in the root (base) bundle as part >>>>>>>> of time zone data maintenance and deter only translations. But >>>>>>>> if you want to handle name changes later, that would be fine. >>>>>>>> It's your call. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Masayoshi >>>>>>>> >>>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote: >>>>>>>>> Masayoshi, >>>>>>>>> I agree that we should change the long names to match the new >>>>>>>>> short names introduced by tzdata. >>>>>>>>> But I suggest to log a different CR for such activity to >>>>>>>>> handle long name changes and their translations (this activity >>>>>>>>> is slightly out of tzdata update scope). Does it make sense? >>>>>>>>> >>>>>>>>> -Aleksej >>>>>>>>> >>>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote: >>>>>>>>>> I think the long names of the Australia time zones should be >>>>>>>>>> revisited to be consistent with the abbreviation changes. The >>>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] >>>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. >>>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", >>>>>>>>>> no longer make sense. >>>>>>>>>> >>>>>>>>>> On the other hand, you will need to access impact of the name >>>>>>>>>> changes, including abbreviations. Also, if you change the >>>>>>>>>> long names, their translations will need to be changed as well. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Masayoshi >>>>>>>>>> >>>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e >>>>>>>>>>> related changes included too) [1] fix to JDK9: >>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to >>>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time >>>>>>>>>>> zone were added. >>>>>>>>>>> Almost complete list of changes can be found in the JBS bug >>>>>>>>>>> description [1], plus some changes wasn't documented in >>>>>>>>>>> tzdata release notes - for such cases raw tzdata diff was >>>>>>>>>>> used for the names modifications. >>>>>>>>>>> >>>>>>>>>>> Two issues with JSR310 implementation were discovered during >>>>>>>>>>> integration process: >>>>>>>>>>> First issue is related to the internal representation of the >>>>>>>>>>> '24:00' value. The JSR310 implementation treats this value >>>>>>>>>>> as a next day 00:00 time. The workaround already exists in >>>>>>>>>>> JSR310 code for similar entries and this failure is resolved >>>>>>>>>>> in similar way [2] as part of this update. >>>>>>>>>>> For the second issue JDK-8051641 [3] was filled and >>>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only >>>>>>>>>>> one that fails with this tzdata. >>>>>>>>>>> Other time zone related tests [4] passes without failures. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Aleksej >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343 >>>>>>>>>>> [2] >>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch >>>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641 >>>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar >>>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone >>>>>>>>>>> test/java/time\ test/java/util/Formatter >>>>>>>>>>> test/closed/java/util/Calendar test/closed/java/util/TimeZone >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From naoto.sato at oracle.com Mon Sep 8 23:04:57 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 08 Sep 2014 16:04:57 -0700 Subject: [9] RFR: 8057646: ClassCircularityError running SQE test Message-ID: <540E3619.5040101@oracle.com> Hello, Please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8057646 The proposed changes are located at: http://cr.openjdk.java.net/~naoto/8057646/webrev.0/ Naoto From Alan.Bateman at oracle.com Tue Sep 9 07:39:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Sep 2014 08:39:31 +0100 Subject: [9] RFR: 8057646: ClassCircularityError running SQE test In-Reply-To: <540E3619.5040101@oracle.com> References: <540E3619.5040101@oracle.com> Message-ID: <540EAEB3.2030003@oracle.com> On 09/09/2014 00:04, Naoto Sato wrote: > Hello, > > Please review the fix for the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8057646 > > The proposed changes are located at: > > http://cr.openjdk.java.net/~naoto/8057646/webrev.0/ > It's not clear to me that this is the right place to address this issue. Clearly the changes to JRELocaleProviderAdapter to use ServiceLoader have upset the ordering that things are initialized for this error case, but it looks to me that it's always been very fragile. I think we need stack back a bit and examine the stack trace to see where might be a more appropriate place to address this, it may be that the security code needs to be more tolerant of attempts at recursive initialization. -Alan. From naoto.sato at oracle.com Tue Sep 9 17:14:02 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 09 Sep 2014 10:14:02 -0700 Subject: [9] RFR: 8057646: ClassCircularityError running SQE test In-Reply-To: <540EAEB3.2030003@oracle.com> References: <540E3619.5040101@oracle.com> <540EAEB3.2030003@oracle.com> Message-ID: <540F355A.20407@oracle.com> On 9/9/14, 12:39 AM, Alan Bateman wrote: > It's not clear to me that this is the right place to address this issue. > Clearly the changes to JRELocaleProviderAdapter to use ServiceLoader > have upset the ordering that things are initialized for this error case, > but it looks to me that it's always been very fragile. I think we need > stack back a bit and examine the stack trace to see where might be a > more appropriate place to address this, it may be that the security code > needs to be more tolerant of attempts at recursive initialization. It's an inherent issue where some init code issues locale sensitive services, such as in this case, *Formatter. So this could happen not only in Security class, but could be anywhere. So I think we still need the change proposed here in order for avoiding regressions. On error cases, the diagnosability will be addressed with the issue with 8057075. Naoto From Alan.Bateman at oracle.com Tue Sep 9 19:38:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Sep 2014 20:38:10 +0100 Subject: [9] RFR: 8057646: ClassCircularityError running SQE test In-Reply-To: <540F355A.20407@oracle.com> References: <540E3619.5040101@oracle.com> <540EAEB3.2030003@oracle.com> <540F355A.20407@oracle.com> Message-ID: <540F5722.3070404@oracle.com> On 09/09/2014 18:14, Naoto Sato wrote: > > It's an inherent issue where some init code issues locale sensitive > services, such as in this case, *Formatter. So this could happen not > only in Security class, but could be anywhere. So I think we still > need the change proposed here in order for avoiding regressions. On > error cases, the diagnosability will be addressed with the issue with > 8057075. I think we should move this issue to security-libs and have this issue addressed in the PolicyFile/PolicyParser code. My concern with catching Throwable is that it's just going to make it harder to diagnose tricky issues like this. I would be interested in other possible cases where you think the ClassCircularityError might happen. I'm just wondering if we need to approach this issue a bit differently. -Alan From naoto.sato at oracle.com Tue Sep 9 20:46:12 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 09 Sep 2014 13:46:12 -0700 Subject: [9] RFR: 8057646: ClassCircularityError running SQE test In-Reply-To: <540F5722.3070404@oracle.com> References: <540E3619.5040101@oracle.com> <540EAEB3.2030003@oracle.com> <540F355A.20407@oracle.com> <540F5722.3070404@oracle.com> Message-ID: <540F6714.10204@oracle.com> OK. I will transfer the issue to security-libs. Naoto On 9/9/14, 12:38 PM, Alan Bateman wrote: > On 09/09/2014 18:14, Naoto Sato wrote: >> >> It's an inherent issue where some init code issues locale sensitive >> services, such as in this case, *Formatter. So this could happen not >> only in Security class, but could be anywhere. So I think we still >> need the change proposed here in order for avoiding regressions. On >> error cases, the diagnosability will be addressed with the issue with >> 8057075. > I think we should move this issue to security-libs and have this issue > addressed in the PolicyFile/PolicyParser code. > > My concern with catching Throwable is that it's just going to make it > harder to diagnose tricky issues like this. I would be interested in > other possible cases where you think the ClassCircularityError might > happen. I'm just wondering if we need to approach this issue a bit > differently. > > -Alan From aleksej.efimov at oracle.com Fri Sep 12 14:42:17 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 12 Sep 2014 18:42:17 +0400 Subject: [7u-dev] RFA: 8049343: (tz) Support tzdata2014g Message-ID: <54130649.7070200@oracle.com> Hello, Could you, please, approve a backport of tz2014g related changes to JDK7. The backport is not straight-forward one, there is no generic time zone names in JDK7 - because of that the tz names changes slightly differs from JDK8. Also, there was a temporary fix for JSR310 code and test failures in JDK8/9. This changes wasn't applied too - they are not relevant to JDK7. Because of such differences, I assume that its also a subject for review too (adding i18n-dev alias), Performed testing: JPRT testing: No tz related failures were observed in (jdk_util,jdk_other,jdk_text) JTREG testing: test/sun/util/resources/TimeZone test/sun/util/calendar test/closed/java/util/TimeZone test/java/util/TimeZone test/java/util/Calendar test/java/util/Formatter test/sun/util/resources/TimeZone test/closed/java/text/Format/DateFormat Thank you, Aleksej Webrev: http://cr.openjdk.java.net/~aefimov/8049343/7/webrev.00/ JDK9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028467.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f7de7da2eb58 JBS bug: https://bugs.openjdk.java.net/browse/JDK-8049343 From sean.coffey at oracle.com Fri Sep 12 15:22:14 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 12 Sep 2014 16:22:14 +0100 Subject: [7u-dev] RFA: 8049343: (tz) Support tzdata2014g In-Reply-To: <54130649.7070200@oracle.com> References: <54130649.7070200@oracle.com> Message-ID: <54130FA6.2080304@oracle.com> Please get a reviewer to review the JDK7u changes. Approved but subject to review. regards, Sean. On 12/09/14 15:42, Aleksej Efimov wrote: > Hello, > > Could you, please, approve a backport of tz2014g related changes to > JDK7. The backport is not straight-forward one, there is no generic > time zone names in JDK7 - because of that the tz names changes > slightly differs from JDK8. > Also, there was a temporary fix for JSR310 code and test failures in > JDK8/9. This changes wasn't applied too - they are not relevant to JDK7. > Because of such differences, I assume that its also a subject for > review too (adding i18n-dev alias), > > Performed testing: > JPRT testing: No tz related failures were observed in > (jdk_util,jdk_other,jdk_text) > JTREG testing: test/sun/util/resources/TimeZone test/sun/util/calendar > test/closed/java/util/TimeZone test/java/util/TimeZone > test/java/util/Calendar > test/java/util/Formatter test/sun/util/resources/TimeZone > test/closed/java/text/Format/DateFormat > > Thank you, > Aleksej > > Webrev: http://cr.openjdk.java.net/~aefimov/8049343/7/webrev.00/ > JDK9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028467.html > > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f7de7da2eb58 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8049343 > From y.umaoka at gmail.com Mon Sep 15 19:24:09 2014 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Mon, 15 Sep 2014 15:24:09 -0400 Subject: TimeZone#setRawOffset problem? Message-ID: <54173CD9.6010409@gmail.com> Hello, I found some test cases in our project started failing after updating JRE's tzdata version to 2014g. The test case creates a new TimeZone, and modify the raw offset. I know it's ancient API before Java implemented tz database, and I know the functionality is somewhat moot at this point. However, it looks the problem was introduced recently - I thought it worked OK a few months ago (but I'm not 100% sure). Java version: java version "1.7.0_67" Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) TZ database version: 2014g Simple test code: for (String id : TimeZone.getAvailableIDs()) { TimeZone tz = TimeZone.getTimeZone(id); int orgOffset = tz.getRawOffset(); // Update raw offset : + 30 minutes int newOffset = orgOffset + 30*60*1000; tz.setRawOffset(newOffset); int actualOffset = tz.getRawOffset(); if (actualOffset != newOffset) { System.out.println(id + " [org=" + orgOffset + ", new=" + newOffset + ", actual=" + actualOffset + "]"); } } Output: Asia/Yakutsk [org=36000000, new=37800000, actual=41400000] Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000] Europe/Volgograd [org=14400000, new=16200000, actual=19800000] Asia/Magadan [org=43200000, new=45000000, actual=52200000] Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000] Asia/Khandyga [org=36000000, new=37800000, actual=41400000] Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000] Asia/Vladivostok [org=39600000, new=41400000, actual=45000000] Europe/Simferopol [org=14400000, new=16200000, actual=19800000] Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000] Asia/Omsk [org=25200000, new=27000000, actual=30600000] Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000] Asia/Sakhalin [org=39600000, new=41400000, actual=45000000] Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000] Asia/Chita [org=36000000, new=37800000, actual=45000000] Asia/Irkutsk [org=32400000, new=34200000, actual=37800000] Europe/Moscow [org=14400000, new=16200000, actual=19800000] America/Grand_Turk [org=-18000000, new=-16200000, actual=-19800000] W-SU [org=14400000, new=16200000, actual=19800000] If my understanding is correct, the standard offset of these zones will change later in this year. Should I go ahead and file a bug? -Yoshito From aleksej.efimov at oracle.com Mon Sep 15 20:04:48 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 16 Sep 2014 00:04:48 +0400 Subject: TimeZone#setRawOffset problem? In-Reply-To: <54173CD9.6010409@gmail.com> References: <54173CD9.6010409@gmail.com> Message-ID: <54174660.4010100@oracle.com> Hello Yoshito, Correct - the standard offsets of these timezones will change later this year, for example "Asia/Yakutsk" (it's a part of tz db that will be soon in JDK7 [1], and the one you had after running a tzupdater): 2631 Zone Asia/Yakutsk 8:38:58 - LMT 1919 Dec 15 2632 8:00 - YAKT 1930 Jun 21 # Yakutsk Time 2633 9:00 Russia YAK%sT 1991 Mar 31 2:00s 2634 8:00 Russia YAK%sT 1992 Jan 19 2:00s 2635 9:00 Russia YAK%sT 2011 Mar 27 2:00s *2636 10:00 - YAKT 2014 Oct 26 2:00s* 2637 9:00 - YAKT Same picture for "Asia/Magadan": 2717 Zone Asia/Magadan 10:03:12 - LMT 1924 May 2 2718 10:00 - MAGT 1930 Jun 21 # Magadan Time 2719 11:00 Russia MAG%sT 1991 Mar 31 2:00s 2720 10:00 Russia MAG%sT 1992 Jan 19 2:00s 2721 11:00 Russia MAG%sT 2011 Mar 27 2:00s *2722 12:00 - MAGT 2014 Oct 26 2:00s * And "Europe/Moscow" and etc: 2335 Zone Europe/Moscow 2:30:17 - LMT 1880 2336 2:30:17 - MMT 1916 Jul 3 # Moscow Mean Time 2337 2:31:19 Russia %s 1919 Jul 1 2:00 2338 3:00 Russia %s 1921 Oct 2339 3:00 Russia MSK/MSD 1922 Oct 2340 2:00 - EET 1930 Jun 21 2341 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 2342 2:00 Russia EE%sT 1992 Jan 19 2:00s 2343 3:00 Russia MSK/MSD 2011 Mar 27 2:00s *2344 4:00 - MSK 2014 Oct 26 2:00s* 2345 3:00 - MSK The results you're observing looks correct. Best Regards, Aleksej [1] http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html On 09/15/2014 11:24 PM, Yoshito Umaoka wrote: > Hello, > > I found some test cases in our project started failing after updating > JRE's tzdata version to 2014g. The test case creates a new TimeZone, > and modify the raw offset. I know it's ancient API before Java > implemented tz database, and I know the functionality is somewhat moot > at this point. However, it looks the problem was introduced recently - > I thought it worked OK a few months ago (but I'm not 100% sure). > > Java version: > > java version "1.7.0_67" > Java(TM) SE Runtime Environment (build 1.7.0_67-b01) > Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) > > TZ database version: 2014g > > Simple test code: > > for (String id : TimeZone.getAvailableIDs()) { > TimeZone tz = TimeZone.getTimeZone(id); > > int orgOffset = tz.getRawOffset(); > > // Update raw offset : + 30 minutes > int newOffset = orgOffset + 30*60*1000; > tz.setRawOffset(newOffset); > > int actualOffset = tz.getRawOffset(); > > if (actualOffset != newOffset) { > System.out.println(id + " [org=" + orgOffset > + ", new=" + newOffset > + ", actual=" + actualOffset + "]"); > } > } > > Output: > > Asia/Yakutsk [org=36000000, new=37800000, actual=41400000] > Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000] > Europe/Volgograd [org=14400000, new=16200000, actual=19800000] > Asia/Magadan [org=43200000, new=45000000, actual=52200000] > Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000] > Asia/Khandyga [org=36000000, new=37800000, actual=41400000] > Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000] > Asia/Vladivostok [org=39600000, new=41400000, actual=45000000] > Europe/Simferopol [org=14400000, new=16200000, actual=19800000] > Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000] > Asia/Omsk [org=25200000, new=27000000, actual=30600000] > Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000] > Asia/Sakhalin [org=39600000, new=41400000, actual=45000000] > Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000] > Asia/Chita [org=36000000, new=37800000, actual=45000000] > Asia/Irkutsk [org=32400000, new=34200000, actual=37800000] > Europe/Moscow [org=14400000, new=16200000, actual=19800000] > America/Grand_Turk [org=-18000000, new=-16200000, actual=-19800000] > W-SU [org=14400000, new=16200000, actual=19800000] > > > If my understanding is correct, the standard offset of these zones > will change later in this year. > > Should I go ahead and file a bug? > > -Yoshito > From y.umaoka at gmail.com Mon Sep 15 20:45:03 2014 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Mon, 15 Sep 2014 16:45:03 -0400 Subject: TimeZone#setRawOffset problem? In-Reply-To: <54174660.4010100@oracle.com> References: <54173CD9.6010409@gmail.com> <54174660.4010100@oracle.com> Message-ID: <54174FCF.40003@gmail.com> Hi Aleksej, >The results you're observing looks correct. I assume you actually meant: - Java has a bug, returning the incorrect result with my simple test program. - My observation of time zones causing the issue (the zones changing standard offset later in this year) is correct. Right? I know setting a different offset to a TimeZone created for an zone ID, is bogus. But, getRawOffset() should return what you set by setRawOffset(int) - which is not the case for these zones. For example, when you call tz.setRawOffset(37800000), then tz.getRawOffset() should return 37800000, not 41400000. Yoshito On 9/15/2014 4:04 PM, Aleksej Efimov wrote: > Hello Yoshito, > > Correct - the standard offsets of these timezones will change later > this year, for example "Asia/Yakutsk" (it's a part of tz db that will > be soon in JDK7 [1], and the one you had after running a tzupdater): > 2631 Zone Asia/Yakutsk 8:38:58 - LMT 1919 Dec 15 > 2632 8:00 - YAKT 1930 Jun 21 # Yakutsk Time > 2633 9:00 Russia YAK%sT 1991 Mar 31 2:00s > 2634 8:00 Russia YAK%sT 1992 Jan 19 2:00s > 2635 9:00 Russia YAK%sT 2011 Mar 27 2:00s > *2636 10:00 - YAKT 2014 Oct 26 2:00s* > 2637 9:00 - YAKT > Same picture for "Asia/Magadan": > 2717 Zone Asia/Magadan 10:03:12 - LMT 1924 May 2 > 2718 10:00 - MAGT 1930 Jun 21 # Magadan Time > 2719 11:00 Russia MAG%sT 1991 Mar 31 2:00s > 2720 10:00 Russia MAG%sT 1992 Jan 19 2:00s > 2721 11:00 Russia MAG%sT 2011 Mar 27 2:00s > *2722 12:00 - MAGT 2014 Oct 26 2:00s > > * > And "Europe/Moscow" and etc: > 2335 Zone Europe/Moscow 2:30:17 - LMT 1880 > 2336 2:30:17 - MMT 1916 Jul 3 # Moscow Mean Time > 2337 2:31:19 Russia %s 1919 Jul 1 2:00 > 2338 3:00 Russia %s 1921 Oct > 2339 3:00 Russia MSK/MSD 1922 Oct > 2340 2:00 - EET 1930 Jun 21 > 2341 3:00 Russia MSK/MSD 1991 Mar 31 2:00s > 2342 2:00 Russia EE%sT 1992 Jan 19 2:00s > 2343 3:00 Russia MSK/MSD 2011 Mar 27 2:00s > *2344 4:00 - MSK 2014 Oct 26 2:00s* > 2345 3:00 - MSK > > The results you're observing looks correct. > > Best Regards, > Aleksej > > [1] > http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html > > On 09/15/2014 11:24 PM, Yoshito Umaoka wrote: >> Hello, >> >> I found some test cases in our project started failing after updating >> JRE's tzdata version to 2014g. The test case creates a new TimeZone, >> and modify the raw offset. I know it's ancient API before Java >> implemented tz database, and I know the functionality is somewhat >> moot at this point. However, it looks the problem was introduced >> recently - I thought it worked OK a few months ago (but I'm not 100% >> sure). >> >> Java version: >> >> java version "1.7.0_67" >> Java(TM) SE Runtime Environment (build 1.7.0_67-b01) >> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) >> >> TZ database version: 2014g >> >> Simple test code: >> >> for (String id : TimeZone.getAvailableIDs()) { >> TimeZone tz = TimeZone.getTimeZone(id); >> >> int orgOffset = tz.getRawOffset(); >> >> // Update raw offset : + 30 minutes >> int newOffset = orgOffset + 30*60*1000; >> tz.setRawOffset(newOffset); >> >> int actualOffset = tz.getRawOffset(); >> >> if (actualOffset != newOffset) { >> System.out.println(id + " [org=" + orgOffset >> + ", new=" + newOffset >> + ", actual=" + actualOffset + "]"); >> } >> } >> >> Output: >> >> Asia/Yakutsk [org=36000000, new=37800000, actual=41400000] >> Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000] >> Europe/Volgograd [org=14400000, new=16200000, actual=19800000] >> Asia/Magadan [org=43200000, new=45000000, actual=52200000] >> Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000] >> Asia/Khandyga [org=36000000, new=37800000, actual=41400000] >> Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000] >> Asia/Vladivostok [org=39600000, new=41400000, actual=45000000] >> Europe/Simferopol [org=14400000, new=16200000, actual=19800000] >> Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000] >> Asia/Omsk [org=25200000, new=27000000, actual=30600000] >> Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000] >> Asia/Sakhalin [org=39600000, new=41400000, actual=45000000] >> Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000] >> Asia/Chita [org=36000000, new=37800000, actual=45000000] >> Asia/Irkutsk [org=32400000, new=34200000, actual=37800000] >> Europe/Moscow [org=14400000, new=16200000, actual=19800000] >> America/Grand_Turk [org=-18000000, new=-16200000, actual=-19800000] >> W-SU [org=14400000, new=16200000, actual=19800000] >> >> >> If my understanding is correct, the standard offset of these zones >> will change later in this year. >> >> Should I go ahead and file a bug? >> >> -Yoshito >> > From aleksej.efimov at oracle.com Mon Sep 15 21:59:24 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 15 Sep 2014 14:59:24 -0700 (PDT) Subject: TimeZone#setRawOffset problem? Message-ID: <44f47112-137c-4675-9aae-8c5fe753c77b@default> Yoshito, I can explain such behavior only by this part of javadoc + some calculations: Let's select the Asia/Yakutsk (please, refer to tzdb rules in previous e-mail) as an example. The 'setRawOffset' javadoc [1] says the following: "If an underlying TimeZone implementation subclass supports historical GMT offset changes, the specified GMT offset is set as the latest GMT offset and the difference from the known latest GMT offset value is used to adjust all historical GMT offset values." The latest known GMT offset is: 9:00 = 32400 (let's count in seconds) New raw offset value (the value set by your test program): 37800 The difference from the known latest GMT offset value: 37800 - 32400 = 5400 Current DST offset (10:00 = 36000 ) is adjusted with this constant: 36000 + 5400 = 41400 Please, note that the 37800 is set as a last GMT offset and it will take effect only on "2014 Oct 26". Other historical offsets will be corrected with difference between latest tzdb offset and new offset value = 5400. I think everything works as expected and not sure if it is a JDK bug, maybe unclear documentation or something else. -Aleksej [1] http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#setRawOffset(int)
----- Original Message -----
From: y.umaoka at gmail.com
To: aleksej.efimov at oracle.com
Cc: i18n-dev at openjdk.java.net
Sent: Tuesday, September 16, 2014 12:45:21 AM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: <i18n dev> TimeZone#setRawOffset problem?

Hi Aleksej,

>The results you're observing looks correct.

I assume you actually meant:

- Java has a bug, returning the incorrect result with my simple test program.
- My observation of time zones causing the issue (the zones changing standard offset later in this year) is correct.

Right?
I know setting a different offset to a TimeZone created for an zone ID, is bogus. But, getRawOffset() should return what you set by setRawOffset(int) - which is not the case for these zones. For example, when you call tz.setRawOffset(37800000), then tz.getRawOffset() should return 37800000, not 41400000.

Yoshito

On 9/15/2014 4:04 PM, Aleksej Efimov wrote:
Hello Yoshito,

Correct - the standard offsets of these timezones will change later this year, for example "Asia/Yakutsk" (it's a part of tz db that will be soon in JDK7 [1], and the one you had after running a tzupdater):
2631 Zone Asia/Yakutsk        8:38:58 -      LMT     1919 Dec 15
2632                          8:00   -       YAKT    1930 Jun 21 # Yakutsk Time
2633                          9:00   Russia  YAK%sT  1991 Mar 31  2:00s
2634                          8:00   Russia  YAK%sT  1992 Jan 19  2:00s
2635                          9:00   Russia  YAK%sT  2011 Mar 27  2:00s
2636                         10:00   -       YAKT    2014 Oct 26  2:00s
2637                          9:00   -       YAKT
Same picture for "Asia/Magadan":
2717 Zone Asia/Magadan       10:03:12 -      LMT     1924 May  2
2718                         10:00   -       MAGT    1930 Jun 21 # Magadan Time
2719                         11:00   Russia  MAG%sT  1991 Mar 31  2:00s
2720                         10:00   Russia  MAG%sT  1992 Jan 19  2:00s
2721                         11:00   Russia  MAG%sT  2011 Mar 27  2:00s
2722                         12:00   -       MAGT    2014 Oct 26  2:00s

And "Europe/Moscow" and etc:
2335 Zone Europe/Moscow       2:30:17 -      LMT     1880
2336                          2:30:17 -      MMT     1916 Jul  3 # Moscow Mean Time
2337                          2:31:19 Russia %s      1919 Jul  1  2:00
2338                          3:00   Russia  %s      1921 Oct
2339                          3:00   Russia  MSK/MSD 1922 Oct
2340                          2:00   -       EET     1930 Jun 21
2341                          3:00   Russia  MSK/MSD 1991 Mar 31  2:00s
2342                          2:00   Russia  EE%sT   1992 Jan 19  2:00s
2343                          3:00   Russia  MSK/MSD 2011 Mar 27  2:00s
2344                          4:00   -       MSK     2014 Oct 26  2:00s
2345                          3:00   -       MSK

The results you're observing looks correct.

Best Regards,
Aleksej

[1] http://mail.openjdk.java.net/pipermail/i18n-dev/2014-September/001511.html

On 09/15/2014 11:24 PM, Yoshito Umaoka wrote:
Hello,

I found some test cases in our project started failing after updating JRE's tzdata version to 2014g. The test case creates a new TimeZone, and modify the raw offset. I know it's ancient API before Java implemented tz database, and I know the functionality is somewhat moot at this point. However, it looks the problem was introduced recently - I thought it worked OK a few months ago (but I'm not 100% sure).

Java version:

java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

TZ database version: 2014g

Simple test code:

        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone tz = TimeZone.getTimeZone(id);

            int orgOffset = tz.getRawOffset();

            // Update raw offset : + 30 minutes
            int newOffset = orgOffset + 30*60*1000;
            tz.setRawOffset(newOffset);

            int actualOffset = tz.getRawOffset();

            if (actualOffset != newOffset) {
                System.out.println(id + " [org=" + orgOffset
                        + ", new=" + newOffset
                        + ", actual=" + actualOffset + "]");
            }
        }

Output:

Asia/Yakutsk [org=36000000, new=37800000, actual=41400000]
Europe/Kaliningrad [org=10800000, new=12600000, actual=16200000]
Europe/Volgograd [org=14400000, new=16200000, actual=19800000]
Asia/Magadan [org=43200000, new=45000000, actual=52200000]
Asia/Srednekolymsk [org=43200000, new=45000000, actual=48600000]
Asia/Khandyga [org=36000000, new=37800000, actual=41400000]
Asia/Yekaterinburg [org=21600000, new=23400000, actual=27000000]
Asia/Vladivostok [org=39600000, new=41400000, actual=45000000]
Europe/Simferopol [org=14400000, new=16200000, actual=19800000]
Asia/Ust-Nera [org=39600000, new=41400000, actual=45000000]
Asia/Omsk [org=25200000, new=27000000, actual=30600000]
Asia/Novosibirsk [org=25200000, new=27000000, actual=30600000]
Asia/Sakhalin [org=39600000, new=41400000, actual=45000000]
Asia/Krasnoyarsk [org=28800000, new=30600000, actual=34200000]
Asia/Chita [org=36000000, new=37800000, actual=45000000]
Asia/Irkutsk [org=32400000, new=34200000, actual=37800000]
Europe/Moscow [org=14400000, new=16200000, actual=19800000]
America/Grand_Turk [org=-18000000, new=-16200000, actual=-19800000]
W-SU [org=14400000, new=16200000, actual=19800000]


If my understanding is correct, the standard offset of these zones will change later in this year.

Should I go ahead and file a bug?

-Yoshito



From naoto.sato at oracle.com Mon Sep 15 23:30:25 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 15 Sep 2014 16:30:25 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata Message-ID: <54177691.5030801@oracle.com> Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8058509 The webrev is located at: http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ The fix is intended to move the LocaleDataMetaInfo of CLDR from java.base module to jdk.localedata module, along with CLDR's "en" locale data and the package name change to avoid the "split package" in two modules. Naoto From mandy.chung at oracle.com Tue Sep 16 01:11:07 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Sep 2014 18:11:07 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54177691.5030801@oracle.com> References: <54177691.5030801@oracle.com> Message-ID: <54178E2B.8000804@oracle.com> On 9/15/2014 4:30 PM, Naoto Sato wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8058509 > > The webrev is located at: > > http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ > > The fix is intended to move the LocaleDataMetaInfo of CLDR from > java.base module to jdk.localedata module, along with CLDR's "en" > locale data and the package name change to avoid the "split package" > in two modules. Should CLDR's en locale data be available when cldrdata.jar is not present? Mandy From y.umaoka at gmail.com Tue Sep 16 07:11:49 2014 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 16 Sep 2014 03:11:49 -0400 Subject: TimeZone#setRawOffset problem? In-Reply-To: <44f47112-137c-4675-9aae-8c5fe753c77b@default> References: <44f47112-137c-4675-9aae-8c5fe753c77b@default> Message-ID: <5417E2B5.7050003@gmail.com> On 9/15/2014 5:59 PM, Aleksej Efimov wrote: > Yoshito, I can explain such behavior only by this part of javadoc + > some calculations: Let's select the Asia/Yakutsk (please, refer to > tzdb rules in previous e-mail) as an example. The 'setRawOffset' > javadoc [1] says the following: "If an underlying TimeZone > implementation subclass supports historical GMT offset changes, the > specified GMT offset is set as the latest GMT offset and the > difference from the known latest GMT offset value is used to adjust > all historical GMT offset values." The latest known GMT offset is: > 9:00 = 32400 (let's count in seconds) New raw offset value (the value > set by your test program): 37800 The difference from the known latest > GMT offset value: 37800 - 32400 = 5400 Current DST offset (10:00 = > 36000 ) is adjusted with this constant: 36000 + 5400 = 41400 Please, > note that the 37800 is set as a last GMT offset and it will take > effect only on "2014 Oct 26". Other historical offsets will be > corrected with difference between latest tzdb offset and new offset > value = 5400. I think everything works as expected and not sure if it > is a JDK bug, maybe unclear documentation or something else. -Aleksej > [1] > http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#setRawOffset(int) Thanks for clarification. I would say the document simply spelled out the existing implementation's behavior (, and not what it should behave)... Anyway, it's not a critical problem - I even think the method (setRawOffset) should be harmful and deprecated. (BTW, if this is the case, setRawOffset(int) only updates the base offset of date after year 2037 for some Brazilian zones?) -Yoshito From erik.joelsson at oracle.com Tue Sep 16 07:41:16 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 16 Sep 2014 09:41:16 +0200 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54177691.5030801@oracle.com> References: <54177691.5030801@oracle.com> Message-ID: <5417E99C.1030502@oracle.com> Hello Naoto, From what I can see, this means that GensrcCLDR.gmk now only generates source for the jdk.localedata module. This means that Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and GensrcCLDR.gmk should be renamed to Gensrc-jdk.localedata.gmk. /Erik On 2014-09-16 01:30, Naoto Sato wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8058509 > > The webrev is located at: > > http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ > > The fix is intended to move the LocaleDataMetaInfo of CLDR from > java.base module to jdk.localedata module, along with CLDR's "en" > locale data and the package name change to avoid the "split package" > in two modules. > > Naoto From masayoshi.okutsu at oracle.com Tue Sep 16 09:10:44 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 16 Sep 2014 18:10:44 +0900 Subject: [7u-dev] RFA: 8049343: (tz) Support tzdata2014g In-Reply-To: <54130649.7070200@oracle.com> References: <54130649.7070200@oracle.com> Message-ID: <5417FE94.5050703@oracle.com> Looks good to me. Thanks, Masayoshi On 9/12/2014 11:42 PM, Aleksej Efimov wrote: > Hello, > > Could you, please, approve a backport of tz2014g related changes to > JDK7. The backport is not straight-forward one, there is no generic > time zone names in JDK7 - because of that the tz names changes > slightly differs from JDK8. > Also, there was a temporary fix for JSR310 code and test failures in > JDK8/9. This changes wasn't applied too - they are not relevant to JDK7. > Because of such differences, I assume that its also a subject for > review too (adding i18n-dev alias), > > Performed testing: > JPRT testing: No tz related failures were observed in > (jdk_util,jdk_other,jdk_text) > JTREG testing: test/sun/util/resources/TimeZone test/sun/util/calendar > test/closed/java/util/TimeZone test/java/util/TimeZone > test/java/util/Calendar > test/java/util/Formatter test/sun/util/resources/TimeZone > test/closed/java/text/Format/DateFormat > > Thank you, > Aleksej > > Webrev: http://cr.openjdk.java.net/~aefimov/8049343/7/webrev.00/ > JDK9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028467.html > > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f7de7da2eb58 > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8049343 > From magnus.ihse.bursie at oracle.com Tue Sep 16 09:49:14 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Sep 2014 11:49:14 +0200 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <5417E99C.1030502@oracle.com> References: <54177691.5030801@oracle.com> <5417E99C.1030502@oracle.com> Message-ID: <5418079A.5090805@oracle.com> On 2014-09-16 09:41, Erik Joelsson wrote: > Hello Naoto, > > From what I can see, this means that GensrcCLDR.gmk now only generates > source for the jdk.localedata module. This means that > Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and > GensrcCLDR.gmk should be renamed to Gensrc-jdk.localedata.gmk. Just changing names is not enough, you need to add a new target as well, and remove the GENSRC_JAVA_BASE assignment. See e.g. Gensrc-java.desktop.gmk for inspiration. /Magnus From naoto.sato at oracle.com Tue Sep 16 16:30:09 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Sep 2014 09:30:09 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54178E2B.8000804@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> Message-ID: <54186591.6050408@oracle.com> CLDR's data is accessible only when cldrdata.jar is available, including their "en" resources. There is no need to put their "en" resources in java.base. Naoto On 9/15/14, 6:11 PM, Mandy Chung wrote: > > On 9/15/2014 4:30 PM, Naoto Sato wrote: >> Hello, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8058509 >> >> The webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >> >> The fix is intended to move the LocaleDataMetaInfo of CLDR from >> java.base module to jdk.localedata module, along with CLDR's "en" >> locale data and the package name change to avoid the "split package" >> in two modules. > > Should CLDR's en locale data be available when cldrdata.jar is not present? > > Mandy > From naoto.sato at oracle.com Tue Sep 16 16:30:57 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Sep 2014 09:30:57 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <5418079A.5090805@oracle.com> References: <54177691.5030801@oracle.com> <5417E99C.1030502@oracle.com> <5418079A.5090805@oracle.com> Message-ID: <541865C1.2090604@oracle.com> Thanks, Erik and Magnus. Will take a look and revise the fix. Naoto On 9/16/14, 2:49 AM, Magnus Ihse Bursie wrote: > On 2014-09-16 09:41, Erik Joelsson wrote: >> Hello Naoto, >> >> From what I can see, this means that GensrcCLDR.gmk now only generates >> source for the jdk.localedata module. This means that >> Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and >> GensrcCLDR.gmk should be renamed to Gensrc-jdk.localedata.gmk. > > Just changing names is not enough, you need to add a new target as well, > and remove the GENSRC_JAVA_BASE assignment. See e.g. > Gensrc-java.desktop.gmk for inspiration. > > /Magnus > From mandy.chung at oracle.com Tue Sep 16 16:50:53 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Sep 2014 09:50:53 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54186591.6050408@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> <54186591.6050408@oracle.com> Message-ID: <54186A6D.50908@oracle.com> At one point you mention that CLDR will become the default in JDK 9. Would you need to move them back to java.base when it becomes the default? Mandy On 9/16/14 9:30 AM, Naoto Sato wrote: > CLDR's data is accessible only when cldrdata.jar is available, > including their "en" resources. There is no need to put their "en" > resources in java.base. > > Naoto > > On 9/15/14, 6:11 PM, Mandy Chung wrote: >> >> On 9/15/2014 4:30 PM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8058509 >>> >>> The webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >>> >>> The fix is intended to move the LocaleDataMetaInfo of CLDR from >>> java.base module to jdk.localedata module, along with CLDR's "en" >>> locale data and the package name change to avoid the "split package" >>> in two modules. >> >> Should CLDR's en locale data be available when cldrdata.jar is not >> present? >> >> Mandy >> From naoto.sato at oracle.com Tue Sep 16 16:57:38 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Sep 2014 09:57:38 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54186A6D.50908@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> <54186591.6050408@oracle.com> <54186A6D.50908@oracle.com> Message-ID: <54186C02.6080907@oracle.com> Yes, the current plan is to make the CLDR's data the default one, only when it is available. Requiring it in the java.base would be problematic for smaller environments. This will be addressed in 8008577. Naoto On 9/16/14, 9:50 AM, Mandy Chung wrote: > At one point you mention that CLDR will become the default in JDK 9. > Would you need to move them back to java.base when it becomes the default? > > Mandy > > On 9/16/14 9:30 AM, Naoto Sato wrote: >> CLDR's data is accessible only when cldrdata.jar is available, >> including their "en" resources. There is no need to put their "en" >> resources in java.base. >> >> Naoto >> >> On 9/15/14, 6:11 PM, Mandy Chung wrote: >>> >>> On 9/15/2014 4:30 PM, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the fix for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8058509 >>>> >>>> The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >>>> >>>> The fix is intended to move the LocaleDataMetaInfo of CLDR from >>>> java.base module to jdk.localedata module, along with CLDR's "en" >>>> locale data and the package name change to avoid the "split package" >>>> in two modules. >>> >>> Should CLDR's en locale data be available when cldrdata.jar is not >>> present? >>> >>> Mandy >>> > From naoto.sato at oracle.com Tue Sep 16 21:03:31 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Sep 2014 14:03:31 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54177691.5030801@oracle.com> References: <54177691.5030801@oracle.com> Message-ID: <5418A5A3.6030403@oracle.com> I revised the fix based on suggestions from Erik/Magnus. I just ended up creating Gensrc-jdk.localedata.gmk, instead of renaming GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly GensrcLocaleDataMetaInfo.gmk) is also needed to build jdk.localedata: http://cr.openjdk.java.net/~naoto/8058509/webrev.1/ Please review. Naoto On 9/15/14, 4:30 PM, Naoto Sato wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8058509 > > The webrev is located at: > > http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ > > The fix is intended to move the LocaleDataMetaInfo of CLDR from > java.base module to jdk.localedata module, along with CLDR's "en" locale > data and the package name change to avoid the "split package" in two > modules. > > Naoto From mandy.chung at oracle.com Tue Sep 16 21:09:01 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Sep 2014 14:09:01 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54186C02.6080907@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> <54186591.6050408@oracle.com> <54186A6D.50908@oracle.com> <54186C02.6080907@oracle.com> Message-ID: <5418A6ED.6030402@oracle.com> On 9/16/14 9:57 AM, Naoto Sato wrote: > Yes, the current plan is to make the CLDR's data the default one, only > when it is available. Requiring it in the java.base would be > problematic for smaller environments. This will be addressed in 8008577. Do you mean the EN cldr data is big? Mandy > > Naoto > > On 9/16/14, 9:50 AM, Mandy Chung wrote: >> At one point you mention that CLDR will become the default in JDK 9. >> Would you need to move them back to java.base when it becomes the >> default? >> >> Mandy >> >> On 9/16/14 9:30 AM, Naoto Sato wrote: >>> CLDR's data is accessible only when cldrdata.jar is available, >>> including their "en" resources. There is no need to put their "en" >>> resources in java.base. >>> >>> Naoto >>> >>> On 9/15/14, 6:11 PM, Mandy Chung wrote: >>>> >>>> On 9/15/2014 4:30 PM, Naoto Sato wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8058509 >>>>> >>>>> The webrev is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >>>>> >>>>> The fix is intended to move the LocaleDataMetaInfo of CLDR from >>>>> java.base module to jdk.localedata module, along with CLDR's "en" >>>>> locale data and the package name change to avoid the "split package" >>>>> in two modules. >>>> >>>> Should CLDR's en locale data be available when cldrdata.jar is not >>>> present? >>>> >>>> Mandy >>>> >> From naoto.sato at oracle.com Tue Sep 16 21:39:00 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Sep 2014 14:39:00 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <5418A6ED.6030402@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> <54186591.6050408@oracle.com> <54186A6D.50908@oracle.com> <54186C02.6080907@oracle.com> <5418A6ED.6030402@oracle.com> Message-ID: <5418ADF4.9000406@oracle.com> No. But I suppose smaller environments would just need JRE's locale data only. Including even some portion of CLDR locale data in java.base would make it not possible for them to jrecreate the image without CLDR. Naoto On 9/16/14, 2:09 PM, Mandy Chung wrote: > On 9/16/14 9:57 AM, Naoto Sato wrote: >> Yes, the current plan is to make the CLDR's data the default one, only >> when it is available. Requiring it in the java.base would be >> problematic for smaller environments. This will be addressed in 8008577. > > Do you mean the EN cldr data is big? > > Mandy > >> >> Naoto >> >> On 9/16/14, 9:50 AM, Mandy Chung wrote: >>> At one point you mention that CLDR will become the default in JDK 9. >>> Would you need to move them back to java.base when it becomes the >>> default? >>> >>> Mandy >>> >>> On 9/16/14 9:30 AM, Naoto Sato wrote: >>>> CLDR's data is accessible only when cldrdata.jar is available, >>>> including their "en" resources. There is no need to put their "en" >>>> resources in java.base. >>>> >>>> Naoto >>>> >>>> On 9/15/14, 6:11 PM, Mandy Chung wrote: >>>>> >>>>> On 9/15/2014 4:30 PM, Naoto Sato wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix for the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8058509 >>>>>> >>>>>> The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >>>>>> >>>>>> The fix is intended to move the LocaleDataMetaInfo of CLDR from >>>>>> java.base module to jdk.localedata module, along with CLDR's "en" >>>>>> locale data and the package name change to avoid the "split package" >>>>>> in two modules. >>>>> >>>>> Should CLDR's en locale data be available when cldrdata.jar is not >>>>> present? >>>>> >>>>> Mandy >>>>> >>> > From mandy.chung at oracle.com Tue Sep 16 21:47:39 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Sep 2014 14:47:39 -0700 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <5418ADF4.9000406@oracle.com> References: <54177691.5030801@oracle.com> <54178E2B.8000804@oracle.com> <54186591.6050408@oracle.com> <54186A6D.50908@oracle.com> <54186C02.6080907@oracle.com> <5418A6ED.6030402@oracle.com> <5418ADF4.9000406@oracle.com> Message-ID: <5418AFFB.5090003@oracle.com> It's okay then and 8008577 will address this properly. This revised webrev looks okay to me. > http://cr.openjdk.java.net/~naoto/8058509/webrev.1/ Mandy On 9/16/14 2:39 PM, Naoto Sato wrote: > No. But I suppose smaller environments would just need JRE's locale > data only. Including even some portion of CLDR locale data in > java.base would make it not possible for them to jrecreate the image > without CLDR. > > Naoto > > On 9/16/14, 2:09 PM, Mandy Chung wrote: >> On 9/16/14 9:57 AM, Naoto Sato wrote: >>> Yes, the current plan is to make the CLDR's data the default one, only >>> when it is available. Requiring it in the java.base would be >>> problematic for smaller environments. This will be addressed in >>> 8008577. >> >> Do you mean the EN cldr data is big? >> >> Mandy >> >>> >>> Naoto >>> >>> On 9/16/14, 9:50 AM, Mandy Chung wrote: >>>> At one point you mention that CLDR will become the default in JDK 9. >>>> Would you need to move them back to java.base when it becomes the >>>> default? >>>> >>>> Mandy >>>> >>>> On 9/16/14 9:30 AM, Naoto Sato wrote: >>>>> CLDR's data is accessible only when cldrdata.jar is available, >>>>> including their "en" resources. There is no need to put their "en" >>>>> resources in java.base. >>>>> >>>>> Naoto >>>>> >>>>> On 9/15/14, 6:11 PM, Mandy Chung wrote: >>>>>> >>>>>> On 9/15/2014 4:30 PM, Naoto Sato wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the fix for the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8058509 >>>>>>> >>>>>>> The webrev is located at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >>>>>>> >>>>>>> The fix is intended to move the LocaleDataMetaInfo of CLDR from >>>>>>> java.base module to jdk.localedata module, along with CLDR's "en" >>>>>>> locale data and the package name change to avoid the "split >>>>>>> package" >>>>>>> in two modules. >>>>>> >>>>>> Should CLDR's en locale data be available when cldrdata.jar is not >>>>>> present? >>>>>> >>>>>> Mandy >>>>>> >>>> >> From erik.joelsson at oracle.com Wed Sep 17 09:36:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Sep 2014 11:36:24 +0200 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <5418A5A3.6030403@oracle.com> References: <54177691.5030801@oracle.com> <5418A5A3.6030403@oracle.com> Message-ID: <54195618.9050308@oracle.com> On 2014-09-16 23:03, Naoto Sato wrote: > I revised the fix based on suggestions from Erik/Magnus. I just ended > up creating Gensrc-jdk.localedata.gmk, instead of renaming > GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly > GensrcLocaleDataMetaInfo.gmk) is also needed to build jdk.localedata: > > http://cr.openjdk.java.net/~naoto/8058509/webrev.1/ > Right, you were able to separate the work for java.base and jdk.localedata in GensrcLocaleData.gmk. The drawback is that the shell find and calculation of the locale lists will be executed twice, but I suppose we can live with that. It's good to get a clean separation of gensrc between different modules when possible. Looks good to me now. /Erik > Please review. > > Naoto > > On 9/15/14, 4:30 PM, Naoto Sato wrote: >> Hello, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8058509 >> >> The webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/8058509/webrev.0/ >> >> The fix is intended to move the LocaleDataMetaInfo of CLDR from >> java.base module to jdk.localedata module, along with CLDR's "en" locale >> data and the package name change to avoid the "split package" in two >> modules. >> >> Naoto From magnus.ihse.bursie at oracle.com Wed Sep 17 10:48:25 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 Sep 2014 12:48:25 +0200 Subject: [9] RFR: 8058509: CLDRLocaleDataMetaInfo should be in jdk.localedata In-Reply-To: <54195618.9050308@oracle.com> References: <54177691.5030801@oracle.com> <5418A5A3.6030403@oracle.com> <54195618.9050308@oracle.com> Message-ID: <541966F9.2080706@oracle.com> On 2014-09-17 11:36, Erik Joelsson wrote: > > On 2014-09-16 23:03, Naoto Sato wrote: >> I revised the fix based on suggestions from Erik/Magnus. I just ended >> up creating Gensrc-jdk.localedata.gmk, instead of renaming >> GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly >> GensrcLocaleDataMetaInfo.gmk) is also needed to build jdk.localedata: >> >> http://cr.openjdk.java.net/~naoto/8058509/webrev.1/ >> > Right, you were able to separate the work for java.base and > jdk.localedata in GensrcLocaleData.gmk. The drawback is that the shell > find and calculation of the locale lists will be executed twice, but I > suppose we can live with that. It's good to get a clean separation of > gensrc between different modules when possible. > > Looks good to me now. Looks good to me, too. /Magnus From y.umaoka at gmail.com Thu Sep 18 23:44:34 2014 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 18 Sep 2014 19:44:34 -0400 Subject: Question about jdk.calendar.japanese.supplemental.era Message-ID: <541B6E62.3010906@gmail.com> In July, Okutsu-san sent a review request for JDK-8048123. I found this is very useful as temporary workaround until new Java patch embedding the new era. However, I think I found one issue. If you use java.util.Calendar, with locale ja-JP-u-ca-japanese, it seems to work as you expect. However, with new java.time package, era field prints out integer value of era. Below is an example code which reproduce the issue. // Pseudo new era // 1602288000000L => 2020-10-10 / Heisei 32-10-10 System.setProperty("jdk.calendar.japanese.supplemental.era", "name=???,abbr=N,since=1602288000000"); // The day before the switch over ChronoLocalDate date = JapaneseDate.of(JapaneseEra.HEISEI, 32, 10, 9); DateTimeFormatter fmt = DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL) .withChronology(JapaneseChronology.INSTANCE).withLocale(Locale.JAPAN); System.out.println(fmt.format(date)); // Output: "??32?10?9?" // Plus one day date = date.plus(1, ChronoUnit.DAYS); System.out.println(fmt.format(date)); // Output: "31?10?10?" The output above becomes "31?10?10?", which is actually composed by Era "3" + Year-Month-Day "1?10?10?". So, java.time.format.DateTimeFormatter does not use era name defined in the property, instead, use era's integer value. In addition to this, the equivalent code with old java.util.Calendar below: // Pseudo new era // 1602288000000L => 2020-10-10 / Heisei 32-10-10 System.setProperty("jdk.calendar.japanese.supplemental.era", "name=???,abbr=N,since=1602288000000"); Locale loc = Locale.forLanguageTag("ja-JP-u-ca-japanese"); Calendar cal = Calendar.getInstance(loc); cal.set(32, 10 - 1, 9); // Set October 9, Heisei 32 DateFormat fmt = DateFormat.getDateInstance(DateFormat.FULL, loc); System.out.println(fmt.format(cal.getTime())); // Output: ??32?10?9? // plus one day cal.add(Calendar.DATE, 1); System.out.println(fmt.format(cal.getTime())); // Output: ?????10?10? prints out "??" (which is correct) instead of "1?" (which is acceptable, but not correct). This is not related to new era switch over actually, but it should be fixed. Are you aware of these issues? -Yoshito From masayoshi.okutsu at oracle.com Fri Sep 19 00:32:28 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 19 Sep 2014 09:32:28 +0900 Subject: Question about jdk.calendar.japanese.supplemental.era In-Reply-To: <541B6E62.3010906@gmail.com> References: <541B6E62.3010906@gmail.com> Message-ID: <541B799C.6030906@oracle.com> Hi Umaoka-san, Yes, it's a known problem. I filed a bug report: https://bugs.openjdk.java.net/browse/JDK-8054214 Thanks, Masayoshi On 9/19/2014 8:44 AM, Yoshito Umaoka wrote: > In July, Okutsu-san sent a review request for JDK-8048123. > I found this is very useful as temporary workaround until new Java > patch embedding the new era. > > However, I think I found one issue. If you use java.util.Calendar, > with locale ja-JP-u-ca-japanese, it seems to work as you expect. > However, with new java.time package, era field prints out integer > value of era. Below is an example code which reproduce the issue. > > // Pseudo new era > // 1602288000000L => 2020-10-10 / Heisei 32-10-10 > System.setProperty("jdk.calendar.japanese.supplemental.era", > "name=???,abbr=N,since=1602288000000"); > > // The day before the switch over > ChronoLocalDate date = JapaneseDate.of(JapaneseEra.HEISEI, 32, 10, 9); > > DateTimeFormatter fmt = > DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL) > .withChronology(JapaneseChronology.INSTANCE).withLocale(Locale.JAPAN); > > System.out.println(fmt.format(date)); // Output: "??32?10?9?" > > // Plus one day > date = date.plus(1, ChronoUnit.DAYS); > > System.out.println(fmt.format(date)); // Output: "31?10?10?" > > > The output above becomes "31?10?10?", which is actually composed by > Era "3" + Year-Month-Day "1?10?10?". > So, java.time.format.DateTimeFormatter does not use era name defined > in the property, instead, use era's integer value. > > In addition to this, the equivalent code with old java.util.Calendar > below: > > // Pseudo new era > // 1602288000000L => 2020-10-10 / Heisei 32-10-10 > System.setProperty("jdk.calendar.japanese.supplemental.era", > "name=???,abbr=N,since=1602288000000"); > > Locale loc = Locale.forLanguageTag("ja-JP-u-ca-japanese"); > Calendar cal = Calendar.getInstance(loc); > cal.set(32, 10 - 1, 9); // Set October 9, Heisei 32 > > DateFormat fmt = DateFormat.getDateInstance(DateFormat.FULL, loc); > System.out.println(fmt.format(cal.getTime())); // Output: ??32?10?9? > > // plus one day > cal.add(Calendar.DATE, 1); > > System.out.println(fmt.format(cal.getTime())); // Output: ?????10 > ?10? > > prints out "??" (which is correct) instead of "1?" (which is > acceptable, but not correct). This is not related to new era switch > over actually, but it should be fixed. > > Are you aware of these issues? > > -Yoshito > > From masayoshi.okutsu at oracle.com Thu Sep 25 09:08:29 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 25 Sep 2014 18:08:29 +0900 Subject: [9] RFR: 8042126: DateTimeFormatter "MMMMM" returns English value in Japanese locale Message-ID: <5423DB8D.805@oracle.com> Hello, Please review the fix for narrow month names support. The narrow names, typically one letter names, are derived from the CLDR data. But there are some semantic differences between the legacy JDK localization and CLDR. The root resources have English names in JDK, but those are language neutral in CLDR. I changed JDK resources to follow the CLDR convention. Also I added test data for narrow month names of all locales. bug: https://bugs.openjdk.java.net/browse/JDK-8042126 wevrev: http://cr.openjdk.java.net/~okutsu/9/8042126/webrev.00/ Thanks, Masayoshi From naoto.sato at oracle.com Thu Sep 25 16:12:25 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 25 Sep 2014 09:12:25 -0700 Subject: [9] RFR: 8042126: DateTimeFormatter "MMMMM" returns English value in Japanese locale In-Reply-To: <5423DB8D.805@oracle.com> References: <5423DB8D.805@oracle.com> Message-ID: <54243EE9.2000405@oracle.com> Could it cause regressions in other locales, which has been expecting English narrow month names? Naoto On 9/25/14, 2:08 AM, Masayoshi Okutsu wrote: > Hello, > > Please review the fix for narrow month names support. The narrow names, > typically one letter names, are derived from the CLDR data. But there > are some semantic differences between the legacy JDK localization and > CLDR. The root resources have English names in JDK, but those are > language neutral in CLDR. I changed JDK resources to follow the CLDR > convention. Also I added test data for narrow month names of all locales. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8042126 > > wevrev: > http://cr.openjdk.java.net/~okutsu/9/8042126/webrev.00/ > > Thanks, > Masayoshi From masayoshi.okutsu at oracle.com Thu Sep 25 23:01:31 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 26 Sep 2014 08:01:31 +0900 Subject: [9] RFR: 8042126: DateTimeFormatter "MMMMM" returns English value in Japanese locale In-Reply-To: <54243EE9.2000405@oracle.com> References: <5423DB8D.805@oracle.com> <54243EE9.2000405@oracle.com> Message-ID: <54249ECB.7050908@oracle.com> Strictly speaking, this is an incompatible change from 8.0, but looks like those locales that don't have narrow month names expect the numbers rather than the English ones. Masayoshi On 9/26/2014 1:12 AM, Naoto Sato wrote: > Could it cause regressions in other locales, which has been expecting > English narrow month names? > > Naoto > > On 9/25/14, 2:08 AM, Masayoshi Okutsu wrote: >> Hello, >> >> Please review the fix for narrow month names support. The narrow names, >> typically one letter names, are derived from the CLDR data. But there >> are some semantic differences between the legacy JDK localization and >> CLDR. The root resources have English names in JDK, but those are >> language neutral in CLDR. I changed JDK resources to follow the CLDR >> convention. Also I added test data for narrow month names of all >> locales. >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8042126 >> >> wevrev: >> http://cr.openjdk.java.net/~okutsu/9/8042126/webrev.00/ >> >> Thanks, >> Masayoshi From naoto.sato at oracle.com Thu Sep 25 23:38:01 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 25 Sep 2014 16:38:01 -0700 Subject: [9] RFR: 8042126: DateTimeFormatter "MMMMM" returns English value in Japanese locale In-Reply-To: <54249ECB.7050908@oracle.com> References: <5423DB8D.805@oracle.com> <54243EE9.2000405@oracle.com> <54249ECB.7050908@oracle.com> Message-ID: <5424A759.4010702@oracle.com> OK, looks good to me then. Naoto On 9/25/14, 4:01 PM, Masayoshi Okutsu wrote: > Strictly speaking, this is an incompatible change from 8.0, but looks > like those locales that don't have narrow month names expect the numbers > rather than the English ones. > > Masayoshi > > On 9/26/2014 1:12 AM, Naoto Sato wrote: >> Could it cause regressions in other locales, which has been expecting >> English narrow month names? >> >> Naoto >> >> On 9/25/14, 2:08 AM, Masayoshi Okutsu wrote: >>> Hello, >>> >>> Please review the fix for narrow month names support. The narrow names, >>> typically one letter names, are derived from the CLDR data. But there >>> are some semantic differences between the legacy JDK localization and >>> CLDR. The root resources have English names in JDK, but those are >>> language neutral in CLDR. I changed JDK resources to follow the CLDR >>> convention. Also I added test data for narrow month names of all >>> locales. >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8042126 >>> >>> wevrev: >>> http://cr.openjdk.java.net/~okutsu/9/8042126/webrev.00/ >>> >>> Thanks, >>> Masayoshi > From sean.coffey at oracle.com Fri Sep 26 13:33:17 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 26 Sep 2014 14:33:17 +0100 Subject: RFR: Currency updates for JDK 7 Message-ID: <54256B1D.8010603@oracle.com> I'm looking to update Currency data in JDK 7u which hasn't been updated for some time. I'm porting back various currency updates from JDK 8. I'm using the opportunity to update some Locale issues also. 7085757: Currency Data: ISO 4217 Amendment 152 7195759: ISO 4217 Amendment 154 8021121: ISO 4217 Amendment Number 156 8055222: Currency update needed for ISO 4217 Amendment #159 8006748: getISO3Country() returns wrong value 7077119: remove past transition dates from CurrencyData.properties file Locale corrections : 6931564: Incorrect display name of Locale for south africa 8027695: There should be a space before % sign in Swedish locale webrev : http://cr.openjdk.java.net/~coffeys/webrev.currencyupdates.7u/webrev/ regards, Sean. From naoto.sato at oracle.com Fri Sep 26 18:36:50 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 26 Sep 2014 11:36:50 -0700 Subject: RFR: Currency updates for JDK 7 In-Reply-To: <54256B1D.8010603@oracle.com> References: <54256B1D.8010603@oracle.com> Message-ID: <5425B242.8030008@oracle.com> Hi Sean, What's the reason behind including those l10n changes (6931564/8027695) that has nothing to do with the currency data updates? It seems kind of odd to me to include those changes, leaving other l10n changes. Naoto On 9/26/14, 6:33 AM, Se?n Coffey wrote: > I'm looking to update Currency data in JDK 7u which hasn't been updated > for some time. I'm porting back various currency updates from JDK 8. I'm > using the opportunity to update some Locale issues also. > > 7085757: Currency Data: ISO 4217 Amendment 152 > 7195759: ISO 4217 Amendment 154 > 8021121: ISO 4217 Amendment Number 156 > 8055222: Currency update needed for ISO 4217 Amendment #159 > 8006748: getISO3Country() returns wrong value > 7077119: remove past transition dates from CurrencyData.properties file > > Locale corrections : > 6931564: Incorrect display name of Locale for south africa > 8027695: There should be a space before % sign in Swedish locale > > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.currencyupdates.7u/webrev/ > > regards, > Sean. From sean.coffey at oracle.com Fri Sep 26 19:41:33 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 26 Sep 2014 20:41:33 +0100 Subject: RFR: Currency updates for JDK 7 In-Reply-To: <5425B242.8030008@oracle.com> References: <54256B1D.8010603@oracle.com> <5425B242.8030008@oracle.com> Message-ID: <5425C16D.2050605@oracle.com> On 26/09/2014 19:36, Naoto Sato wrote: > Hi Sean, > > What's the reason behind including those l10n changes > (6931564/8027695) that has nothing to do with the currency data > updates? It seems kind of odd to me to include those changes, leaving > other l10n changes. I can take out the 6931564/8027695 changes if necessary. They're two point fixes that I came across while bringing back the currency changes. Figured that they would also be useful/low risk fixes in an update release. regards, Sean. > > Naoto > > On 9/26/14, 6:33 AM, Se?n Coffey wrote: >> I'm looking to update Currency data in JDK 7u which hasn't been updated >> for some time. I'm porting back various currency updates from JDK 8. I'm >> using the opportunity to update some Locale issues also. >> >> 7085757: Currency Data: ISO 4217 Amendment 152 >> 7195759: ISO 4217 Amendment 154 >> 8021121: ISO 4217 Amendment Number 156 >> 8055222: Currency update needed for ISO 4217 Amendment #159 >> 8006748: getISO3Country() returns wrong value >> 7077119: remove past transition dates from CurrencyData.properties file >> >> Locale corrections : >> 6931564: Incorrect display name of Locale for south africa >> 8027695: There should be a space before % sign in Swedish locale >> >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.currencyupdates.7u/webrev/ >> >> regards, >> Sean. From naoto.sato at oracle.com Fri Sep 26 20:49:38 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 26 Sep 2014 13:49:38 -0700 Subject: RFR: Currency updates for JDK 7 In-Reply-To: <5425C16D.2050605@oracle.com> References: <54256B1D.8010603@oracle.com> <5425B242.8030008@oracle.com> <5425C16D.2050605@oracle.com> Message-ID: <5425D162.60707@oracle.com> That's OK. Looks good to me. Thank you for the backport! Naoto On 9/26/14, 12:41 PM, Se?n Coffey wrote: > > On 26/09/2014 19:36, Naoto Sato wrote: >> Hi Sean, >> >> What's the reason behind including those l10n changes >> (6931564/8027695) that has nothing to do with the currency data >> updates? It seems kind of odd to me to include those changes, leaving >> other l10n changes. > I can take out the 6931564/8027695 changes if necessary. They're two > point fixes that I came across while bringing back the currency changes. > Figured that they would also be useful/low risk fixes in an update release. > > regards, > Sean. >> >> Naoto >> >> On 9/26/14, 6:33 AM, Se?n Coffey wrote: >>> I'm looking to update Currency data in JDK 7u which hasn't been updated >>> for some time. I'm porting back various currency updates from JDK 8. I'm >>> using the opportunity to update some Locale issues also. >>> >>> 7085757: Currency Data: ISO 4217 Amendment 152 >>> 7195759: ISO 4217 Amendment 154 >>> 8021121: ISO 4217 Amendment Number 156 >>> 8055222: Currency update needed for ISO 4217 Amendment #159 >>> 8006748: getISO3Country() returns wrong value >>> 7077119: remove past transition dates from CurrencyData.properties file >>> >>> Locale corrections : >>> 6931564: Incorrect display name of Locale for south africa >>> 8027695: There should be a space before % sign in Swedish locale >>> >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.currencyupdates.7u/webrev/ >>> >>> regards, >>> Sean. >