RE: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

September 17, 2019 11:25 PM > To: Martin Buchholz > Cc: Ramanand Patil ; core-libs-dev d...@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

RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

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.

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

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 patch is not clean because: It uses "rearguard" format tzdata from IANA (instead of

RE: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Thank you Martin and Naoto for your reviews. Hi Martin, Currently, we are evaluating the approach for update releases. But in my opinion, it is better to migrate to vanguard format. Regards, Ramanand. From: Martin Buchholz Sent: Tuesday, August 6, 2019 1:57 AM To: Ramanand Patil Cc: core

RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Hi all, Please review the patch for tzdata2019b integration into jdk project(jdk-14). Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 Summary: - This patch uses "vanguard" format tzdata from IANA (instead of rearguard

RE: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

11:19 PM > To: Ramanand Patil ; Andrew John Hughes > ; core-libs-dev@openjdk.java.net; i18n- > d...@openjdk.java.net > Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to > tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk- > 13 > > H

RE: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

Hi Andrew, Thank you for your review. Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ Regards, Ramanand. > -Original Message- > From: Andrew John Hughes > Sent: Saturday, July 6, 2019 9:53 PM > To: Ramanand Patil ; core-libs- > d...@openjdk

RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

Hi all, Please review the patch for tzdata2019a integration into jdk project. Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 https://bugs.openjdk.java.net/browse/JDK-8225580 Summary: - The fix contains cumulative tzdata changes

RE: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Hi Deepak, Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. Regards, Ramanand. -Original Message- From: Naoto Sato Sent: Friday, May 10, 2019 6:12 PM To: Deepak

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

. > -Original Message- > From: Langer, Christoph > Sent: Monday, March 25, 2019 12:42 PM > To: Deepak Kejriwal > Cc: Ramanand Patil ; Naoto Sato > ; core-libs-dev ; > jdk8u-...@openjdk.java.net > Subject: RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 &

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Deepak, In particular, the test TestDateTimeFormatterBuilderWithLocale.java should have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev repos. Also I think, you can omit the second copyright info(from line no. 24) for the same reason. Note: I am not a reviewer for

RFR: 8213085: (tz) Upgrade time-zone data to tzdata2018g

Hi all, Please review the latest TZDATA integration (tzdata2018g) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213085 Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RE: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

; To: Martin Buchholz ; Ramanand Patil > > Cc: core-libs-dev ; i18n-dev d...@openjdk.java.net> > Subject: Re: RFR: 8213016: (tz) Upgrade time-zone data to > tzdata2018f > > +1 > > Naoto > > On 10/26/18 12:38 PM, Martin Buchholz wrote: > > Looks good to me.

RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

Hi all, Please review the latest TZDATA integration (tzdata2018f) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ All the TimeZone related tests are passed after integration. Note: The used tzdata files are from the

RE: Time-zone database issues

Hi Naoto, Thank you for filing the bug. As far as tzdata2018f release is concerned I am going ahead with the integration, with the help of the patch provided here- https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 in rearguard format. [

RFR[jdk8u-dev]: 8134124: sun/security/tools/jarsigner/warnings.sh fails when using Hindi locale

Hi all, Please review this trivial test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8134124 Webrev: http://cr.openjdk.java.net/~rpatil/8134124/webrev.00/ The test is made locale independent now. Regards, Ramanand.

RFR: 8203233: (tz) Upgrade time-zone data to tzdata2018e

Hi all, Please review the latest TZDATA integration (tzdata2018e) to JDK. Bug: https://bugs.openjdk.java.net/browse/JDK-8203233 Webrev: http://cr.openjdk.java.net/~rpatil/8203233/webrev.00/ All the TimeZone related tests are passed after integration. Note: Using the rearguard version of the

RFR: 8200359: (tz) Upgrade time-zone data to tzdata2018d

Hi all, Please review the latest TZDATA integration (tzdata2018d) into JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200359 Webrev: http://cr.openjdk.java.net/~rpatil/8200359/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

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

Hi all, Please review the latest TZDATA integration (tzdata2018c) into JDK10. Bug: https://bugs.openjdk.java.net/browse/JDK-8195837 Webrev: http://cr.openjdk.java.net/~rpatil/8195837/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RE: RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Thank you Daniel and Sean for your reviews. Regards, Ramanand. > -Original Message- > From: Daniel Fuchs > Sent: Wednesday, December 20, 2017 2:43 PM > To: Ramanand Patil <ramanand.pa...@oracle.com>; core-libs-dev d...@openjdk.java.net> > Subject: Re: RFR: J

RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8153955 Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266 Webrev: http://cr.openjdk.java.net/~rpatil/8161266/webrev.00/ Summary(also added to backport bug description): The fix from JDK9

RE: JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c

: Martin Buchholz [mailto:marti...@google.com] Sent: Wednesday, November 08, 2017 12:18 AM To: Ramanand Patil <ramanand.pa...@oracle.com> Cc: Naoto Sato <naoto.s...@oracle.com>; core-libs-dev <core-libs-dev@openjdk.java.net>; i18n-...@openjdk.java.net Subject: Re: JDK10 RFR o

RE: JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c

: Tuesday, November 07, 2017 5:18 AM > To: Ramanand Patil <ramanand.pa...@oracle.com>; core-libs-dev d...@openjdk.java.net>; i18n-...@openjdk.java.net > Subject: Re: JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c > and 8190259: test tck.java.time.zone.TCKZoneRules is broken by t

JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c

Hi all, Please review the latest TZDATA integration (tzdata2017c) to JDK10. Bugs: https://bugs.openjdk.java.net/browse/JDK-8190258 https://bugs.openjdk.java.net/browse/JDK-8190259 Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/ All the TimeZone related tests are passed

RE: tzdata2017c is out

...@google.com] Sent: Tuesday, October 24, 2017 2:05 AM To: i18n-...@openjdk.java.net; core-libs-dev <core-libs-dev@openjdk.java.net>; Ramanand Patil <ramanand.pa...@oracle.com>; Stephen Colebourne <scolebou...@joda.org> Subject: tzdata2017c is out   tzdata2017c came out to

RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type

Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/048738.html JDK10

RE: RFR: 8177449: (tz) Support tzdata2017b

Thank you Martin for the quick review.   Regards, Ramanand.   From: Martin Buchholz [mailto:marti...@google.com] Sent: Thursday, March 30, 2017 12:05 AM To: Ramanand Patil <ramanand.pa...@oracle.com> Cc: i18n-...@openjdk.java.net; core-libs-dev <core-libs-dev@openjdk.java.net>

RFR: 8177449: (tz) Support tzdata2017b

Hi all, Please review the latest TZDATA integration (tzdata2017b) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RFR: 8176044: (tz) Support tzdata2017a

Hi all, Please review the latest TZDATA integration (tzdata2017a) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RE: RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name

Thank you Alan and Kumar. I have just pushed the fix. Regards, Ramanand. -Original Message- From: Kumar Srinivasan Sent: Monday, February 06, 2017 9:54 PM To: Ramanand Patil <ramanand.pa...@oracle.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: RFR: 817

RE: RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name

cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b Regards, Ramanand. -Original Message- From: David Holmes Sent: Monday, February 06, 2017 3:10 AM To: Ramanand Patil <ramanand.pa...@oracle.com>; core-libs-dev <core-libs-

RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name

Hi all, Please review the following trivial bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8173943 Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/ LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.

RE: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

Thank you Kumar and Alan. Just pushed the fix. All the related tests from "core" and "pit" testset are passed. Regards, Ramanand. -Original Message- From: Kumar Srinivasan Sent: Tuesday, January 31, 2017 9:53 PM To: Ramanand Patil <ramanand.pa...@oracle.com> C

RE: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

Thank you Alan. I have eliminated the inner catch block for LinkageError. Here is the updated webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.04 Regards, Ramanand. -Original Message- From: Alan Bateman Sent: Sunday, January 29, 2017 1:06 AM To: Ramanand Patil <ramanand

RE: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

(even when test passes) and to print the final test result message as suggested by Kumar. Regards, Ramanand. -Original Message- From: Kumar Srinivasan Sent: Wednesday, January 25, 2017 9:30 PM To: Ramanand Patil <ramanand.pa...@oracle.com> Cc: Alan Bateman <alan.bate...@oracle.c

RE: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

Hi Kumar, Thank you for the review and suggestions for the test case. Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.02/ Regards, Ramanand. -Original Message- From: Kumar Srinivasan Sent: Tuesday, January 24, 2017 2:50 AM To: Ramanand Patil <ramanand

RE: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

the code back into original loadModuleMainClass - NoClassDefFoundError is replaced by its parent class LinkageError in method loadMainClass Regards, Ramanand. -Original Message- From: Alan Bateman Sent: Friday, January 20, 2017 8:03 PM To: Ramanand Patil <ramanand.pa...@oracle.com>

RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8167063 Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/ Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added

RE: RFR: 8170316: (tz) Support tzdata2016j

Thank you Martin.   Regards, Ramanand. From: Martin Buchholz [mailto:marti...@google.com] Sent: Tuesday, November 29, 2016 12:59 AM To: Ramanand Patil <ramanand.pa...@oracle.com> Cc: i18n-...@openjdk.java.net; core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: RFR:

RE: RFR: 8170316: (tz) Support tzdata2016j

Hi Masayoshi, Sorry, that was an error from my side. Thank you for pointing that out and for your review. [Changed the BugID in Subject now]. Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, November 30, 2016 10:08 AM To: Ramanand Patil <ramanand

RFR: 8169191: (tz) Support tzdata2016j

Hi all, Please review the latest TZDATA integration (tzdata2016j) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8170316 Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK8U. Since tzdata is cumulative, this bug fix backports both the tzdata versions(tzdata2016h+tzdata2016i) into jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev:

RFR: 8169191: (tz) Support tzdata2016i

Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RFR: 8168512: (tz) Support tzdata2016h

Hi all, Please review the latest TZDATA integration (tzdata2016h) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8168512 Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RE: RFR: 8166875: (tz) Support tzdata2016g

ber 05, 2016 8:49 AM To: Ramanand Patil <ramanand.pa...@oracle.com>; Martin Buchholz <marti...@google.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; i18n-...@openjdk.java.net Subject: Re: RFR: 8166875: (tz) Support tzdata2016g Hi Ramanand, I don't think it's appropria

RE: RFR: 8166875: (tz) Support tzdata2016g

;""Yangon (ရန်ကုန်) is a combination of the two words yan (ရန်) and koun (ကုန်), which mean "enemies" and "run out of", respectively. It is also translated as "End of Strife".""" On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Pa

RFR: 8166875: (tz) Support tzdata2016g

HI all, Please review the latest TZDATA integration (tzdata2016g) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ All the TimeZone related tests are passed after integration. [BugID is updated for tests TimeZoneTest.java

RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added int

Hi all, Please review this trivial fix which addresses the mentioned 2 bugs. Bugs: 1. https://bugs.openjdk.java.net/browse/JDK-8160951 2. https://bugs.openjdk.java.net/browse/JDK-8160958 Webrev: http://cr.openjdk.java.net/~rpatil/8160951%2b8160958/webrev.00/ Only test/TEST.groups is modified to

RE: RFR: 8161016: Strange behavior of URLConnection with proxy

/ Regards, Ramanand. -Original Message- From: Aleksey Shipilev [mailto:aleksey.shipi...@gmail.com] Sent: Thursday, August 11, 2016 10:10 PM To: Ramanand Patil; OpenJDK Network Dev list Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8161016: Strange behavior of URLConnection with proxy

RFR: 8161016: Strange behavior of URLConnection with proxy

Hi all, Please review the fix for Bug  - https://bugs.openjdk.java.net/browse/JDK-8161016 Bug Description: When ProxySelector is present, i.e. there is minimum one proxy set (by System Property or System Default or using Custom ProxySelector implementation) connection should be opened through

RE: RFR: 8159684: (tz) Support tzdata2016f

ly 13, 2016 12:14 PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8159684: (tz) Support tzdata2016f I don't think it's appropriate to add 8159684 to TimeZoneTest.java which doesn't test the data changes of 2016e/f at all. I think there should be a

RFR: 8159684: (tz) Support tzdata2016f

Hi all, Please review the latest TZDATA integration (tzdata2016f) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8159684 Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/ All the TimeZone related tests are passed after this integration. Regards, Ramanand.

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Thank you Sean. Updated Webrev: http://cr.openjdk.java.net/~rpatil/8153955/webrev.03/ Regards, Ramanand. -Original Message- From: Seán Coffey Sent: Friday, June 17, 2016 9:34 PM To: Ramanand Patil; Daniel Fuchs; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: Re: RFR

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi All, Gentle reminder... Regards, Ramanand. -Original Message- From: Ramanand Patil Sent: Tuesday, June 14, 2016 9:51 PM To: Daniel Fuchs; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi all, May I request one more review for this bug fix.? Thank you very much Daniel for your review. Regards, Ramanand. -Original Message- From: Daniel Fuchs Sent: Friday, June 10, 2016 7:47 PM To: Ramanand Patil; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: Re: RFR

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

To: Ramanand Patil; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access Hi Ramanand, Thanks for looking into this. 1. FileHander.java: 94 *handler-name.append 95 *specifies whether

RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8153955 Webrev: http://cr.openjdk.java.net/~rpatil/8153955/webrev.00/ Fix: A new configurable java property- "java.util.logging.FileHandler.maxLocks" is added to the FileHandler which can be set in the

RE: RFR: 8151876: (tz) Support tzdata2016d

Sent: Tuesday, May 31, 2016 3:05 PM To: Masayoshi Okutsu; Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016d   Masayoshi, I still think the test adds value. At minimum it identifies timezones which don't have a localis

RE: RFR: 8151876: (tz) Support tzdata2016d

Hi Masayoshi,   Thank you, I will delete this test before pushing the patch.     Regards, Ramanand.   From: Masayoshi Okutsu Sent: Tuesday, May 31, 2016 11:37 AM To: Ramanand Patil; Seán Coffey; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8151876: (tz

RFR: 8151876: (tz) Support tzdata2016d

HI all, Please review the latest TZDATA integration (tzdata2016d) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ Patch Contains: 1. IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and

RE: RFR: 8151876: (tz) Support tzdata2016c

to the test.java.time.format.TestZoneTextPrinterParser.test_ParseText just eliminates the test. Is there an alternate test that the formatter is returning the correct value for the GMT+/- cases? Roger On 4/11/2016 6:59 AM, Ramanand Patil wrote: > Hi all, > > I would like someone from java.time to do a second review for this. > > Rega

RE: RFR: 8151876: (tz) Support tzdata2016c

Hi all, I would like someone from java.time to do a second review for this. Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Tuesday, April 05, 2016 5:09 AM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8151876: (tz

RFR: 8151876: (tz) Support tzdata2016c

Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ All the TimeZone related tests are passed after integration. Please note that this patch includes

RE: RFR: 8151876: (tz) Support tzdata2016b

PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016b Hi Ramanand, What I meant is to remove those new resources so that "GMT+hh:mm" is used for formatting. There may be some tests that require change

RE: RFR: 8151876: (tz) Support tzdata2016b

vsk Summer Time", "ULST", + "Ulyanovsk Time", "ULT"}}, Please let me know if this is fine. Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, March 23, 2016 7:22 PM To: Ramanand

RFR: 8151876: (tz) Support tzdata2016b

Hi all, Please review the latest TZDATA (tzdata2016b) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ All the TimeZone related tests are passed after integration. Please note that, as per the release

RE: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Hi all, May I request one more review for this bug? [Thank you Masayoshi for your review.] Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, February 24, 2016 1:46 PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject

RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in

RE:[PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

Hi all, Please help me in getting this review done. Regards, Ramanand. -Original Message- From: Ramanand Patil Sent: Friday, February 05, 2016 10:46 PM To: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead

RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

Hi all Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8135259 Bug Description: Attempts to resolve a host unknown to the DNS server cause an UnknownHostException stating "unknown error" instead of "Name or service not known". Webrev:

RE: RFR: 8148446: (tz) Support tzdata2016a

Hi Masayoshi/all, Please review the updated Webrev at: http://cr.openjdk.java.net/~rpatil/8148446/webrev.01/ Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Thursday, February 04, 2016 12:17 PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev

RFR: 8148446: (tz) Support tzdata2016a

HI all, Please review the latest TZDATA integration (tzdata2016a) to JDK9. Bug - https://bugs.openjdk.java.net/browse/JDK-8148446 Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

RFR: 8148570: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file

HI all, Please review this trivial fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8148570 Bug Description - While compiling and building TZDB data file(tzdata2016a) when transition rule(for Iran) doesn't have the day-of-week data a null pointer exception is thrown. Webrev -

RE: RFR: 8148570: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file

: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file Hi Ramanand, Is there a specific regression test that can be written for the case? Otherwise, looks fine. Roger On 1/29/2016 12:56 PM, Ramanand Patil wrote: > HI

RE: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Hi all, Please help me in reviewing this test fix. Regards, Ramanand. From: Ramanand Patil Sent: Monday, January 25, 2016 1:05 PM To: i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck

RE: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

nformation is available without Offset. Anyway, I will wait for java.time people to review this change. Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, January 27, 2016 11:23 AM To: Ramanand Patil; i18n-...@openjdk.java.net; core-libs-dev@openjdk.java.n

RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Hi all, Please review the trivial test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8147912 Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale). Webrev:

RE: RFR: JDK-8144988: Unexpected timezone returned after parsing a date

To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date Hi Ramanand, test/java/text/Format/DateFormat/Bug8141243.java: 28 * @run main Bug8141243 29 * @run main/othervm -Djava.locale.providers

RFR: JDK-8144988: Unexpected timezone returned after parsing a date

Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988 Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00 This is basically a backport of JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8141243 JDK9 changeset(for reference):

RFR: 8145388: URLConnection.guessContentTypeFromStream returns image/jpg for some JPEG images

HI all, Please review this small fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145388 Bug Description - For some JPEG images the method java.net.URLConnection#guessContentTypeFromStream will return the MIME type image/jpg, which is not a valid, registered IANA mime type for

RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi Roger,   The added import in DateTimeFormatter.java  is because of the javadocs entry - {@link ChronoLocalDateTime#atZone(ZoneId)}     Regards, Ramanand.   From: Roger Riggs Sent: Monday, December 14, 2015 8:36 PM To: Ramanand Patil; core-libs-dev@openjdk.java.net Cc: i18n

RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

ks, Roger On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > I believe this is suitable for committing, thanks, other reviews welcome! > Stephen > > > > On 10 December 2015 at 15:36, Ramanand Patil < HYPERLINK > "mailto:ramanand.pa...@oracle.com; ramanand.pa...@ora

RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

tests are a little hard to follow. thanks for fixing this Stephen On 9 December 2015 at 07:44, Ramanand Patil <ramanand.pa...@oracle.com> wrote: > HI all, > > > > Please review a fix for Bug - HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8066982"

Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

HI all, Please review a fix for Bug - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts

RE: Code Review for JDK-8141243: Unexpected timezone returned after parsing a date

To: Ramanand Patil; i18n-dev; core-libs-dev; jdk8u-dev Subject: Re: Code Review for JDK-8141243: Unexpected timezone returned after parsing a date Hi Ramanand, I don't think this fix is correct. This change mixes up time zone IDs and display names. SimpleDateFomat should parse only display names