From naoto.sato at oracle.com  Thu Aug  1 00:57:51 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 31 Jul 2019 17:57:51 -0700
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
Message-ID: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8215181

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8215181/webrev.00/

This is to enable "accounting" style currency formatting (negative 
values in parentheses) with CLDR.

Naoto

From thejasvi.v.voniadka at oracle.com  Thu Aug  1 13:42:08 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Thu, 1 Aug 2019 06:42:08 -0700 (PDT)
Subject: <i18n dev> RFR: 8158880:
 test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail
 with zh_CN locale
Message-ID: <fc1172e9-4a94-4d6d-afd1-03323e42706a@default>

Hi,

Request you to please review this change.

JBS:    https://bugs.openjdk.java.net/browse/JDK-8158880 (test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale)

Description:    The test " test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java# test_appendZoneText_parseGenericTimeZonePatterns" fails if run on certain locales (such as "ja"). At present the test does not enforce a specific locale for the DateTimeFormatter, and hence the machine's locale is used as the default. This could cause parsing mismatches when run on non-US locales. The fix is to set the locale explicitly in the test.

Webrev:    http://cr.openjdk.java.net/~vagarwal/8158880/webrev.0




From naoto.sato at oracle.com  Thu Aug  1 16:13:19 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 1 Aug 2019 09:13:19 -0700
Subject: <i18n dev> RFR: 8158880:
 test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail
 with zh_CN locale
In-Reply-To: <fc1172e9-4a94-4d6d-afd1-03323e42706a@default>
References: <fc1172e9-4a94-4d6d-afd1-03323e42706a@default>
Message-ID: <ce736722-cd26-c150-2f52-22f47d84372c@oracle.com>

Looks good to me, Thejasvi.

Naoto

On 8/1/19 6:42 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request you to please review this change.
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8158880 (test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale)
> 
> Description:    The test " test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java# test_appendZoneText_parseGenericTimeZonePatterns" fails if run on certain locales (such as "ja"). At present the test does not enforce a specific locale for the DateTimeFormatter, and hence the machine's locale is used as the default. This could cause parsing mismatches when run on non-US locales. The fix is to set the locale explicitly in the test.
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8158880/webrev.0
> 
> 
> 

From ramanand.patil at oracle.com  Mon Aug  5 08:27:49 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 5 Aug 2019 01:27:49 -0700 (PDT)
Subject: <i18n dev> RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b
Message-ID: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>

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 format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this.
	- As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java.
	  Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3].
	- test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id.
	- The patch has passed all the related testing including JCK.

Notes:
- As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST.
- Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same.


[1] https://bugs.openjdk.java.net/browse/JDK-8212970
[2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
[3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498


Regards,
Ramanand.

From naoto.sato at oracle.com  Mon Aug  5 19:54:51 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 5 Aug 2019 12:54:51 -0700
Subject: <i18n dev> RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
In-Reply-To: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>
References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>
Message-ID: <d995e50a-a780-d14f-f632-db686f29b5b9@oracle.com>

Hi Ramanand,

Looks good to me. Glad that the number of files to review has decreased 
a lot :-)

Naoto

On 8/5/19 1:27 AM, Ramanand Patil wrote:
> 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 format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this.
> 	- As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java.
> 	  Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3].
> 	- test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id.
> 	- The patch has passed all the related testing including JCK.
> 
> Notes:
> - As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST.
> - Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same.
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8212970
> [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498
> 
> 
> Regards,
> Ramanand.
> 

From martinrb at google.com  Mon Aug  5 20:27:26 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 5 Aug 2019 13:27:26 -0700
Subject: <i18n dev> RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
In-Reply-To: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>
References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>
Message-ID: <CA+kOe08vhFQ5CGeAsck6CVJzReKO8Ch2mYzXRoTbANL0XT2wug@mail.gmail.com>

Thanks for the update and redundancy removal.  Looks good to me.

What is the recommendation for older releases?  Migrate to vanguard format
by backporting recent changes or stay on rearguard forever?

On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil <ramanand.patil at oracle.com>
wrote:

> 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 format), as the enhancement bug[1] is fixed now. Many thanks to
> Naoto for this.
>         - As per the latest changes to Palestine zone rules, the
> hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in
> ZoneInfoFile.java.
>           Because of those checks
> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned
> in the bug comment[3].
>         - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set
> ZoneDescriptor.daylight value to "false" for BET zone id.
>         - The patch has passed all the related testing including JCK.
>
> Notes:
> - As per the mail from tzdata maintainers[2] there is a possibility that
> Brazil might not abolish DST.
> - Since the enhancement bug[1] is not fixed in update releases, jdk13u
> will still use the rearguard format tzdata. A separate review request will
> be sent for the same.
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212970
> [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
> [3]
> https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498
>
>
> Regards,
> Ramanand.
>

From ramanand.patil at oracle.com  Tue Aug  6 04:44:02 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 5 Aug 2019 21:44:02 -0700 (PDT)
Subject: <i18n dev> RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
In-Reply-To: <CA+kOe08vhFQ5CGeAsck6CVJzReKO8Ch2mYzXRoTbANL0XT2wug@mail.gmail.com>
References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default>
 <CA+kOe08vhFQ5CGeAsck6CVJzReKO8Ch2mYzXRoTbANL0XT2wug@mail.gmail.com>
Message-ID: <ed6156a6-be3d-4d83-9cfc-50c4512c8c5b@default>

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 <martinrb at google.com> 
Sent: Tuesday, August 6, 2019 1:57 AM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev <i18n-dev at openjdk.java.net>
Subject: Re: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Thanks for the update and redundancy removal.? Looks good to me.

What is the recommendation for older releases?? Migrate to vanguard format by backporting recent changes or stay on rearguard forever?

On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil <mailto:ramanand.patil at oracle.com> wrote:
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 format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this.
? ? ? ? - As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java.
? ? ? ? ? Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3].
? ? ? ? - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id.
? ? ? ? - The patch has passed all the related testing including JCK.

Notes:
- As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST.
- Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same.


[1] https://bugs.openjdk.java.net/browse/JDK-8212970
[2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
[3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498


Regards,
Ramanand.

From ramanand.patil at oracle.com  Tue Aug  6 05:57:47 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 5 Aug 2019 22:57:47 -0700 (PDT)
Subject: <i18n dev> [13u]: RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
Message-ID: <c39b043c-38f3-437f-bbca-a1851c1ac2a5@default>

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 vanguard format), as the enhancement bug[1] is not fixed in jdk13u.
The patch has passed all the related testing including JCK.

Note: As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST.


[1] https://bugs.openjdk.java.net/browse/JDK-8212970
[2] https://mm.icann.org/pipermail/tz/2019-July/028344.html


Regards,
Ramanand.

From sean.coffey at oracle.com  Tue Aug  6 15:13:54 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 6 Aug 2019 16:13:54 +0100
Subject: <i18n dev> [13u]: RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
In-Reply-To: <c39b043c-38f3-437f-bbca-a1851c1ac2a5@default>
References: <c39b043c-38f3-437f-bbca-a1851c1ac2a5@default>
Message-ID: <ec099fd3-6dfe-428b-ec45-f55a993592e4@oracle.com>

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 patch is not clean because: It uses "rearguard" format tzdata from IANA (instead of vanguard format), as the enhancement bug[1] is not fixed in jdk13u.
> The patch has passed all the related testing including JCK.
>
> Note: As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST.
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212970
> [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
>
>
> Regards,
> Ramanand.

From naoto.sato at oracle.com  Tue Aug  6 15:55:11 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 6 Aug 2019 08:55:11 -0700
Subject: <i18n dev> [13u]: RFR: 8228469: (tz) Upgrade time-zone data to
	tzdata2019b
In-Reply-To: <ec099fd3-6dfe-428b-ec45-f55a993592e4@oracle.com>
References: <c39b043c-38f3-437f-bbca-a1851c1ac2a5@default>
 <ec099fd3-6dfe-428b-ec45-f55a993592e4@oracle.com>
Message-ID: <657b66b4-a2f8-0edc-4d7b-37daf6d6a2be@oracle.com>

+1

Naoto

On 8/6/19 8:13 AM, Se?n Coffey wrote:
> 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 patch is not clean because: It uses "rearguard" format tzdata from 
>> IANA (instead of vanguard format), as the enhancement bug[1] is not 
>> fixed in jdk13u.
>> The patch has passed all the related testing including JCK.
>>
>> Note: As per the mail from tzdata maintainers[2] there is a 
>> possibility that Brazil might not abolish DST.
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8212970
>> [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html
>>
>>
>> Regards,
>> Ramanand.

From naoto.sato at oracle.com  Wed Aug  7 20:12:17 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 7 Aug 2019 13:12:17 -0700
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
In-Reply-To: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
Message-ID: <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>

Ping.

Naoto

On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8215181
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
> 
> This is to enable "accounting" style currency formatting (negative 
> values in parentheses) with CLDR.
> 
> Naoto

From lance.andersen at oracle.com  Wed Aug  7 20:17:26 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 7 Aug 2019 16:17:26 -0400
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
In-Reply-To: <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>
References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
 <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>
Message-ID: <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com>

Hi Naoto,

I looked over the proposed changes and the bug.  They seem reasonable to me.

Best
Lance
> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com wrote:
> 
> Ping.
> 
> Naoto
> 
> On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote:
>> Hi,
>> Please review the fix to the following issue:
>> https://bugs.openjdk.java.net/browse/JDK-8215181
>> The proposed changeset is located at:
>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
>> This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR.
>> Naoto

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From lance.andersen at oracle.com  Wed Aug  7 20:20:52 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 7 Aug 2019 16:20:52 -0400
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
In-Reply-To: <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com>
References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
 <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>
 <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com>
Message-ID: <A94C85EB-7D53-4F42-8160-E4A94CA04B8D@oracle.com>

Hi again Naoto,

I meant to ask is there a CSR due to the change in the javadoc for NumberFormat?  If not, there probably should


> On Aug 7, 2019, at 4:17 PM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi Naoto,
> 
> I looked over the proposed changes and the bug.  They seem reasonable to me.
> 
> Best
> Lance
>> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com wrote:
>> 
>> Ping.
>> 
>> Naoto
>> 
>> On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>> Please review the fix to the following issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8215181
>>> The proposed changeset is located at:
>>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
>>> This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR.
>>> Naoto
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Wed Aug  7 20:24:29 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 7 Aug 2019 13:24:29 -0700
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
In-Reply-To: <A94C85EB-7D53-4F42-8160-E4A94CA04B8D@oracle.com>
References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
 <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>
 <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com>
 <A94C85EB-7D53-4F42-8160-E4A94CA04B8D@oracle.com>
Message-ID: <3a190aa4-cf6b-ba1c-4dfb-77bdea5b3712@oracle.com>

Thanks for the review, Lance.

Yes, CSR is needed and it is already approved:

https://bugs.openjdk.java.net/browse/JDK-8218770

Naoto

On 8/7/19 1:20 PM, Lance Andersen wrote:
> Hi again Naoto,
> 
> I meant to ask is there a CSR due to the change in the javadoc for 
> NumberFormat? ?If not, there probably should
> 
> 
>> On Aug 7, 2019, at 4:17 PM, Lance Andersen <lance.andersen at oracle.com 
>> <mailto:lance.andersen at oracle.com>> wrote:
>>
>> Hi Naoto,
>>
>> I looked over the proposed changes and the bug. ?They seem reasonable 
>> to me.
>>
>> Best
>> Lance
>>> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com 
>>> <mailto:naoto.sato at oracle.com> wrote:
>>>
>>> Ping.
>>>
>>> Naoto
>>>
>>> On 7/31/19 5:57 PM, naoto.sato at oracle.com 
>>> <mailto:naoto.sato at oracle.com> wrote:
>>>> Hi,
>>>> Please review the fix to the following issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8215181
>>>> The proposed changeset is located at:
>>>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
>>>> This is to enable "accounting" style currency formatting (negative 
>>>> values in parentheses) with CLDR.
>>>> Naoto
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>> <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From lance.andersen at oracle.com  Wed Aug  7 20:26:56 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 7 Aug 2019 16:26:56 -0400
Subject: <i18n dev> [14] RFR: 8215181: Accounting currency format support
In-Reply-To: <3a190aa4-cf6b-ba1c-4dfb-77bdea5b3712@oracle.com>
References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com>
 <fa5d1375-fbc2-7551-8c4a-5d306c1bad78@oracle.com>
 <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com>
 <A94C85EB-7D53-4F42-8160-E4A94CA04B8D@oracle.com>
 <3a190aa4-cf6b-ba1c-4dfb-77bdea5b3712@oracle.com>
Message-ID: <BF00136C-88D3-4A2D-874A-2062708670C2@oracle.com>

awesome, I must have missed it thinking it was a bug when I reviewed the bug itself (long day :-) ) ?.

> On Aug 7, 2019, at 4:24 PM, naoto.sato at oracle.com wrote:
> 
> Thanks for the review, Lance.
> 
> Yes, CSR is needed and it is already approved:
> 
> https://bugs.openjdk.java.net/browse/JDK-8218770
> 
> Naoto
> 
> On 8/7/19 1:20 PM, Lance Andersen wrote:
>> Hi again Naoto,
>> I meant to ask is there a CSR due to the change in the javadoc for NumberFormat?  If not, there probably should
>>> On Aug 7, 2019, at 4:17 PM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>> 
>>> Hi Naoto,
>>> 
>>> I looked over the proposed changes and the bug.  They seem reasonable to me.
>>> 
>>> Best
>>> Lance
>>>> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com <mailto:naoto.sato at oracle.com> wrote:
>>>> 
>>>> Ping.
>>>> 
>>>> Naoto
>>>> 
>>>> On 7/31/19 5:57 PM, naoto.sato at oracle.com <mailto:naoto.sato at oracle.com> wrote:
>>>>> Hi,
>>>>> Please review the fix to the following issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8215181
>>>>> The proposed changeset is located at:
>>>>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
>>>>> This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR.
>>>>> Naoto
>>> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com>
>>> 
>>> 
>>> 
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From thejasvi.v.voniadka at oracle.com  Thu Aug  8 00:55:44 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Wed, 7 Aug 2019 17:55:44 -0700 (PDT)
Subject: <i18n dev> RFR: 8158880:
 test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail
 with zh_CN locale
In-Reply-To: <ce736722-cd26-c150-2f52-22f47d84372c@oracle.com>
References: <fc1172e9-4a94-4d6d-afd1-03323e42706a@default>
 <ce736722-cd26-c150-2f52-22f47d84372c@oracle.com>
Message-ID: <d152336d-f13b-42d1-9261-c10fc3b6bda7@default>

Hi Naoto,

Thank you for the review. This change has now been pushed.



-----Original Message-----
From: Naoto Sato 
Sent: Thursday, August 01, 2019 9:43 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8158880: test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Looks good to me, Thejasvi.

Naoto

On 8/1/19 6:42 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request you to please review this change.
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8158880 (test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale)
> 
> Description:    The test " test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java# test_appendZoneText_parseGenericTimeZonePatterns" fails if run on certain locales (such as "ja"). At present the test does not enforce a specific locale for the DateTimeFormatter, and hence the machine's locale is used as the default. This could cause parsing mismatches when run on non-US locales. The fix is to set the locale explicitly in the test.
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8158880/webrev.0
> 
> 
> 

From naoto.sato at oracle.com  Thu Aug 29 19:42:51 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 29 Aug 2019 12:42:51 -0700
Subject: <i18n dev> [14] RFR: 8229831: Upgrade
 Character.isUnicodeIdentifierStart/Part() methods to the latest standard
Message-ID: <13d9f962-9cef-afca-3bdf-eaa93fe6721a@oracle.com>

Hi,

Please review the proposed modifications to the methods in 
java.lang.Character class. The CSR is located here:

https://bugs.openjdk.java.net/browse/JDK-8230188

It mainly intends to clarify the spec of the Unicode Identifier methods, 
by supplying the corresponding Unicode Standard Annex #31 explanations. 
Also, it intends to upgrade the current implementation to the latest 
12.0 level. Here is the proposed implementation changes:

https://cr.openjdk.java.net/~naoto/8229831/webrev.00/

The CSR is intentionally left as draft so that I can gather/reflect 
opinions from this list.

Naoto