From naoto.sato at oracle.com  Tue Apr  7 17:52:17 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 7 Apr 2020 10:52:17 -0700
Subject: <i18n dev> [15] RFR: 8242010: Upgrade IANA Language Subtag Registry
 to Version 2020-04-01
Message-ID: <cc3dcac4-99b3-52f2-f642-7a3e79d661a9@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

Besides the upgrade of the data file, I fixed the issue where 
EquivMapsGenerator had been ignoring "extlang" tag. Now it correctly 
maps the extlang, such as "zh-cmn" to its preferred language (in this 
case, "cmn") tag.

Naoto

From naoto.sato at oracle.com  Wed Apr  8 17:29:16 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 8 Apr 2020 10:29:16 -0700
Subject: <i18n dev> [15] RFR (XXS): 8242337: javadoc typo in
 NumberFormat::setMinimumFractionDigits
Message-ID: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com>

Hello,

Please review the fix to the following issue:

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

Here is the proposed diff:

---
diff -r 706df347bcc2 src/java.base/share/classes/java/text/NumberFormat.java
--- a/src/java.base/share/classes/java/text/NumberFormat.java
+++ b/src/java.base/share/classes/java/text/NumberFormat.java
@@ -865,7 +865,7 @@
       * Sets the minimum number of digits allowed in the fraction 
portion of a
       * number. minimumFractionDigits must be &le; 
maximumFractionDigits.  If the
       * new value for minimumFractionDigits exceeds the current value
-     * of maximumFractionDigits, then maximumIntegerDigits will also be 
set to
+     * of maximumFractionDigits, then maximumFractionDigits will also 
be set to
       * the new value
       *
       * @param newValue the minimum number of fraction digits to be 
shown; if
---

It is simply fixing a typo (possibly a copy/paste mistake). Thanks to 
Martin for finding this.

Naoto

From lance.andersen at oracle.com  Wed Apr  8 17:30:50 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 8 Apr 2020 13:30:50 -0400
Subject: <i18n dev> [15] RFR (XXS): 8242337: javadoc typo in
 NumberFormat::setMinimumFractionDigits
In-Reply-To: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com>
References: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com>
Message-ID: <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com>

+1

> On Apr 8, 2020, at 1:29 PM, naoto.sato at oracle.com wrote:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8242337
> 
> Here is the proposed diff:
> 
> ---
> diff -r 706df347bcc2 src/java.base/share/classes/java/text/NumberFormat.java
> --- a/src/java.base/share/classes/java/text/NumberFormat.java
> +++ b/src/java.base/share/classes/java/text/NumberFormat.java
> @@ -865,7 +865,7 @@
>      * Sets the minimum number of digits allowed in the fraction portion of a
>      * number. minimumFractionDigits must be &le; maximumFractionDigits.  If the
>      * new value for minimumFractionDigits exceeds the current value
> -     * of maximumFractionDigits, then maximumIntegerDigits will also be set to
> +     * of maximumFractionDigits, then maximumFractionDigits will also be set to
>      * the new value
>      *
>      * @param newValue the minimum number of fraction digits to be shown; if
> ---
> 
> It is simply fixing a typo (possibly a copy/paste mistake). Thanks to Martin for finding this.
> 
> 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 martinrb at google.com  Wed Apr  8 18:22:45 2020
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Apr 2020 11:22:45 -0700
Subject: <i18n dev> [15] RFR (XXS): 8242337: javadoc typo in
	NumberFormat::setMinimumFractionDigits
In-Reply-To: <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com>
References: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com>
 <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com>
Message-ID: <CA+kOe09_+VSOsFa=WqJkREZ2scGRNo+wYD_yL1ZvzFoa_ASq0A@mail.gmail.com>

+1 !

From takiguc at linux.vnet.ibm.com  Tue Apr 21 01:37:57 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 21 Apr 2020 10:37:57 +0900
Subject: <i18n dev> RFR: 8242541: Small charset issues (ISO8859-16,
 x-eucJP-Open, x-IBM834 and x-IBM949C)
Message-ID: <0aba3a0278ee3c834a012106cac3e66b@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8242541
Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.00/

I applied following changes:
* Missing historical name alias in ISO8859-16
* Typo hisname on x-eucJP-Open
* x-IBM834 and x-IBM949C charset source codes should be template style

I appreciate your feedback and suggestions.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From naoto.sato at oracle.com  Wed Apr 22 15:54:01 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 Apr 2020 08:54:01 -0700
Subject: <i18n dev> RFR: 8242541: Small charset issues (ISO8859-16,
 x-eucJP-Open, x-IBM834 and x-IBM949C)
In-Reply-To: <0aba3a0278ee3c834a012106cac3e66b@linux.vnet.ibm.com>
References: <0aba3a0278ee3c834a012106cac3e66b@linux.vnet.ibm.com>
Message-ID: <56bdfe6b-5dcf-fb16-4595-d0f9a5fee25c@oracle.com>

Hi Takiguchi-san,

Change looks good. I'd expect a test case in 
open/test/jdk/java/nio/charset/Charset/RegisteredCharsets.java for the 
added "ISO8859_16" alias.

Naoto

On 4/20/20 6:37 PM, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242541
> Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.00/
> 
> I applied following changes:
> * Missing historical name alias in ISO8859-16
> * Typo hisname on x-eucJP-Open
> * x-IBM834 and x-IBM949C charset source codes should be template style
> 
> I appreciate your feedback and suggestions.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From kiran.sidhartha.ravikumar at oracle.com  Mon Apr 27 11:13:11 2020
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Mon, 27 Apr 2020 12:13:11 +0100
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
	tzdata2020a
Message-ID: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>

Hello All,


Please review the patch for tzdata2020a integration into jdk.

Release details can be found here:

http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html


Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8243541


The patch has passed all the related testing including JCK and uses 
vanguard format tzdata.


Thanks,

Kiran



From martinrb at google.com  Mon Apr 27 14:16:40 2020
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Apr 2020 07:16:40 -0700
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
	tzdata2020a
In-Reply-To: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
Message-ID: <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>

Hi Kiran,

Thanks for working on this update so promptly.

The innocent renaming of America/Godthab to America/Nuuk is causing much
trouble.
Since it's a renaming, both names remain and I expected them to have the
same metadata.
So I expected the entries in TimeZoneNames.java and the translations in
e.g.TimeZoneNames_de.java to have parallel entries for both names.
Which is what happened with Asia/Rangoon rename to Asia/Yangon.
Consider the output of
 $ find . -type f -name '*.java' | xargs grep -E 'Asia/(Rangoon|Yangon)'

(I wish IANA would coordinate their tzdata releases with ICU CLDR releases,
but apparently they don't)

(I help keep Google's java programs up to date with tzdata)

On Mon, Apr 27, 2020 at 4:21 AM Kiran Ravikumar <
kiran.sidhartha.ravikumar at oracle.com> wrote:

> Hello All,
>
>
> Please review the patch for tzdata2020a integration into jdk.
>
> Release details can be found here:
>
> http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html
>
>
> Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
>
>
> The patch has passed all the related testing including JCK and uses
> vanguard format tzdata.
>
>
> Thanks,
>
> Kiran
>
>
>

From naoto.sato at oracle.com  Mon Apr 27 16:36:45 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Apr 2020 09:36:45 -0700
Subject: <i18n dev> [15] RFR: 8243664: JavaDoc of CompactNumberFormat points
 to wrong enum
Message-ID: <7290c23f-ce51-2960-7ada-f234d865ecea@oracle.com>

Hello,

Please review this small doc fix to the following issue:

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

Here is the diff:

---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java 
2020-04-27 09:09:14.000000000 -0700
+++ new/src/java.base/share/classes/java/text/CompactNumberFormat.java 
2020-04-27 09:09:14.000000000 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -206,7 +206,7 @@
   * {@link java.math.RoundingMode} for formatting.  By default, it uses
   * {@link java.math.RoundingMode#HALF_EVEN RoundingMode.HALF_EVEN}.
   *
- * @see CompactNumberFormat.Style
+ * @see NumberFormat.Style
   * @see NumberFormat
   * @see DecimalFormat
   * @since 12
---

javadoc is clever enough to convert it to correct NumberFormat.Style 
link, but still this should be corrected.

Naoto

From gnu.andrew at redhat.com  Mon Apr 27 17:39:30 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 27 Apr 2020 18:39:30 +0100
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
 tzdata2020a
In-Reply-To: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
Message-ID: <ef485c9f-aa3b-0657-d4e6-3d5c15fa3796@redhat.com>



On 27/04/2020 12:13, Kiran Ravikumar wrote:
> Hello All,
> 
> 
> Please review the patch for tzdata2020a integration into jdk.
> 
> Release details can be found here:
> 
> http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html
> 
> 
> Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
> 
> 
> The patch has passed all the related testing including JCK and uses
> vanguard format tzdata.
> 
> 
> Thanks,
> 
> Kiran
> 
> 

First of all, I'd like to concur with Martin in thanking you for working
on this so quickly. The new zone got flagged as our system tzdata update
was being prepared and I was able to already find a bug filed for
tzdata2020a. I was about to e-mail you to ask your progress on it, then
thought to check the mailing list first. I was happily surprised to find
the patch already written and posted for review! :-)

The changes look fine to me. It would be good to get the translations in
for America/Nuuk, but, for the time being, at least we have the fallback
case so the JDK doesn't crash if asked to print that timezone.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From huizhe.wang at oracle.com  Mon Apr 27 17:54:21 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 27 Apr 2020 10:54:21 -0700
Subject: <i18n dev> [15] RFR: 8243664: JavaDoc of CompactNumberFormat
 points to wrong enum
In-Reply-To: <7290c23f-ce51-2960-7ada-f234d865ecea@oracle.com>
References: <7290c23f-ce51-2960-7ada-f234d865ecea@oracle.com>
Message-ID: <c7dfde3d-3d06-5c93-7b3a-108d3772b52e@oracle.com>

+1.

Indeed, the resulting javadoc was fine :-)


Best,

Joe


On 4/27/2020 9:36 AM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review this small doc fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8243664
>
> Here is the diff:
>
> ---
> --- old/src/java.base/share/classes/java/text/CompactNumberFormat.java 
> 2020-04-27 09:09:14.000000000 -0700
> +++ new/src/java.base/share/classes/java/text/CompactNumberFormat.java 
> 2020-04-27 09:09:14.000000000 -0700
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -206,7 +206,7 @@
> ? * {@link java.math.RoundingMode} for formatting.? By default, it uses
> ? * {@link java.math.RoundingMode#HALF_EVEN RoundingMode.HALF_EVEN}.
> ? *
> - * @see CompactNumberFormat.Style
> + * @see NumberFormat.Style
> ? * @see NumberFormat
> ? * @see DecimalFormat
> ? * @since 12
> ---
>
> javadoc is clever enough to convert it to correct NumberFormat.Style 
> link, but still this should be corrected.
>
> Naoto

From kiran.sidhartha.ravikumar at oracle.com  Mon Apr 27 18:19:28 2020
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Mon, 27 Apr 2020 19:19:28 +0100
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
	tzdata2020a
In-Reply-To: <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
 <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>
Message-ID: <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>

Hi Martin and Andrew,


Thanks for the review and providing a direction towards updating the 
translations.


Here is an updated webrev with the changes:

http://cr.openjdk.java.net/~kravikumar/8243541/webrev/


All associated tests pass. Please let me know if they look alright.


Thanks,

Kiran

On 27/04/2020 15:16, Martin Buchholz wrote:
> Hi Kiran,
>
> Thanks for working on this update so promptly.
>
> The innocent renaming of America/Godthab to America/Nuuk is causing 
> much trouble.
> Since it's a renaming, both names remain and I expected them to have 
> the same metadata.
> So I expected the entries in TimeZoneNames.java and the translations 
> in e.g.TimeZoneNames_de.java to have parallel entries for both names.
> Which is what happened with Asia/Rangoon rename to Asia/Yangon.
> Consider the output of
> ?$ find . -type f -name '*.java' | xargs grep -E 'Asia/(Rangoon|Yangon)'
>
> (I wish IANA would coordinate their tzdata releases with ICU CLDR 
> releases, but apparently they don't)
>
> (I help keep Google's java programs up to date with tzdata)
>
> On Mon, Apr 27, 2020 at 4:21 AM Kiran Ravikumar 
> <kiran.sidhartha.ravikumar at oracle.com 
> <mailto:kiran.sidhartha.ravikumar at oracle.com>> wrote:
>
>     Hello All,
>
>
>     Please review the patch for tzdata2020a integration into jdk.
>
>     Release details can be found here:
>
>     http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html
>     <https://urldefense.com/v3/__http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html__;!!GqivPVa7Brio!PGqR3RfBtyodUFrLtWqpA28agMmn_GtHHtKh8oegq3ePykB5KcxVpzelGnZjTxeLKvzw6K2xqoo$>
>
>
>     Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
>
>
>     The patch has passed all the related testing including JCK and uses
>     vanguard format tzdata.
>
>
>     Thanks,
>
>     Kiran
>
>

From martinrb at google.com  Mon Apr 27 18:55:14 2020
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Apr 2020 11:55:14 -0700
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
	tzdata2020a
In-Reply-To: <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
 <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>
 <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
Message-ID: <CA+kOe0-CqmvnfhDOGjCxoDOLn8DJ=kTrc3S9ot-1QH9LvME-Eg@mail.gmail.com>

Thanks.  This looks good.

How the tzdata updates get done has always been a mystery to me.
If you've written any helper scripts or process docs, checking those
in as well (but which directory?) might be useful.
(I maintain such things at Google, but they are not very useful for
you - too full of Googleisms.)

On Mon, Apr 27, 2020 at 11:19 AM Kiran Ravikumar
<kiran.sidhartha.ravikumar at oracle.com> wrote:
>
> Hi Martin and Andrew,
>
>
> Thanks for the review and providing a direction towards updating the translations.
>
>
> Here is an updated webrev with the changes:
>
> http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
>
>
> All associated tests pass. Please let me know if they look alright.
>
>
> Thanks,
>
> Kiran
>
> On 27/04/2020 15:16, Martin Buchholz wrote:
>
> Hi Kiran,
>
> Thanks for working on this update so promptly.
>
> The innocent renaming of America/Godthab to America/Nuuk is causing much trouble.
> Since it's a renaming, both names remain and I expected them to have the same metadata.
> So I expected the entries in TimeZoneNames.java and the translations in e.g.TimeZoneNames_de.java to have parallel entries for both names.
> Which is what happened with Asia/Rangoon rename to Asia/Yangon.
> Consider the output of
>  $ find . -type f -name '*.java' | xargs grep -E 'Asia/(Rangoon|Yangon)'
>
> (I wish IANA would coordinate their tzdata releases with ICU CLDR releases, but apparently they don't)
>
> (I help keep Google's java programs up to date with tzdata)
>
> On Mon, Apr 27, 2020 at 4:21 AM Kiran Ravikumar <kiran.sidhartha.ravikumar at oracle.com> wrote:
>>
>> Hello All,
>>
>>
>> Please review the patch for tzdata2020a integration into jdk.
>>
>> Release details can be found here:
>>
>> http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html
>>
>>
>> Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
>>
>>
>> The patch has passed all the related testing including JCK and uses
>> vanguard format tzdata.
>>
>>
>> Thanks,
>>
>> Kiran
>>
>>

From naoto.sato at oracle.com  Mon Apr 27 20:09:56 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 27 Apr 2020 13:09:56 -0700
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
 tzdata2020a
In-Reply-To: <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
 <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>
 <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
Message-ID: <2104a448-fa04-fbdf-696e-9278d9e8e9a1@oracle.com>

Looks OK to me. Thanks for the update.

Naoto

On 4/27/20 11:19 AM, Kiran Ravikumar wrote:
> Hi Martin and Andrew,
> 
> 
> Thanks for the review and providing a direction towards updating the 
> translations.
> 
> 
> Here is an updated webrev with the changes:
> 
> http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
> 
> 
> All associated tests pass. Please let me know if they look alright.
> 
> 
> Thanks,
> 
> Kiran
> 
> On 27/04/2020 15:16, Martin Buchholz wrote:
>> Hi Kiran,
>>
>> Thanks for working on this update so promptly.
>>
>> The innocent renaming of America/Godthab to America/Nuuk is causing 
>> much trouble.
>> Since it's a renaming, both names remain and I expected them to have 
>> the same metadata.
>> So I expected the entries in TimeZoneNames.java and the translations 
>> in e.g.TimeZoneNames_de.java to have parallel entries for both names.
>> Which is what happened with Asia/Rangoon rename to Asia/Yangon.
>> Consider the output of
>> ?$ find . -type f -name '*.java' | xargs grep -E 'Asia/(Rangoon|Yangon)'
>>
>> (I wish IANA would coordinate their tzdata releases with ICU CLDR 
>> releases, but apparently they don't)
>>
>> (I help keep Google's java programs up to date with tzdata)
>>
>> On Mon, Apr 27, 2020 at 4:21 AM Kiran Ravikumar 
>> <kiran.sidhartha.ravikumar at oracle.com 
>> <mailto:kiran.sidhartha.ravikumar at oracle.com>> wrote:
>>
>> ??? Hello All,
>>
>>
>> ??? Please review the patch for tzdata2020a integration into jdk.
>>
>> ??? Release details can be found here:
>>
>> ??? http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html
>>     
>> <https://urldefense.com/v3/__http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html__;!!GqivPVa7Brio!PGqR3RfBtyodUFrLtWqpA28agMmn_GtHHtKh8oegq3ePykB5KcxVpzelGnZjTxeLKvzw6K2xqoo$> 
>>
>>
>>
>> ??? Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
>>
>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8243541
>>
>>
>> ??? The patch has passed all the related testing including JCK and uses
>> ??? vanguard format tzdata.
>>
>>
>> ??? Thanks,
>>
>> ??? Kiran
>>
>>

From takiguc at linux.vnet.ibm.com  Tue Apr 28 18:41:42 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 29 Apr 2020 03:41:42 +0900
Subject: <i18n dev> RFR: 8242541: Small charset issues (ISO8859-16,
 x-eucJP-Open, x-IBM834 and x-IBM949C)
In-Reply-To: <56bdfe6b-5dcf-fb16-4595-d0f9a5fee25c@oracle.com>
References: <0aba3a0278ee3c834a012106cac3e66b@linux.vnet.ibm.com>
 <56bdfe6b-5dcf-fb16-4595-d0f9a5fee25c@oracle.com>
Message-ID: <d045196871a14f390a9c5ca3bab129ca@linux.vnet.ibm.com>

Hello Naoto.

Thank you for your attention.
And I'm sorry about bad response.

I added ISO8859_16 entry into 
test/jdk/java/nio/charset/Charset/RegisteredCharsets.java

Could you review the fix again ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8242541
Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.01/

Thanks,
Ichiroh Takiguchi

On 2020-04-23 00:54, naoto.sato at oracle.com wrote:
> Hi Takiguchi-san,
> 
> Change looks good. I'd expect a test case in
> open/test/jdk/java/nio/charset/Charset/RegisteredCharsets.java for the
> added "ISO8859_16" alias.
> 
> Naoto
> 
> On 4/20/20 6:37 PM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242541
>> Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.00/
>> 
>> I applied following changes:
>> * Missing historical name alias in ISO8859-16
>> * Typo hisname on x-eucJP-Open
>> * x-IBM834 and x-IBM949C charset source codes should be template style
>> 
>> I appreciate your feedback and suggestions.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Tue Apr 28 20:46:38 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 28 Apr 2020 13:46:38 -0700
Subject: <i18n dev> RFR: 8242541: Small charset issues (ISO8859-16,
 x-eucJP-Open, x-IBM834 and x-IBM949C)
In-Reply-To: <d045196871a14f390a9c5ca3bab129ca@linux.vnet.ibm.com>
References: <0aba3a0278ee3c834a012106cac3e66b@linux.vnet.ibm.com>
 <56bdfe6b-5dcf-fb16-4595-d0f9a5fee25c@oracle.com>
 <d045196871a14f390a9c5ca3bab129ca@linux.vnet.ibm.com>
Message-ID: <8f856340-4554-b96a-0393-2e475e52bd01@oracle.com>

Looks good.

Naoto

On 4/28/20 11:41 AM, Ichiroh Takiguchi wrote:
> Hello Naoto.
> 
> Thank you for your attention.
> And I'm sorry about bad response.
> 
> I added ISO8859_16 entry into 
> test/jdk/java/nio/charset/Charset/RegisteredCharsets.java
> 
> Could you review the fix again ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242541
> Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.01/
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2020-04-23 00:54, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>>
>> Change looks good. I'd expect a test case in
>> open/test/jdk/java/nio/charset/Charset/RegisteredCharsets.java for the
>> added "ISO8859_16" alias.
>>
>> Naoto
>>
>> On 4/20/20 6:37 PM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242541
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.00/
>>>
>>> I applied following changes:
>>> * Missing historical name alias in ISO8859-16
>>> * Typo hisname on x-eucJP-Open
>>> * x-IBM834 and x-IBM949C charset source codes should be template style
>>>
>>> I appreciate your feedback and suggestions.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.

From gnu.andrew at redhat.com  Wed Apr 29 15:48:52 2020
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 29 Apr 2020 16:48:52 +0100
Subject: <i18n dev> RFR [15] 8243541: (tz) Upgrade time-zone data to
	tzdata2020a
In-Reply-To: <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
References: <fb11792a-6aef-7806-903b-a3a48c311690@oracle.com>
 <CA+kOe0_808RBjPEy6C4yvb4JLeoJ9zPEmoBprDCfXipk+P45XA@mail.gmail.com>
 <c7a49e75-ad65-78df-1729-bb2babb645de@oracle.com>
Message-ID: <c72abfa6-2ad1-df96-9fcc-bd30136329a8@redhat.com>



On 27/04/2020 19:19, Kiran Ravikumar wrote:
> Hi Martin and Andrew,
> 
> 
> Thanks for the review and providing a direction towards updating the
> translations.
> 
> 
> Here is an updated webrev with the changes:
> 
> http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
> 
> 
> All associated tests pass. Please let me know if they look alright.
> 
> 
> Thanks,
> 
> Kiran
> 

Looks good to me. Now we have a translation for Nuuk in all the
languages for which we had Godthab translations, and the zones are
tested too.

Thumbs up from me!

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From naoto.sato at oracle.com  Wed Apr 29 22:18:26 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 Apr 2020 15:18:26 -0700
Subject: <i18n dev> [15] RFR: 8244152: Remove unnecessary hash map resize in
 LocaleProviderAdapters
Message-ID: <e59313a6-6b7e-6085-dc53-d4fe8f460ae4@oracle.com>

Hello,

Please review this small fix to the following issue:

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

The proposed changeset is located at:

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

The hash map used there didn't have initial capacity, even though the 
exact numbers are known.

Naoto

From huizhe.wang at oracle.com  Thu Apr 30 00:06:54 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 29 Apr 2020 17:06:54 -0700
Subject: <i18n dev> [15] RFR: 8244152: Remove unnecessary hash map
 resize in LocaleProviderAdapters
In-Reply-To: <e59313a6-6b7e-6085-dc53-d4fe8f460ae4@oracle.com>
References: <e59313a6-6b7e-6085-dc53-d4fe8f460ae4@oracle.com>
Message-ID: <e03eb0c8-6fcb-c102-754c-ec79f8856eb2@oracle.com>

+1

-Joe

On 4/29/2020 3:18 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review this small fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8244152
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/
>
> The hash map used there didn't have initial capacity, even though the 
> exact numbers are known.
>
> Naoto