From naoto.sato at oracle.com Fri Sep 6 17:59:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 6 Sep 2019 10:59:08 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8230284 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ The original enhancement for the accounting currency format support (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for the explicit/implicit numbering script. The above change made it to share the same code with NumberElements which properly deals with the numbering script. Naoto From Roger.Riggs at oracle.com Mon Sep 9 15:12:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 11:12:34 -0400 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: References: Message-ID: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> Hi Naoto, Bundle.java: ?- 28: Explicit import are preferred,? (if the IDE make the change, fix the settings in the IDE). ?- 763, the indentation of the nested getOrDefault calls doesn't look conventional. ? (It might be interesting to have an API that allows one or more defaults to be tried in turn. ?? It will call each of the methods so there is no shortcutting if the value is found early in the list). CLDRConverter: ?- 513, 1169...: Debugging code can be removed Otherwise looks ok. Thanks, Roger On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8230284 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ > > The original enhancement for the accounting currency format support > (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for > the explicit/implicit numbering script. The above change made it to > share the same code with NumberElements which properly deals with the > numbering script. > > Naoto From naoto.sato at oracle.com Mon Sep 9 18:23:12 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 11:23:12 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> Message-ID: <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Hi Roger, Thanks for the review. On 9/9/19 8:12 AM, Roger Riggs wrote: > Hi Naoto, > > Bundle.java: > ?- 28: Explicit import are preferred,? (if the IDE make the change, fix > the settings in the IDE). Corrected. > > ?- 763, the indentation of the nested getOrDefault calls doesn't look > conventional. > ? (It might be interesting to have an API that allows one or more > defaults to be tried in turn. > ?? It will call each of the methods so there is no shortcutting if the > value is found early in the list). The code meant to short cut if a value is found early, as this implements the fallback. I corrected the indentation of getOrDefault() methods. > > CLDRConverter: > ?- 513, 1169...: Debugging code can be removed I removed the one around line 513, but kept the 1169 as this is useful. It does not affect the JDK image as this is the code for the build tool. > > Otherwise looks ok. Updated webrev is here: http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ Naoto > > Thanks, Roger > > > > On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8230284 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >> >> The original enhancement for the accounting currency format support >> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for >> the explicit/implicit numbering script. The above change made it to >> share the same code with NumberElements which properly deals with the >> numbering script. >> >> Naoto > From Roger.Riggs at oracle.com Mon Sep 9 19:07:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 15:07:51 -0400 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Message-ID: Hi, Looks fine. [The code is clear as is; but the shortcuts in Bundle.java (770-775) won't actually be a shortcut because for each method it has to compute the value of the argument before it can call the method. There isn't an API that accepts a supplier that would not be evaluated until the value was needed.] Thanks, Roger On 9/9/19 2:23 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > Thanks for the review. > > On 9/9/19 8:12 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Bundle.java: >> ??- 28: Explicit import are preferred,? (if the IDE make the change, >> fix the settings in the IDE). > > Corrected. > >> >> ??- 763, the indentation of the nested getOrDefault calls doesn't >> look conventional. >> ?? (It might be interesting to have an API that allows one or more >> defaults to be tried in turn. >> ??? It will call each of the methods so there is no shortcutting if >> the value is found early in the list). > > The code meant to short cut if a value is found early, as this > implements the fallback. I corrected the indentation of getOrDefault() > methods. > >> >> CLDRConverter: >> ??- 513, 1169...: Debugging code can be removed > > I removed the one around line 513, but kept the 1169 as this is > useful. It does not affect the JDK image as this is the code for the > build tool. > >> >> Otherwise looks ok. > > Updated webrev is here: > > http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ > > Naoto > >> >> Thanks, Roger >> >> >> >> On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230284 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >>> >>> The original enhancement for the accounting currency format support >>> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account >>> for the explicit/implicit numbering script. The above change made it >>> to share the same code with NumberElements which properly deals with >>> the numbering script. >>> >>> Naoto >> From naoto.sato at oracle.com Mon Sep 9 19:21:57 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 12:21:57 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Message-ID: Thanks again, Roger. I now get what you meant. Yes, the current code does calculate each value before getting the correct one. Naoto On 9/9/19 12:07 PM, Roger Riggs wrote: > Hi, > > Looks fine. > > [The code is clear as is; but the shortcuts in Bundle.java (770-775) > won't actually be a shortcut > because for each method it has to compute the value of the argument > before it can call the method. > There isn't an API that accepts a supplier that would not be evaluated > until the value was needed.] > > Thanks, Roger > > > On 9/9/19 2:23 PM, naoto.sato at oracle.com wrote: >> Hi Roger, >> >> Thanks for the review. >> >> On 9/9/19 8:12 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> Bundle.java: >>> ??- 28: Explicit import are preferred,? (if the IDE make the change, >>> fix the settings in the IDE). >> >> Corrected. >> >>> >>> ??- 763, the indentation of the nested getOrDefault calls doesn't >>> look conventional. >>> ?? (It might be interesting to have an API that allows one or more >>> defaults to be tried in turn. >>> ??? It will call each of the methods so there is no shortcutting if >>> the value is found early in the list). >> >> The code meant to short cut if a value is found early, as this >> implements the fallback. I corrected the indentation of getOrDefault() >> methods. >> > > > >>> >>> CLDRConverter: >>> ??- 513, 1169...: Debugging code can be removed >> >> I removed the one around line 513, but kept the 1169 as this is >> useful. It does not affect the JDK image as this is the code for the >> build tool. >> >>> >>> Otherwise looks ok. >> >> Updated webrev is here: >> >> http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ >> >> Naoto >> >>> >>> Thanks, Roger >>> >>> >>> >>> On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8230284 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >>>> >>>> The original enhancement for the accounting currency format support >>>> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account >>>> for the explicit/implicit numbering script. The above change made it >>>> to share the same code with NumberElements which properly deals with >>>> the numbering script. >>>> >>>> Naoto >>> > From sean.coffey at oracle.com Wed Sep 11 10:50:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 11 Sep 2019 10:50:00 +0000 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone Message-ID: The current algorithm for determining the default timezone on (non-AIX) unix systems goes something like : 1. If TZ environment variable is defined, use it 2. else if /etc/timezone exists, use the value contained within it 3. else if /etc/localtime exists and is a symbolic link, use the name pointed to 4. else if /etc/localtime is a binary, find the first identical time zone binary file in /usr/share/zoneinfo/ Step 4 is a bit crude in that the zoneinfo directory can contain over 1,800 files on today's systems. I'd like to change the logic so that common timezones are first checked for buffer matching before a full directory traversal is performed. It should be a performance gain and it should also lead to more consistent results for reasons outlined in the bug report. https://bugs.openjdk.java.net/browse/JDK-8223490 webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ -- Regards, Sean. From naoto.sato at oracle.com Thu Sep 12 16:42:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Sep 2019 09:42:51 -0700 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: Message-ID: Hi Se?n, I like your approach to provide the fast path to determine the system time zone. One general question is, is UTC/GMT the right set of fast path candidates? Should we add some more common ones? Other comments to the code: TimeZone_md.c - Should fast path search come after "dir" validation, i.e., line 146-148? - Line 126: "statbuf" can be removed. - Line 134: 'i' is not size_of_something, so 'int' type should suffice (and its initialization is done in the for-loop). - Line 138: the fast path search should "continue" with the next name, instead of "break". - Line 142, 182: I'd wrap this line with parens for the if statement. - Line 232-242: "pathname" is an argument to this function, so freeing it inside the function seems odd. Also, no need to reset dbuf/fd since they are no longer reused in the loop. Naoto On 9/11/19 3:50 AM, Se?n Coffey wrote: > The current algorithm for determining the default timezone on (non-AIX) > unix systems goes something like : > > 1. If TZ environment variable is defined, use it > 2. else if /etc/timezone exists, use the value contained within it > 3. else if /etc/localtime exists and is a symbolic link, use the name > pointed to > 4. else if /etc/localtime is a binary, find the first identical time > zone binary file in /usr/share/zoneinfo/ > > Step 4 is a bit crude in that the zoneinfo directory can contain over > 1,800 files on today's systems. I'd like to change the logic so that > common timezones are first checked for buffer matching before a full > directory traversal is performed. It should be a performance gain and it > should also lead to more consistent results for reasons outlined in the > bug report. > > https://bugs.openjdk.java.net/browse/JDK-8223490 > webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ > > From naoto.sato at oracle.com Thu Sep 12 20:24:38 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Sep 2019 13:24:38 -0700 Subject: 8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed In-Reply-To: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> References: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> Message-ID: <6bcfefbe-ffb9-a33d-23c3-3bffbae7dbbb@oracle.com> Hi Masanori, Thank you for looking at the issue and your contribution. I am also investigating it (as an assignee of the bug), and looking at this old issue: https://bugs.openjdk.java.net/browse/JDK-4177484 The comment suggests that the existing behavior is the expected one. In fact, your fix would break some regression test cases in jdk/java/util/Calendar/CalendarRegression.java. I will need some more archaeological investigation, but I am inclined to close it as not an issue at the moment. Naoto On 9/12/19 12:16 AM, Yano, Masanori wrote: > Hello. > > I think JDK-8229471 occurs because a change of TimeZone is not considered in getTime(). > To resolve this problem, isTimeSet flag must be set to false when setTimeZone() is called. > > Please review the following change. > > diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java > --- a/src/java.base/share/classes/java/util/Calendar.java Thu Aug 22 14:09:36 2019 -0700 > +++ b/src/java.base/share/classes/java/util/Calendar.java Thu Sep 12 11:45:37 2019 +0900 > @@ -2901,7 +2901,7 @@ > * generally, a call to setTimeZone() affects calls to set() BEFORE AND > * AFTER it up to the next call to complete(). > */ > - areAllFieldsSet = areFieldsSet = false; > + isTimeSet = areAllFieldsSet = areFieldsSet = false; > } > > /** > diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/jdk/java/util/Calendar/Bug8229471.java Thu Sep 12 11:45:37 2019 +0900 > @@ -0,0 +1,22 @@ > +/* > + *@test > + *@bug 8229471 > + *@summary test for recompute when Calendar.setTimeZone() > + */ > + > +import java.util.Calendar; > +import java.util.Date; > +import java.util.Locale; > +import java.util.TimeZone; > + > +public class Bug8229471 { > + public static void main(String[] args) throws Exception { > + Calendar calendar = Calendar.getInstance(new Locale("en", "US")); > + Date date1 = calendar.getTime(); > + calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest")); > + Date date2 = calendar.getTime(); > + if (date1.equals(date2)) { > + throw new RuntimeException("Bug8229471: failed. TimeZone is not applied."); > + } > + } > +} > > Regards, > Masanori Yano > From sean.coffey at oracle.com Fri Sep 13 08:32:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 Sep 2019 09:32:00 +0100 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References:

Message-ID: <38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> Thanks for the review Naoto. The edits certainly did need some tidying up. Comments inline. On 12/09/2019 17:42, naoto.sato at oracle.com wrote: > Hi Se?n, > > I like your approach to provide the fast path to determine the system > time zone. One general question is, is UTC/GMT the right set of fast > path candidates? Should we add some more common ones? > I'm open to suggestions. I think these two are very common and good for starting with. > Other comments to the code: > > TimeZone_md.c > > - Should fast path search come after "dir" validation, i.e., line > 146-148? > - Line 126: "statbuf" can be removed. > - Line 134: 'i' is not size_of_something, so 'int' type should suffice > (and its initialization is done in the for-loop). > - Line 138: the fast path search should "continue" with the next name, > instead of "break". > - Line 142, 182: I'd wrap this line with parens for the if statement. All above corrected. > - Line 232-242: "pathname" is an argument to this function, so freeing > it inside the function seems odd. Also, no need to reset dbuf/fd since > they are no longer reused in the loop. > I thought it was a useful approach given that it's the last function to use 'pathname'. However, it's not in keeping with normal design I guess. I've reverted and now free pathname at other call sites instead. new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/ regards, Sean. > Naoto > > On 9/11/19 3:50 AM, Se?n Coffey wrote: >> The current algorithm for determining the default timezone on >> (non-AIX) unix systems goes something like : >> >> 1. If TZ environment variable is defined, use it >> 2. else if /etc/timezone exists, use the value contained within it >> 3. else if /etc/localtime exists and is a symbolic link, use the name >> pointed to >> 4. else if /etc/localtime is a binary, find the first identical time >> zone binary file in /usr/share/zoneinfo/ >> >> Step 4 is a bit crude in that the zoneinfo directory can contain over >> 1,800 files on today's systems. I'd like to change the logic so that >> common timezones are first checked for buffer matching before a full >> directory traversal is performed. It should be a performance gain and >> it should also lead to more consistent results for reasons outlined >> in the bug report. >> >> https://bugs.openjdk.java.net/browse/JDK-8223490 >> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >> >> From naoto.sato at oracle.com Fri Sep 13 18:05:49 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 13 Sep 2019 11:05:49 -0700 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> References:

<38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> Message-ID: Much better now. One nit: label "freedata" at line 236 should not be indented. As to the fastpath candidate zones, I was just curious. UTC/GMT is fine by me. Naoto On 9/13/19 1:32 AM, Se?n Coffey wrote: > Thanks for the review Naoto. The edits certainly did need some tidying > up. Comments inline. > > On 12/09/2019 17:42, naoto.sato at oracle.com wrote: >> Hi Se?n, >> >> I like your approach to provide the fast path to determine the system >> time zone. One general question is, is UTC/GMT the right set of fast >> path candidates? Should we add some more common ones? >> > I'm open to suggestions. I think these two are very common and good for > starting with. > >> Other comments to the code: >> >> TimeZone_md.c >> >> - Should fast path search come after "dir" validation, i.e., line >> 146-148? >> - Line 126: "statbuf" can be removed. >> - Line 134: 'i' is not size_of_something, so 'int' type should suffice >> (and its initialization is done in the for-loop). >> - Line 138: the fast path search should "continue" with the next name, >> instead of "break". >> - Line 142, 182: I'd wrap this line with parens for the if statement. > All above corrected. >> - Line 232-242: "pathname" is an argument to this function, so freeing >> it inside the function seems odd. Also, no need to reset dbuf/fd since >> they are no longer reused in the loop. >> > I thought it was a useful approach given that it's the last function to > use 'pathname'. However, it's not in keeping with normal design I guess. > I've reverted and now free pathname at other call sites instead. > > new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/ > > regards, > Sean. > >> Naoto >> >> On 9/11/19 3:50 AM, Se?n Coffey wrote: >>> The current algorithm for determining the default timezone on >>> (non-AIX) unix systems goes something like : >>> >>> 1. If TZ environment variable is defined, use it >>> 2. else if /etc/timezone exists, use the value contained within it >>> 3. else if /etc/localtime exists and is a symbolic link, use the name >>> pointed to >>> 4. else if /etc/localtime is a binary, find the first identical time >>> zone binary file in /usr/share/zoneinfo/ >>> >>> Step 4 is a bit crude in that the zoneinfo directory can contain over >>> 1,800 files on today's systems. I'd like to change the logic so that >>> common timezones are first checked for buffer matching before a full >>> directory traversal is performed. It should be a performance gain and >>> it should also lead to more consistent results for reasons outlined >>> in the bug report. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223490 >>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >>> >>> From ramanand.patil at oracle.com Tue Sep 17 08:18:37 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 17 Sep 2019 01:18:37 -0700 (PDT) Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c Message-ID: <80fa7966-1731-4941-9343-2ee7428587fd@default> Hi all, Please review the patch for tzdata2019c integration into jdk project(jdk-14). Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 The patch has passed all the related testing including JCK. Regards, Ramanand. From martinrb at google.com Tue Sep 17 15:29:28 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 Sep 2019 08:29:28 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: <80fa7966-1731-4941-9343-2ee7428587fd@default> References: <80fa7966-1731-4941-9343-2ee7428587fd@default> Message-ID: Looks good to me. At Google we also integrated tzdata2019c, and it was uneventful (good!). But we're still using rearguard format. The vanguard/rearguard distinction is a source of errors, so it should be made clear what format is being used to import the files. If you have a script to update the jdk sources, perhaps it should be checked in to openjdk? If these files are in vanguard format, is there a trap for those of us doing backports to jdks that only support rearguard? On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019c integration into jdk > project(jdk-14). > Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 > > The patch has passed all the related testing including JCK. > > Regards, > Ramanand. > From naoto.sato at oracle.com Tue Sep 17 16:45:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Sep 2019 09:45:15 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> Message-ID: <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> +1 On 9/17/19 8:29 AM, Martin Buchholz wrote: > Looks good to me. > At Google we also integrated tzdata2019c, and it was uneventful (good!). > But we're still using rearguard format. > The vanguard/rearguard distinction is a source of errors, so it should be > made clear what format is being used to import the files. > If you have a script to update the jdk sources, perhaps it should be > checked in to openjdk? > If these files are in vanguard format, is there a trap for those of us > doing backports to jdks that only support rearguard? Can't think of any off the top of my head, Martin. The build tool internally converts vanguard data into rearguard compatible, by adjusting the standard offsets, and build into tzdb.dat (which should even be compatible to prior JDK runtimes). Naoto > > On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil > wrote: > >> Hi all, >> Please review the patch for tzdata2019c integration into jdk >> project(jdk-14). >> Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 >> >> The patch has passed all the related testing including JCK. >> >> Regards, >> Ramanand. >> From martinrb at google.com Tue Sep 17 17:14:35 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 Sep 2019 10:14:35 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> Message-ID: On Tue, Sep 17, 2019 at 9:45 AM wrote: > +1 > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > Looks good to me. > > At Google we also integrated tzdata2019c, and it was uneventful (good!). > > But we're still using rearguard format. > > The vanguard/rearguard distinction is a source of errors, so it should be > > made clear what format is being used to import the files. > > If you have a script to update the jdk sources, perhaps it should be > > checked in to openjdk? > > If these files are in vanguard format, is there a trap for those of us > > doing backports to jdks that only support rearguard? > > Can't think of any off the top of my head, Martin. The build tool > Which build tool? TzdbZoneRulesCompiler? > internally converts vanguard data into rearguard compatible, by > adjusting the standard offsets, and build into tzdb.dat (which should > even be compatible to prior JDK runtimes). > So ... a change like this one is created by copying selected vanguard format files from the tzdata source distribution into openjdk, and then TzdbZoneRulesCompiler converts to rearguard format internally? At Google, we chose to run tzdata's own tool to convert to rearguard format and then check in those data files into the jdk source tree. I worry that when other engineers backport to older releases, if only the data files are copied, then conversion to rearguard format will not happen, with bad results. From naoto.sato at oracle.com Tue Sep 17 17:54:49 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Sep 2019 10:54:49 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> Message-ID: On 9/17/19 10:14 AM, Martin Buchholz wrote: > > > On Tue, Sep 17, 2019 at 9:45 AM > wrote: > > +1 > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > Looks good to me. > > At Google we also integrated tzdata2019c, and it was uneventful > (good!). > > But we're still using rearguard format. > > The vanguard/rearguard distinction is a source of errors, so it > should be > > made clear what format is being used to import the files. > > If you have a script to update the jdk sources, perhaps it should be > > checked in to openjdk? > > If these files are in vanguard format, is there a trap for those > of us > > doing backports to jdks that only support rearguard? > > Can't think of any off the top of my head, Martin. The build tool > > > Which build tool??TzdbZoneRulesCompiler? Yes. > > internally converts vanguard data into rearguard compatible, by > adjusting the standard offsets, and build into tzdb.dat (which should > even be compatible to prior JDK runtimes). > > > So ... a change like this one is created by copying selected vanguard > format files from the tzdata source distribution into openjdk, and > then?TzdbZoneRulesCompiler converts to rearguard format internally?? At > Google, we chose to run tzdata's?own?tool to convert to rearguard format > and then check in those data files into the jdk source tree. The tool will not convert the file format to rearguard. Read the vanguard format file, then converts the data into tzdb.dat that can be recognized by prior runtimes. > > I worry that when other engineers backport to older releases, if only > the data files are copied, then conversion to rearguard format will not > happen,?with bad results. If an engineer only backports the vanguard files into older releases (before the vanguard support), I don't think the JDK build will succeed. Build will fail on creating tzdb.dat file. Naoto From christoph.langer at sap.com Wed Sep 18 09:45:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 09:45:21 +0000 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support Message-ID: Hi, please review this backport to JDK11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b, which is required for 11.0.5. This will make the JDK's timezone parser support the "vanguard" format and enables a simple backport of JDK-8228469. To make the patch applicable to jdk11u, I had to manually do all the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk. Furthermore there were some rejects which were easy to resolve in: make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> Copyright year make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> Copyright year and import statements src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java -> Copyright year With the patch applied all regression testing shows still green (both, jtreg and TCK). Thanks Christoph From ramanand.patil at oracle.com Wed Sep 18 17:44:17 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 18 Sep 2019 10:44:17 -0700 (PDT) Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com>

Message-ID: Hi Naoto and Martin, Thank you very much for your reviews. Hi Martin, Naoto is correct, the jdk build will fail for the update releases when using vanguard format, since the fix from JDK-8212970 is not yet backported. Since, jdk14 has this fix, my current patch uses vanguard format tzdata. I am planning to backport JDK-8212970 along with the tzdata2019c integration into the update releases, if there are no major issues. I have already seen the 11u backport request from Christoph for-8212970. Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, September 17, 2019 11:25 PM > To: Martin Buchholz > Cc: Ramanand Patil ; core-libs-dev dev at openjdk.java.net>; i18n-dev > Subject: Re: RFR: 8231098: (tz) Upgrade time-zone data to > tzdata2019c > > On 9/17/19 10:14 AM, Martin Buchholz wrote: > > > > > > On Tue, Sep 17, 2019 at 9:45 AM > > wrote: > > > > +1 > > > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > > Looks good to me. > > > At Google we also integrated tzdata2019c, and it was uneventful > > (good!). > > > But we're still using rearguard format. > > > The vanguard/rearguard distinction is a source of errors, so it > > should be > > > made clear what format is being used to import the files. > > > If you have a script to update the jdk sources, perhaps it should be > > > checked in to openjdk? > > > If these files are in vanguard format, is there a trap for those > > of us > > > doing backports to jdks that only support rearguard? > > > > Can't think of any off the top of my head, Martin. The build tool > > > > > > Which build tool??TzdbZoneRulesCompiler? > > Yes. > > > > > internally converts vanguard data into rearguard compatible, by > > adjusting the standard offsets, and build into tzdb.dat (which should > > even be compatible to prior JDK runtimes). > > > > > > So ... a change like this one is created by copying selected vanguard > > format files from the tzdata source distribution into openjdk, and > > then?TzdbZoneRulesCompiler converts to rearguard format internally? > > At Google, we chose to run tzdata's?own?tool to convert to rearguard > > format and then check in those data files into the jdk source tree. > > The tool will not convert the file format to rearguard. Read the vanguard > format file, then converts the data into tzdb.dat that can be recognized by > prior runtimes. > > > > > I worry that when other engineers backport to older releases, if only > > the data files are copied, then conversion to rearguard format will > > not happen,?with bad results. > > If an engineer only backports the vanguard files into older releases (before > the vanguard support), I don't think the JDK build will succeed. > Build will fail on creating tzdb.dat file. > > Naoto From christoph.langer at sap.com Fri Sep 20 09:39:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Sep 2019 09:39:35 +0000 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: Thank you, Matthias. From: Baesken, Matthias Sent: Freitag, 20. September 2019 10:07 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212970: TZ database in "vanguard" format support Hello Christoph, looks good to me ! Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 18. September 2019 11:45 To: jdk-updates-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support Hi, please review this backport to JDK11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b, which is required for 11.0.5. This will make the JDK?s timezone parser support the ?vanguard? format and enables a simple backport of JDK-8228469. To make the patch applicable to jdk11u, I had to manually do all the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk. Furthermore there were some rejects which were easy to resolve in: make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> Copyright year make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> Copyright year and import statements src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java -> Copyright year With the patch applied all regression testing shows still green (both, jtreg and TCK). Thanks Christoph From martinrb at google.com Fri Sep 20 15:11:25 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Sep 2019 08:11:25 -0700 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: (not a review) At Google, we decided to stay on rearguard format tzdata files for all our jdks. One reason for that was being able to easily support older jdk versions with the same data files. Vanguard still seems riskier to me than rearguard. Of course, eventually we'll need to switch to vanguard, and this backport will make that possible earlier. Another pitfall when backporting to jdk8 is that there are two copies of all the tzdata files in the repo. On Wed, Sep 18, 2019 at 2:46 AM Langer, Christoph wrote: > Hi, > > please review this backport to JDK11 updates: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 > > This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data > to tzdata2019b, which is required for 11.0.5. This will make the JDK's > timezone parser support the "vanguard" format and enables a simple backport > of JDK-8228469. > > To make the patch applicable to jdk11u, I had to manually do all the > deletions in test/jdk/sun/util/calendar/zi/tzdata and > test/jdk/sun/util/calendar/zi/tzdata_jdk. > > Furthermore there were some rejects which were easy to resolve in: > make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> > Copyright year > make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> > Copyright year and import statements > src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year > src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java > -> Copyright year > > With the patch applied all regression testing shows still green (both, > jtreg and TCK). > > Thanks > Christoph > > From ying.z.zhou at oracle.com Thu Sep 26 05:58:22 2019 From: ying.z.zhou at oracle.com (Daisy Zhou) Date: Wed, 25 Sep 2019 22:58:22 -0700 (PDT) Subject: [14]RFR 8231213: Migrate SimpleDateFormatConstTest to JDK Repo Message-ID: <61169622-561d-4a93-b1f9-fa261727d6d5@default> Hello, Please help to review this patch for migrating SimpleDateFormatConstTest from Tonga to Jtreg. Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8231213" https://bugs.openjdk.java.net/browse/JDK-8231213 Webrev: http://cr.openjdk.java.net/~yzhou/8231213/webrev.02/ Thanks, Daisy From naoto.sato at oracle.com Thu Sep 26 15:28:46 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 26 Sep 2019 08:28:46 -0700 Subject: [14]RFR 8231213: Migrate SimpleDateFormatConstTest to JDK Repo In-Reply-To: <61169622-561d-4a93-b1f9-fa261727d6d5@default> References: <61169622-561d-4a93-b1f9-fa261727d6d5@default> Message-ID: Looks good. Naoto On 9/25/19 10:58 PM, Daisy Zhou wrote: > Hello, > > Please help to review this patch for migrating SimpleDateFormatConstTest from Tonga to Jtreg. > > > > Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8231213" https://bugs.openjdk.java.net/browse/JDK-8231213 > > Webrev: http://cr.openjdk.java.net/~yzhou/8231213/webrev.02/ > > > > Thanks, > > Daisy > From ramanand.patil at oracle.com Fri Sep 27 08:58:23 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 27 Sep 2019 01:58:23 -0700 (PDT) Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> Message-ID: <285975f8-b183-4e33-bc2b-58115b676ff2@default> Adding i18n group. Regards, Ramanand. > -----Original Message----- > From: Ramanand Patil > Sent: Thursday, September 26, 2019 3:16 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support > > Hi all, > Please review this backport to JDK13 updates: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 > Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ > Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 > > The patch from jdk14 was not applied cleanly. Here is the change summary: > - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and > test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. > - The original patch(jdk14) had tzdata2019a vanguard format, but > since the jdk13u is already patched with tzdata2019b rearguard format, in > this patch tzdata files used are from tzdata2019b vanguard format. > Post this backport, it will be easy to backport future tzdata versions starting > tzdata2019c(JDK-8231098). > > All the related tests including JCK are passed. > > > Regards, > Ramanand. From naoto.sato at oracle.com Fri Sep 27 16:14:35 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 27 Sep 2019 09:14:35 -0700 Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <285975f8-b183-4e33-bc2b-58115b676ff2@default> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> <285975f8-b183-4e33-bc2b-58115b676ff2@default> Message-ID: Looks good to me. Naoto On 9/27/19 1:58 AM, Ramanand Patil wrote: > Adding i18n group. > > > Regards, > Ramanand. > >> -----Original Message----- >> From: Ramanand Patil >> Sent: Thursday, September 26, 2019 3:16 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support >> >> Hi all, >> Please review this backport to JDK13 updates: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 >> Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ >> Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 >> >> The patch from jdk14 was not applied cleanly. Here is the change summary: >> - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and >> test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. >> - The original patch(jdk14) had tzdata2019a vanguard format, but >> since the jdk13u is already patched with tzdata2019b rearguard format, in >> this patch tzdata files used are from tzdata2019b vanguard format. >> Post this backport, it will be easy to backport future tzdata versions starting >> tzdata2019c(JDK-8231098). >> >> All the related tests including JCK are passed. >> >> >> Regards, >> Ramanand.