Re: RFR: 8223490: Optimize search algorithm for determining default time zone

ful 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

RFR: 8223490: Optimize search algorithm for determining default time zone

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 po

Re: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Looks good Ramanand. regards, Sean. On 06/08/2019 06:57, Ramanand Patil wrote: Hi all, Please review the patch for jdk13u backport of tzdata2019b integration into jdk: Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 The pa

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

The changes look fine to me Ramanand. The europe file contains some interesting comments about the rolled back changes that have been made for 2018c. A plan on how to resolve these pending changes can be followed up via JDK-8195595 Regards, Sean. On 29/01/18 08:49, Ramanand Patil wrote: Hi a

Re: DateFormatSymbols for Locale.GERMAN changed form Java 8 to Java 9

CLDR Locale data is now used by default in JDK 9. If you need to remain with JDK 8 behaviour you can use the 'java.locale.providers' system property. See https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-974CF488-23E8-4963-A322-82006A7A14C7 Regards, S

Re: RFR: 8151876: (tz) Support tzdata2016d

if (! zi.equalsTo(ziOLD)) { Regards, Ramanand. *From:*Seán Coffey *Sent:* Tuesday, May 31, 2016 3:05 PM *To:* Masayoshi Okutsu; Ramanand Patil; i18n-dev@openjdk.java.net; core-libs-...@openjdk.java.net *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d Masayoshi, I still think the test

Re: RFR: 8151876: (tz) Support tzdata2016d

ese test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT±hh:mm format. Regards, Ramanand. *From:*Masayoshi Okutsu *Sent:* Saturday, May 28, 2016 10:58 AM *To:* Seán Coffey; Ramanand Patil; i18n-dev@openjdk.java.net; core-lib

Re: RFR: 8151876: (tz) Support tzdata2016d

beyond my proposal that the "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing* zones which have changed to use the "±hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GM

Re: RFR: 8151876: (tz) Support tzdata2016d

Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration (tzda

Re: RFR: 8098547: (tz) Support tzdata2015e

That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. Where the 1969 date coming from ? Is there some rollover calculation happening ? Regards, Sean. On 25/06/2015 09:05, Attila Szege

Re: RFR: 8098547: (tz) Support tzdata2015e

Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on all platforms. With Best Regards, Aleksej [1] https://bu

Re: RFR : 8071447: IBM1166 Locale Request for Kazakh characters

ot;. But it has been this way for a long time. The rest looks fine. I might have overlooked the implementation for the early update releases? -Sherman On 2/24/15 6:02 AM, Seán Coffey wrote: I've updated the JDK 9 changes to take account of the recent NIO charset work that Sherman

Re: RFR : 8071447: IBM1166 Locale Request for Kazakh characters

104 < 0x67 U+0407 --- > 0x67 U+049a 107c106 < 0x69 U+0409 --- > 0x69 U+04a2 114,116c113,115 < 0x70 U+040a < 0x71 U+040b < 0x72 U+040c --- > 0x70 U+04e8 > 0x71 U+04b0 > 0x72 U+04ae 119c118 < 0x75 U+040f --- > 0x75 U+04ba 227c226 < 0xe1 U+00a7 --- > 0xe

Re: RFR : 8071447: IBM1166 Locale Request for Kazakh characters

Just a reminder on this one.. regards, Sean. On 06/02/15 17:51, Seán Coffey wrote: Looking for a code review around the addition of this new charset. I haven't added a charset before so I'm hoping I caught all the necessary steps and edits. Sherman, would appreciate if you co

RFR : 8071447: IBM1166 Locale Request for Kazakh characters

Looking for a code review around the addition of this new charset. I haven't added a charset before so I'm hoping I caught all the necessary steps and edits. Sherman, would appreciate if you could cast a careful eye over this one. In particular, I'm wondering if I need to take extra steps due

Re: [9] RFR: 8072042: (tz) Support tzdata2015a

Looks good to me. regards, Sean. On 03/02/2015 15:59, Aleksej Efimov wrote: Hi, Could I have a review the latest tzdata2015a integration fix to JDK9, please. The regression tests run and JPRT testing (jdk_other,jdk_util, jdk_text, jdk_time test sets) shows no TZ related JDK9 failures. Than

Re: RFR: 8064914: tzdb.dat compilation failure when using tzdata2014j

Looks fine. Thanks for handling. regards, Sean. On 17/11/2014 00:11, Aleksej Efimov wrote: Hello, During the latest tzdata (2014j) integration the tzdb.dat build failure was observed - details can be found in JBS [1]. The proposed [2] fix resolves time zones double link problem and JDK compi

Re: [7u-dev] Request for approval: 8059206: (tz) Support tzdata2014i

Approved pending a peer review of the JDK7u changes. regards, Sean. On 01/11/2014 22:19, Aleksej Efimov wrote: Hello, Please, approve a JDK 7u-dev backport of tzdata2014i integration fix. The fix is almost identical to JDK8 with one difference: there is no generic names in JDK7 and changes r

Re: RFR: Currency updates for JDK 7

27695 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

RFR: Currency updates for JDK 7

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 4

Re: [7u-dev] RFA: 8049343: (tz) Support tzdata2014g

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

RFR : 6984762 : Invalid close of file descriptor '-1' in findZoneinfoFile

This issue was fixed in JDK 6 and JDK 8 some time back along with : 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 for some reason, the bad fd close fix never made JDK 7 and I'm looking to fix that now. https://bugs.openjdk.java.net/browse/JDK-6984762 webrev : http://cr.open

Re: RFR: 8038306: (tz) Support tzdata2014b

Looks fine to me. regards, Sean. On 02/04/14 11:55, Aleksej Efimov wrote: Hello, Can I have a review for the latest (2014b) TZ data integration to JDK9. The webrev can be located here [1]. The following set of tests were executed without failures: test/sun/util/calendar test/java/util/Calen

Re: RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time

Looks good Aleksej. A future rule change doesn't necessarily mean a new GMT offset change. Original test logic seemed buggy. regards, Sean. On 12/03/2014 15:06, Aleksej Efimov wrote: Hello, Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java' test bug failure [1] related to th

Re: RFR: 8037012: (tz) Support tzdata2014a

Looks good to me. regards, Sean. On 12/03/2014 15:05, Aleksej Efimov wrote: Hello, Can I have a review for a tzdata2014a [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00 The following test sets were executed on the build with latest tzdata: test/sun/util/calen

Re: RFR: 8030822: (tz) Support tzdata2013i

Looks good to me Aleksej. Hopefully you can get a reviewer from the i18n dev team also. regards, Sean. On 21/01/14 13:17, Aleksej Efimov wrote: Hi, Can I have a review for 2013i timezone data integration [1] to JDK9. There is one change in tzdb that affects naming for "Asia/Amman" timezone:

Re: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes

Looks good here too Aleksej.. in case you need a second reviewer. regards, Sean. On 06/11/2013 17:18, Xueming Shen wrote: Looks fine. thanks! -Sherman On 11/05/2013 03:21 PM, Aleksej Efimov wrote: Sherman, Thank you for a quick review. I totally agree with you on all items. Actually, I misse

Re: RFR: 8027370: (tz) Support tzdata2013h

Looks good to me too Aleksej. regards, Sean. On 08/11/2013 16:42, Xueming Shen wrote: looks fine. I would assume you've also run the corresponding tests at test/closed repo. -Sherman On 11/5/2013 8:38 AM, Aleksej Efimov wrote: Hi, Can I have a review for tzdata2013h integration [1]. The we

Re: Request for approval for 8025255: (tz) Support tzdata2013g

8026772 and 8025255. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022452.html [2] http://cr.openjdk.java.net/~aefimov/8025255/7/8025255_jdk7.patch <http://cr.openjdk.java.net/%7Eaefimov/8025255/7/8025255_jdk7.patch> On 10/24/2013 06:59 PM, Seán Coffey wrote: Good to p

Re: Request for approval for 8025255: (tz) Support tzdata2013g

Good to put the test on ProblemList for short term Aleksej. Approved for 7u-dev. For records, I'm pasting bug ID and jdk8 changeset here again. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8025255 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf regards, Sean. On 24/10/2013 13:56

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ regards, Sean. On 02/09/13 21:07, Alan Bateman wrote: On 02/09/2013 19:06, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Chris - you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. regards, Sean. On 02/09/13 19:15, Chris Hegarty wrote: On 09/02/2013 07:06 PM, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first)

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/13 19:15, Chris Hegarty wrote: On 09/02/2013 07:06 PM, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ The 'javaAWTAccess != null ' checks are redundant. It will

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ regards, Sean. On 02/09/13 16:47, Seán Coffey wrote: Performance regression reported where a high number of threads calling TimeZone.getDefault can run into

RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Performance regression reported where a high number of threads calling TimeZone.getDefault can run into a bottleneck on AppContext accessor calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. Turns out that we're unnecessarily going through the AppContext in certain scenario

Re: RFR JDK-8020054: (tz) Support tzdata2013d

Looks fine to me also Sherman. On a side note, we should look at migrating some closed TZ tests to open repo. I'm not sure why that wasn't done from first day. regards, Sean. On 09/08/2013 08:20, Yuka Kamiya wrote: Hi Sherman, The fix looks good to me. Thanks, -- Yuka (2013/08/09 14:54),

Re: RFR JDK-8013386: (tz) Support tzdata2013c

Thanks for taking care of this Sherman. I was wondering what sort of impact JSR 310 would make on tzdata updates. The Atlantic/Stanley display name issue mentioned is a regular one, we should log a bug against the test file generation scripts. I just had a quick grok of the jdk8 repo. The foll

Review request for 8000529 : Regression : SimpleDateFormat incorrectly parses dates formatted with Z and z pattern letters

Masayoshi, this is a JDK 8 review request for an issue we touched on a good while back. As suggested by you, fix is to clear ZONE_OFFSET field of the calendar being built before attempting to set a DST_OFFSET value. I plan to backport to 7u-dev after a few weeks of soak time. bug report : ht

RFR: 7197187 Currency.isPastCutoverDate should be made more robust

As correctly pointed out by Alan, the 7180362 code fix should be tidied up to not handle RuntimeExceptions. The NullPointerExcepiton and IndexOutOfBoundsException's should not be handled by the Currency.replaceCurrencyData(..) bug report : http://bugs.sun.com/view_bug.do?bug_id=7197187 webrev

Re: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards

I approved the change in jdk8), I don't find any reason for backporting this change into 7u line. Is there any strong reason for backport? Naoto On 9/18/12 10:37 AM, Seán Coffey wrote: > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. > Was it possible to

RFR: CR 7196533 : TimeZone.getDefault() slow due to synchronization bottleneck

Masayoshi, I'm looking to backport this fix which was been soaking in jdk8 for a few months now. Fix is identical with the exception of some comment re-ordering and redeclaring of the javaAWTAccess variable to keep code consistent with jdk8. jdk8 review thread : http://mail.openjdk.java.

Re: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

mezone", tzname); System.setSecurityManager(new SecurityManager()); On 28/11/2012 12:59, Staffan Larsen wrote: Did we conclude that my original change was good, or was there an alternative? Thanks, /Staffan On 27 nov 2012, at 17:02, Seán Coffey wrote: I suspect this test

Re: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

I suspect this test will fail with java agents too, say when doing code coverage during test runs. It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. This test runs in othervm mode by default. Any java agents calling in

RFR : 8002227 : (tz) Support tzdata2012i

a2012i Date: Wed, 07 Nov 2012 10:47:17 +0900 From: Yuka Kamiya To: Seán Coffey CC: i18n-dev Hi Seán, The fix looks good to me. Thanks, -- Yuka (12/11/07 8:18), Seán Coffey wrote: Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i which was released recently.

RFR : 8002227 : (tz) Support tzdata2012i

Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i which was released recently. This request is for jdk8. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002227 webrev : http://cr.openjdk.java.net/~coffeys/webrev.tzdata2012i/

RFF : 7196533 : TimeZone.getDefault() slow due to synchronization bottleneck

Recent changes in java.util.TimeZone created new setter and getter methods for setting and obtaining the defaultTimeZone for VM. Synchronization on these methods has caused some performance issues for VMs making heavy usage of TimeZone.getDefault() Fix is to remove synchronization and make th

Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards

cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. Was it possible to verify this fix on jdk7u Shi Jun ? Any thoughts from i18n reviewers on this one being backported to 7u ? regards, Sean. On 17/09/2012 08:07, Shi Jun Zhang wrote: Hi all, I'd like to request for approval

Re: hg: jdk8/tl/jdk: 7180362: RFE: Implement date cutover functionality for currency.properties file

On 08/09/2012 10:14, Alan Bateman wrote: On 07/09/2012 21:19, sean.cof...@oracle.com wrote: Changeset: fffbb33df102 Author:coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency

Re: Review request : 7180362: RFE: Implement date cutover functionality for currency.properties file

Latest webrev is available here : http://cr.openjdk.java.net/~coffeys/webrev.7180362.3.jdk8/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.3.jdk8/> I've changed code so that ISO 8601 format is now expected. regards, Sean. On 30/08/2012 17:17, Seán Coffey wrote: Stephen

Re: Review request : 7180362: RFE: Implement date cutover functionality for currency.properties file

7;HH:mm:ss Stephen co-spec lead JSR-310 On 28 August 2012 14:48, Seán Coffey wrote: 7180362 deals with an enhancement to allow the JRE specify cutover dates when currency.properties file is provided. I've added the required syntax to the new javadoc comments in Currency class. bug report

Re: Review request : 7180362: RFE: Implement date cutover functionality for currency.properties file

enjdk.java.net/~coffeys/webrev.7180362.2.jdk8/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7180362.2.jdk8/> regards, Sean. Naoto On 8/28/12 6:48 AM, Seán Coffey wrote: 7180362 deals with an enhancement to allow the JRE specify cutover dates when currency.properties file is provided. I&

Review request : 7180362: RFE: Implement date cutover functionality for currency.properties file

7180362 deals with an enhancement to allow the JRE specify cutover dates when currency.properties file is provided. I've added the required syntax to the new javadoc comments in Currency class. bug report :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180362 webrev : http://cr.openjdk.j

RFR : 7167359 (tz) SEGV on solaris if TZ variable not set

review request for issue that arose after 7092679 fix. Without a TZ variable set on solaris, there's possibility for SEGV. Simple fix. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7167359.jdk8/ bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167359 (not visible yet) regards,

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 13/03/2012 09:38, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ Looks okay to me. For bonus points, open, fstat and read should be restarted if interrupted (EINTR). -Alan.

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

15:11, Seán Coffey wrote: Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good. I assume this is the latest: http://cr.openjdk.java.net/~coffeys/w

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good. regards, Sean. On 12/03/12 14:34, Alan Bateman wrote: On 12/03/2012 14:31, Seán Coffey wrot

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Ok - good point on the stat change Alan. I think this is what you're after : http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.2/ regards, Sean. On 12/03/12 11:04, Alan Bateman wrote: On 09/03/2012 16:00, Seán Coffey wrote: Issue seen on somewhat irregular linux system configur