From rriggs at openjdk.java.net  Fri Oct  2 15:24:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 15:24:51 GMT
Subject: <i18n dev> RFR: 8251989: Hex formatting and parsing utility
Message-ID: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>

java.util.HexFormat utility:

 - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
 - Static factories and builder methods to create HexFormat copies with modified parameters.
 - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
 - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
 - Prefix and suffixes now apply to each formatted value, not the string as a whole
 - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
   like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
 - Immutable and thread safe, a "value-based" class

See the [HexFormat
javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.

Review comments and suggestions welcome.

-------------

Commit messages:
 - 8251989: Hex formatting and parsing utility

Changes: https://git.openjdk.java.net/jdk/pull/482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251989
  Stats: 1665 lines in 12 files changed: 1503 ins; 144 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From prr at openjdk.java.net  Fri Oct  2 18:24:41 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 2 Oct 2020 18:24:41 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments
In-Reply-To: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
Message-ID: <uVQfNzkXaMGLRflzd-LLsatQJyxFj5jtE57i-XPzzAU=.30e62e82-056d-4ad8-a2d5-c47e6c882f9d@github.com>

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
> 
> The fix:
>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>   - Adds comments to the "serializable" classes even if those classes are non-public
>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>   - Delete the java.awt.PeerFixer class.
> 
> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
> 
> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html

src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java line 44:

> 42: /**
> 43:  * A {@code IIODOMException} is thrown by the {@code IIOMetadataNode} in
> 44:  * "exceptional" circumstances.

"A" -> "An"

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From prr at openjdk.java.net  Fri Oct  2 18:38:39 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 2 Oct 2020 18:38:39 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments
In-Reply-To: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
Message-ID: <_0gBfrD0z0Z7EFJ4SHXPR3namwcJkFJofC7GGwXOdq8=.901366c2-b6bc-4215-866d-f613def1006e@github.com>

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
> 
> The fix:
>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>   - Adds comments to the "serializable" classes even if those classes are non-public
>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>   - Delete the java.awt.PeerFixer class.
> 
> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
> 
> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html

I think the main thing here is I would separate out removing the duplicate PeerFixer into a new bug.

I also see that the CSR is still just a pure template.

src/java.desktop/share/classes/java/awt/ScrollPane.java line 815:

> 813:
> 814: /*
> 815:  * In JDK 1.1.1, the pkg private class java.awt.PeerFixer was moved to

As I mentioned in the OLD review thread for hg, this definitely needs a CSR
and it needs to be called out.
I think it should be separated out from this fix which is about fixing doclint warnings but here you are making an
incompatible change. Let's not mix the two.

src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java line 434:

> 432:      * @serial
> 433:      */
> 434:     private int checkboxMenuItemSerializedDataVersion = 1;

OK. Good this was being discussed in the old review and it should stay.

src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java line 75:

> 73:      * This constant is used when the backward focus traversal order is active.
> 74:      */
> 75:     private final int BACKWARD_TRAVERSAL = 1;

I see you also reverted the change of these two to static so that is also good.

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/369

From prr at openjdk.java.net  Fri Oct  2 19:48:40 2020
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 2 Oct 2020 19:48:40 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments
In-Reply-To: <_0gBfrD0z0Z7EFJ4SHXPR3namwcJkFJofC7GGwXOdq8=.901366c2-b6bc-4215-866d-f613def1006e@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
 <_0gBfrD0z0Z7EFJ4SHXPR3namwcJkFJofC7GGwXOdq8=.901366c2-b6bc-4215-866d-f613def1006e@github.com>
Message-ID: <a3IGk9CSgHYQtzvPRf6OKxOp0Y0TVtRdRKrTwSZzmjc=.ab15ee61-f58c-4300-b7b1-d56c4edfb0f5@github.com>

On Fri, 2 Oct 2020 18:35:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> We have a number of missing javadoc tags and comments in the desktop module.
>> Most of the missing comments are related to the serialized form.
>> 
>> The fix:
>>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>>   - Adds comments to the "serializable" classes even if those classes are non-public
>>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>>   - Delete the java.awt.PeerFixer class.
>> 
>> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
>> 
>> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
>> 
>> The old review request:
>> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html
>
> I think the main thing here is I would separate out removing the duplicate PeerFixer into a new bug.
> 
> I also see that the CSR is still just a pure template.

> I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal)

Probably almost all of it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From serb at openjdk.java.net  Sat Oct  3 00:31:48 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 3 Oct 2020 00:31:48 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments [v2]
In-Reply-To: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
Message-ID: <6Ov7jdR5aBYuiqkmH1WnBXafvEMKjs0J56Qu5icFAzw=.eef7d4ff-1daf-44c7-8424-030a638c7c30@github.com>

> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
> 
> The fix:
>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>   - Adds comments to the "serializable" classes even if those classes are non-public
>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>   - Delete the java.awt.PeerFixer class.
> 
> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
> 
> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html

Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:

 - Update ScrollPane.java
 - Update based on the feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/369/files
  - new: https://git.openjdk.java.net/jdk/pull/369/files/cfc1df5d..c1d83696

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=369&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=369&range=00-01

  Stats: 52 lines in 3 files changed: 49 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/369/head:pull/369

PR: https://git.openjdk.java.net/jdk/pull/369

From serb at openjdk.java.net  Sat Oct  3 03:59:39 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 3 Oct 2020 03:59:39 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments [v2]
In-Reply-To: <a3IGk9CSgHYQtzvPRf6OKxOp0Y0TVtRdRKrTwSZzmjc=.ab15ee61-f58c-4300-b7b1-d56c4edfb0f5@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
 <_0gBfrD0z0Z7EFJ4SHXPR3namwcJkFJofC7GGwXOdq8=.901366c2-b6bc-4215-866d-f613def1006e@github.com>
 <a3IGk9CSgHYQtzvPRf6OKxOp0Y0TVtRdRKrTwSZzmjc=.ab15ee61-f58c-4300-b7b1-d56c4edfb0f5@github.com>
Message-ID: <UddqDTnOFHI-YSNdQZzuteuF_85KVQ0FK4deeIGu0y8=.5faf969a-fa30-4d0a-930a-3fc8dd33f407@github.com>

On Fri, 2 Oct 2020 19:46:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> I think the main thing here is I would separate out removing the duplicate PeerFixer into a new bug.
>> 
>> I also see that the CSR is still just a pure template.
>
>> I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal)
> 
> Probably almost all of it.

The PeerFixer is extracted to the separate CR:
https://bugs.openjdk.java.net/browse/JDK-8253965
https://github.com/openjdk/jdk/pull/493

Other review comments fixed as well, CSR is in progress.

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From serb at openjdk.java.net  Sat Oct  3 04:47:38 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 3 Oct 2020 04:47:38 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments [v2]
In-Reply-To: <UddqDTnOFHI-YSNdQZzuteuF_85KVQ0FK4deeIGu0y8=.5faf969a-fa30-4d0a-930a-3fc8dd33f407@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
 <_0gBfrD0z0Z7EFJ4SHXPR3namwcJkFJofC7GGwXOdq8=.901366c2-b6bc-4215-866d-f613def1006e@github.com>
 <a3IGk9CSgHYQtzvPRf6OKxOp0Y0TVtRdRKrTwSZzmjc=.ab15ee61-f58c-4300-b7b1-d56c4edfb0f5@github.com>
 <UddqDTnOFHI-YSNdQZzuteuF_85KVQ0FK4deeIGu0y8=.5faf969a-fa30-4d0a-930a-3fc8dd33f407@github.com>
Message-ID: <D53f6P8Sy0JldulN2eLc5lvLf2vRqqWhdbDASunNYEA=.8411f644-ea3c-4567-9f6b-b2c16a9e8f0c@github.com>

On Sat, 3 Oct 2020 03:57:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I need advice about what exact change should be reviewed in the CSR(except PeerFixer removal)
>> 
>> Probably almost all of it.
>
> The PeerFixer is extracted to the separate CR:
> https://bugs.openjdk.java.net/browse/JDK-8253965
> https://github.com/openjdk/jdk/pull/493
> 
> Other review comments fixed as well, CSR is in progress.

CSR is updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From prr at openjdk.java.net  Sat Oct  3 19:36:38 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 3 Oct 2020 19:36:38 GMT
Subject: <i18n dev> RFR: 8251123: doclint warnings about missing javadoc
 tags and comments [v2]
In-Reply-To: <6Ov7jdR5aBYuiqkmH1WnBXafvEMKjs0J56Qu5icFAzw=.eef7d4ff-1daf-44c7-8424-030a638c7c30@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
 <6Ov7jdR5aBYuiqkmH1WnBXafvEMKjs0J56Qu5icFAzw=.eef7d4ff-1daf-44c7-8424-030a638c7c30@github.com>
Message-ID: <afqcPoSnlob0W3uBFdJhPvJjQooTQtt0tKpVRF_CLn8=.c5c5d822-dd61-4009-958f-022abb53998f@github.com>

On Sat, 3 Oct 2020 00:31:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> We have a number of missing javadoc tags and comments in the desktop module.
>> Most of the missing comments are related to the serialized form.
>> 
>> The fix:
>>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>>   - Adds comments to the "serializable" classes even if those classes are non-public
>>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>>   - Delete the java.awt.PeerFixer class.
>> 
>> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
>> 
>> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
>> 
>> The old review request:
>> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ScrollPane.java
>  - Update based on the feedback

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From igraves at openjdk.java.net  Mon Oct  5 22:31:50 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 5 Oct 2020 22:31:50 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
Message-ID: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>

The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
type is not defined.

This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an
additional exception type to throw when an invalid argument index is observed.

A CSR will be required for this PR.

-------------

Commit messages:
 - Updating docs and throwing errors accordingly

Changes: https://git.openjdk.java.net/jdk/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253459
  Stats: 77 lines in 2 files changed: 74 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From serb at openjdk.java.net  Tue Oct  6 10:52:46 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 6 Oct 2020 10:52:46 GMT
Subject: <i18n dev> Integrated: 8251123: doclint warnings about missing
 javadoc tags and comments
In-Reply-To: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
References: <dLKsXDutH87luyKefwe1x_JiZ2lE91G2kKdQ2b2pBBo=.a7a8b9c9-f008-4b0a-bbcc-72d23c7cdc2e@github.com>
Message-ID: <lmzyAsFG-4zRCB24dmBd8jYTT_pTVkVlXiqg6oocYkY=.3f9d9853-b02a-42d5-8cec-30ba575d3fed@github.com>

On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
> 
> The fix:
>   - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
>   - Adds comments to the "serializable" classes even if those classes are non-public
>   - Fixes references/adds missing tags to the special methods(like readObject/writeObject)
>   - Delete the java.awt.PeerFixer class.
> 
> I need advice about what exact change should be reviewed in  the CSR(except PeerFixer removal)
> 
> Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/beans-dev/2020-August/000423.html

This pull request has now been integrated.

Changeset: f397b60a
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f397b60a
Stats:     1256 lines in 69 files changed: 809 ins; 165 del; 282 mod

8251123: doclint warnings about missing javadoc tags and comments

Reviewed-by: jdv, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/369

From rriggs at openjdk.java.net  Tue Oct  6 13:59:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 13:59:10 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>

On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Is the new exception type useful?  yes, it matches the previous pattern.
But it (and none of the IllegalFormatException subclasses) produce a readable message with the offending value. So the
developer will not see anything useful. The fine grained exceptions provide little value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Tue Oct  6 19:13:07 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Oct 2020 19:13:07 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
Message-ID: <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>

On Tue, 6 Oct 2020 13:55:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
>> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
>> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
>> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
>> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
>> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
>> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
>> required for this PR.
>
> Is the new exception type useful?  yes, it matches the previous pattern.
> But it does not (and none of the IllegalFormatException subclasses) produce a readable message with the offending
> value. So the developer will not see anything useful. The fine grained exceptions provide little value.

I've been on the fence about this, personally. The Formatter uses pretty fine-grained exception types for error
conditions. I'd be okay discontinuing this practice here, but am not sure what to replace this with. Perhaps we enable
`IllegalFormatException` to be, itself, public and instantiable ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Thu Oct  8 21:07:37 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 8 Oct 2020 21:07:37 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v2]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <6XbJr_Xa0SBSRBnBgT92rAvtQNhESkLQkaMahhRFAiU=.fc84561e-28f2-478b-97bd-76702c999287@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updating docs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/f2af81f6..33bf7a14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=00-01

  Stats: 16 lines in 3 files changed: 10 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From kravikumar at openjdk.java.net  Mon Oct 12 10:06:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 12 Oct 2020 10:06:16 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
Message-ID: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>

Hi Guys,

Please review the patch for tzdata2020b integration into JDK.

Release details can be found here:

https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html

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

I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
need to be updated to incorporate the change.

The patch has passed all the related testing including JCK.

Thanks,
Kiran

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8254177
 - 8254177: Resolving whitespaces in TestZoneInfo310.java
 - 8254177: (tz) Upgrade time-zone data to tzdata2020b

Changes: https://git.openjdk.java.net/jdk/pull/602/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=602&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254177
  Stats: 480 lines in 27 files changed: 138 ins; 133 del; 209 mod
  Patch: https://git.openjdk.java.net/jdk/pull/602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/602/head:pull/602

PR: https://git.openjdk.java.net/jdk/pull/602

From kravikumar at openjdk.java.net  Mon Oct 12 10:06:17 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 12 Oct 2020 10:06:17 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <22YmDaNpCLPodEMwzylAkKsF41pIePBAvkpQcyTH-6g=.12bffcc4-05f9-40e0-b454-75e5bb8713ce@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 221:

> 219:         zids_old = ZoneInfoOld.getAvailableIDs(-8 * 60 * 60 * 1000);
> 220: 	Arrays.sort(zids_old);
> 221: 	System.out.println("new and old length = " + zids_new.length + " " + zids_old.length);

Missed to remove the instrumentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From erikj at openjdk.java.net  Mon Oct 12 13:00:18 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Oct 2020 13:00:18 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <cYLhMc2BMeJ4FiHxtK8uQcsPf5cFJ1aPNmy3JjkBpok=.84957f0b-7483-4d03-bbcc-9cb6337c2169@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From naoto at openjdk.java.net  Mon Oct 12 17:08:17 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Oct 2020 17:08:17 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <BR57psTBXz0VHZpZvfvT3acDjupN3qxRLirR9Si3mkc=.3e0bba96-cb58-477c-9948-981ab807a4d9@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Looks good to me.
I was wondering about the consequence of removing the "US/Pacific-New" zone names, but since the time zone should never
have been introduced in the first place (it didn't become the law), I think no real world application would have used
it.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From igraves at openjdk.java.net  Mon Oct 12 22:04:25 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 12 Oct 2020 22:04:25 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v3]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <AxF_1veebuzHCsrzUXZlCRirCmolcZhstDPIFlaelOc=.edc0b258-5749-4467-a22a-77762f66e969@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains four commits:

 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly

-------------

Changes: https://git.openjdk.java.net/jdk/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02
  Stats: 96 lines in 4 files changed: 88 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From coffeys at openjdk.java.net  Tue Oct 13 11:10:19 2020
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 13 Oct 2020 11:10:19 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
production/testing system is looking for such a zone.

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From kravikumar at openjdk.java.net  Tue Oct 13 11:35:13 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 11:35:13 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
Message-ID: <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>

On Tue, 13 Oct 2020 11:07:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the patch for tzdata2020b integration into JDK.
>> 
>> Release details can be found here:
>> 
>> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
>> 
>> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
>> need to be updated to incorporate the change.
>> The patch has passed all the related testing including JCK.
>> 
>> Thanks,
>> Kiran
>
> Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
> production/testing system is looking for such a zone.

Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From kravikumar at openjdk.java.net  Tue Oct 13 11:41:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 11:41:16 GMT
Subject: <i18n dev> Integrated: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <7ehytQcqVn_Zu5PS5lK08N0zXW0pf_OPGfU5LKVGHM8=.5fdd7b75-4e0a-4e67-8d3d-f86175c38cfc@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: 9c934909
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c934909
Stats:     480 lines in 27 files changed: 138 ins; 133 del; 209 mod

8254177: (tz) Upgrade time-zone data to tzdata2020b

Reviewed-by: erikj, naoto, coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From andrew at openjdk.java.net  Tue Oct 13 18:46:16 2020
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 13 Oct 2020 18:46:16 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
 <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
Message-ID: <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>

On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
>> production/testing system is looking for such a zone.
>
> Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes

Looks like we both reached the same patch for this one independently :)
systemv was removed from tzdata some time ago and wasn't even being read by the JDK as far as I could see. Its contents
are duplicated in jdk11_backward anyway. Good to see both it and pacificnew being removed. In the unlikely event the
removal of Pacific_New is problematic, it could be added to jdk11_backward as well, but it seems very unlikely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From kravikumar at openjdk.java.net  Wed Oct 14 12:59:17 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 14 Oct 2020 12:59:17 GMT
Subject: <i18n dev> RFR: 8254177: (tz) Upgrade time-zone data to
 tzdata2020b
In-Reply-To: <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
 <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
 <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>
Message-ID: <fDpL9h0scz5O8qBYscHt4R5mxqsw6rvhSsmyd-d_0Xw=.27b504a7-f305-42c0-8ef8-b1b0f463e04b@github.com>

On Tue, 13 Oct 2020 18:43:18 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes
>
> Looks like we both reached the same patch for this one independently :)
> systemv was removed from tzdata some time ago and wasn't even being read by the JDK as far as I could see. Its contents
> are duplicated in jdk11_backward anyway. Good to see both it and pacificnew being removed. In the unlikely event the
> removal of Pacific_New is problematic, it could be added to jdk11_backward as well, but it seems very unlikely.

Thanks for the comment, Andrew. I agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From igraves at openjdk.java.net  Wed Oct 14 18:39:31 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 14 Oct 2020 18:39:31 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v4]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/391449a8..9b07ef33

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02-03

  Stats: 18 lines in 2 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From jason_mehrens at hotmail.com  Thu Oct 15 02:30:18 2020
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 15 Oct 2020 02:30:18 +0000
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v4]
In-Reply-To: <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>,
 <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>
Message-ID: <DM5PR1801MB2074FC52596831F81296296283020@DM5PR1801MB2074.namprd18.prod.outlook.com>

Ian,

Should IllegalFormatArgumentIndexException.java provide an override of getMessage?  It appears that is done in the following:

https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatWidthException.java
https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java

Otherwise the index won't be rendered when toString or printStackTrace is invoked.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Ian Graves <igraves at openjdk.java.net>
Sent: Wednesday, October 14, 2020 1:39 PM
To: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v4]

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/391449a8..9b07ef33

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02-03

  Stats: 18 lines in 2 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Thu Oct 15 19:20:28 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 15 Oct 2020 19:20:28 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v5]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Additional specificity around width

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/9b07ef33..0526ef43

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03-04

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From kravikumar at openjdk.java.net  Mon Oct 19 18:54:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 19 Oct 2020 18:54:16 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c
Message-ID: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>

Hi Guys,

Please review the integration of tzdata2020c to JDK.

Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8254982

Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.

Please let me know if the changes are good to push.

Thanks,
Kiran

-------------

Commit messages:
 - 8254982: (tz) Upgrade time-zone data to tzdata2020c

Changes: https://git.openjdk.java.net/jdk/pull/747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254982
  Stats: 30 lines in 4 files changed: 27 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/747/head:pull/747

PR: https://git.openjdk.java.net/jdk/pull/747

From erikj at openjdk.java.net  Mon Oct 19 19:02:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 19 Oct 2020 19:02:13 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <svjctHrsWeWeRI1xF1reU5VxO2tGEdHsEzB1b_iuNZk=.21f03395-9be3-494c-8346-6887b8d65fbe@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

Build change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/747

From naoto at openjdk.java.net  Mon Oct 19 19:43:20 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 19 Oct 2020 19:43:20 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

test/jdk/java/util/Formatter/BasicDateTime.java line 1695:

> 1693:         list.remove("America/Dawson");
> 1694:         list.remove("America/WhiteHorse");
> 1695:         list.remove("Canada/Yukon");

I'd explicitly mention why these time zones are removed from the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From kravikumar at openjdk.java.net  Tue Oct 20 11:39:36 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 20 Oct 2020 11:39:36 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c [v2]
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
additional commits since the last revision:

 - 8254982: Adding comments for removal of zones in BasicDateTime.java
 - Merge remote-tracking branch 'origin/master' into JDK-8254982
 - 8254982: (tz) Upgrade time-zone data to tzdata2020c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/747/files
  - new: https://git.openjdk.java.net/jdk/pull/747/files/7bd51537..7434663a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=00-01

  Stats: 26902 lines in 293 files changed: 17268 ins; 8054 del; 1580 mod
  Patch: https://git.openjdk.java.net/jdk/pull/747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/747/head:pull/747

PR: https://git.openjdk.java.net/jdk/pull/747

From kravikumar at openjdk.java.net  Tue Oct 20 11:39:38 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 20 Oct 2020 11:39:38 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c [v2]
In-Reply-To: <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
 <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>
Message-ID: <GReRISl8rbK_8UZSN9J7q1XgTsMAt53I3ps69QCgd4U=.29c79659-7120-43e2-b267-867aabe47b5f@github.com>

On Mon, 19 Oct 2020 19:38:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
>> incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
>> additional commits since the last revision:
>>  - 8254982: Adding comments for removal of zones in BasicDateTime.java
>>  - Merge remote-tracking branch 'origin/master' into JDK-8254982
>>  - 8254982: (tz) Upgrade time-zone data to tzdata2020c
>
> test/jdk/java/util/Formatter/BasicDateTime.java line 1695:
> 
>> 1693:         list.remove("America/Dawson");
>> 1694:         list.remove("America/WhiteHorse");
>> 1695:         list.remove("Canada/Yukon");
> 
> I'd explicitly mention why these time zones are removed from the test.

Thanks, Naoto, I have added the information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From naoto at openjdk.java.net  Tue Oct 20 16:18:25 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 20 Oct 2020 16:18:25 GMT
Subject: <i18n dev> RFR: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c [v2]
In-Reply-To: <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
 <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>
Message-ID: <u1E_ohihA7QJqWM-i5w6IW0UlOvACuBbRSI9gbcmon8=.7982aa21-1d75-4422-ae27-b76b46cc0fcd@github.com>

On Tue, 20 Oct 2020 11:39:36 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020c to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
>> 
>> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
>> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
>> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
>> if the changes are good to push.
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
> incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
> additional commits since the last revision:
>  - 8254982: Adding comments for removal of zones in BasicDateTime.java
>  - Merge remote-tracking branch 'origin/master' into JDK-8254982
>  - 8254982: (tz) Upgrade time-zone data to tzdata2020c

Looks good. Thank you for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/747

From naoto at openjdk.java.net  Wed Oct 21 20:47:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 20:47:21 GMT
Subject: <i18n dev> RFR: 8255086: JRE country and region name may be the
 latest
Message-ID: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>

Hi,

Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

-------------

Commit messages:
 - 8255086: JRE country and region name may be the latest

Changes: https://git.openjdk.java.net/jdk/pull/786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255086
  Stats: 234 lines in 5 files changed: 111 ins; 0 del; 123 mod
  Patch: https://git.openjdk.java.net/jdk/pull/786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/786/head:pull/786

PR: https://git.openjdk.java.net/jdk/pull/786

From bchristi at openjdk.java.net  Wed Oct 21 23:05:11 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 21 Oct 2020 23:05:11 GMT
Subject: <i18n dev> RFR: 8255086: JRE country and region name may be the
 latest
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>

On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

Hi, Naoto

What is the source for the updated values in LocaleNames.properties?

Also, could the bug synopsis be updated to be more descriptive?

Thanks,
-Brent

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Wed Oct 21 23:19:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 23:19:10 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
In-Reply-To: <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
Message-ID: <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>

On Wed, 21 Oct 2020 23:01:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Hi, Naoto
> 
> What is the source for the updated values in LocaleNames.properties?
> 
> Also, could the bug synopsis be updated to be more descriptive?
> 
> Thanks,
> -Brent

Hi Brent,

> What is the source for the updated values in LocaleNames.properties?

The source is CLDR v37, which is currently used in the latest JDK release. They are extracted with a code snippet (https://bugs.openjdk.java.net/browse/JDK-8255086?focusedCommentId=14375906&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14375906), and non-ASCII chars are Unicode escaped.

> Also, could the bug synopsis be updated to be more descriptive?

Modified the synopsis. Hope it made sense.

Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Wed Oct 21 23:38:23 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 23:38:23 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Put a newline at the end.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/786/files
  - new: https://git.openjdk.java.net/jdk/pull/786/files/5ccc2bdb..17054a4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/786/head:pull/786

PR: https://git.openjdk.java.net/jdk/pull/786

From jjg at openjdk.java.net  Thu Oct 22 17:29:21 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 17:29:21 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec tag
Message-ID: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>

The change is (just) to remove legacy usages of a JDK-private custom tag.

-------------

Commit messages:
 - JDK-8255262: Remove use of legacy custom @spec tag

Changes: https://git.openjdk.java.net/jdk/pull/814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=814&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255262
  Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/814/head:pull/814

PR: https://git.openjdk.java.net/jdk/pull/814

From lancea at openjdk.java.net  Thu Oct 22 17:35:15 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 22 Oct 2020 17:35:15 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <YqDdpupjEAA42B4PFVQOO5Chtneb-DXRonDYRk0g1oU=.84fb141b-90cd-4c59-a0ca-e2e749898547@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

looks fine

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/814

From iris at openjdk.java.net  Thu Oct 22 17:46:16 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 22 Oct 2020 17:46:16 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <-NCS5lF0mdeaDq1CyQYTrh0gGVozPafltjNYsEpO488=.d795b2ec-acc2-4c06-8434-757b2095e386@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Nice clean-up.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/814

From mr at openjdk.java.net  Thu Oct 22 17:46:15 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 22 Oct 2020 17:46:15 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <IBnKE7sN9xlVAuD9BAutsshS8xqFrfZiksTR1Vy7KYs=.c10a9cd1-b81a-491d-85ba-fa5785b224eb@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

As the creator of these tags many moons ago, I approve this change.

-------------

Marked as reviewed by mr (Lead).

PR: https://git.openjdk.java.net/jdk/pull/814

From darcy at openjdk.java.net  Thu Oct 22 17:46:18 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Oct 2020 17:46:18 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <5hlum1g6yK7pF3TkDMBvYSlK0Ca3bVh1VM3XJUVAvCk=.93e60ef2-400c-4775-a4c5-1f290e14ed57@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From alanb at openjdk.java.net  Thu Oct 22 17:46:17 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Oct 2020 17:46:17 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <TOmCzg8UsQNgcxFkhfFIrZ3pPjnJQR_wRxMmuQ5z1tc=.82fb45d2-9a57-42ed-b7bc-bffc6a0ffcac@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From mchung at openjdk.java.net  Thu Oct 22 17:56:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Oct 2020 17:56:16 GMT
Subject: <i18n dev> RFR: JDK-8255262: Remove use of legacy custom @spec
 tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <CfzmVDcf7nrnyFKDthPyHgl0oxzB3mhVX-O_HeNK4ak=.ad190ae9-cdad-4ecf-a831-025ca3449893@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From jjg at openjdk.java.net  Thu Oct 22 19:49:22 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 19:49:22 GMT
Subject: <i18n dev> Integrated: JDK-8255262: Remove use of legacy custom
 @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <AF8Qx0S97zH-OBwiR9XmXmR9CBm12YhuYY2pfk2Ab7A=.76dafd63-a12a-403a-b0c4-df482c607f3b@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

This pull request has now been integrated.

Changeset: 0aa3c925
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0aa3c925
Stats:     209 lines in 69 files changed: 0 ins; 209 del; 0 mod

8255262: Remove use of legacy custom @spec tag

Reviewed-by: lancea, mr, iris, alanb, darcy, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From bchristi at openjdk.java.net  Thu Oct 22 21:44:14 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 22 Oct 2020 21:44:14 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
In-Reply-To: <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
 <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>
Message-ID: <XYEkQuKwc5EJAKkkW-i88LO0VEIcqxzw2-5QMqLyMG8=.067fb41c-6e5b-48b4-bf3e-f3f8ea091d77@github.com>

On Wed, 21 Oct 2020 23:16:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi, Naoto
>> 
>> What is the source for the updated values in LocaleNames.properties?
>> 
>> Also, could the bug synopsis be updated to be more descriptive?
>> 
>> Thanks,
>> -Brent
>
> Hi Brent,
> 
>> What is the source for the updated values in LocaleNames.properties?
> 
> The source is CLDR v37, which is currently used in the latest JDK release. They are extracted with a code snippet (https://bugs.openjdk.java.net/browse/JDK-8255086?focusedCommentId=14375906&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14375906), and non-ASCII chars are Unicode escaped.
> 
>> Also, could the bug synopsis be updated to be more descriptive?
> 
> Modified the synopsis. Hope it made sense.
> 
> Naoto

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From bchristi at openjdk.java.net  Thu Oct 22 21:44:14 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 22 Oct 2020 21:44:14 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
Message-ID: <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>

On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put a newline at the end.

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From joehw at openjdk.java.net  Thu Oct 22 22:32:12 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 22 Oct 2020 22:32:12 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
Message-ID: <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>

On Thu, 22 Oct 2020 21:40:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put a newline at the end.
>
> Marked as reviewed by bchristi (Reviewer).

Hi Naoto,

Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.

The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Thu Oct 22 23:23:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Oct 2020 23:23:10 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
 <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
Message-ID: <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>

On Thu, 22 Oct 2020 22:29:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Marked as reviewed by bchristi (Reviewer).
>
> Hi Naoto,
> 
> Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.
> 
> The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

Hi Joe,

> Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.

test/jdk/sun/text/resources/LocaleData validates all the changes with this changeset (added lines at the end), by checking the names in the resource bundle.

> 
> The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

Yeah, but I cannot think of a better location to preserve it. The reason is that it cannot be used as a test because CLDR's English names and COMPAT's root names can inherently be different. I just regard the code to be one-off to retrieve authentic English names for those language ids.

Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From joehw at openjdk.java.net  Fri Oct 23 00:24:25 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Oct 2020 00:24:25 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
 <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
 <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>
Message-ID: <DMA6WJkCjNUDypHdqN6aKOqKKuURGh704_q-ybeXlIM=.0ff76670-35a9-41a5-b23b-187411b0a548@github.com>

On Thu, 22 Oct 2020 23:20:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Joe,
> 
> > Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.
> 
> test/jdk/sun/text/resources/LocaleData validates all the changes with this changeset (added lines at the end), by checking the names in the resource bundle.

Saw the test and thought ISO3166 would be more direct. But you're right, as you said below, since it's one-off thing, can't really use a test like ISO3166 for a complete comparison.
> 
> > The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?
> 
> Yeah, but I cannot think of a better location to preserve it. The reason is that it cannot be used as a test because CLDR's English names and COMPAT's root names can inherently be different. I just regard the code to be one-off to retrieve authentic English names for those language ids.

I see. Thanks.

Joe

> 
> Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From joehw at openjdk.java.net  Fri Oct 23 00:24:24 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Oct 2020 00:24:24 GMT
Subject: <i18n dev> RFR: 8255086: Update the root locale display names
 [v2]
In-Reply-To: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
Message-ID: <USua9O8kb3Xy5jeMd38dzkCzVl8ddS9jCGR1xFxvuhA=.04819f82-1bb3-4c6b-9865-d5cef1ed519f@github.com>

On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put a newline at the end.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Fri Oct 23 01:20:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Oct 2020 01:20:12 GMT
Subject: <i18n dev> Integrated: 8255086: Update the root locale display names
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <5PuQOLClUtKCfPMUtsO8gJvOg7RjgSGalM9yvBFTvZM=.59b4d109-3245-43d9-8814-e8f841d49f0e@github.com>

On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

This pull request has now been integrated.

Changeset: ff5f2265
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff5f2265
Stats:     234 lines in 5 files changed: 111 ins; 0 del; 123 mod

8255086: Update the root locale display names

Reviewed-by: bchristi, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From kravikumar at openjdk.java.net  Fri Oct 23 10:15:38 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Fri, 23 Oct 2020 10:15:38 GMT
Subject: <i18n dev> Integrated: 8254982: (tz) Upgrade time-zone data to
 tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <KjTE9nDT6TrbT3DzZQBCdkeWvgRUo4GXzztGGkGoZ_c=.65c238da-8b6f-4c65-b3a7-ab5f516fe1ba@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK. 
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: 55a0cad8
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/55a0cad8
Stats:     33 lines in 4 files changed: 30 ins; 0 del; 3 mod

8254982: (tz) Upgrade time-zone data to tzdata2020c

Reviewed-by: erikj, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From naoto at openjdk.java.net  Fri Oct 23 17:25:47 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Oct 2020 17:25:47 GMT
Subject: <i18n dev> RFR: 8255242: Bidi.requiresBidi has misleading exception
 message
Message-ID: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>

Hi,

Please review this small exception message fix.

Naoto

-------------

Commit messages:
 - 8255242: Bidi.requiresBidi has misleading exception message

Changes: https://git.openjdk.java.net/jdk/pull/841/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=841&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255242
  Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/841.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/841/head:pull/841

PR: https://git.openjdk.java.net/jdk/pull/841

From bchristi at openjdk.java.net  Fri Oct 23 17:40:36 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 23 Oct 2020 17:40:36 GMT
Subject: <i18n dev> RFR: 8255242: Bidi.requiresBidi has misleading
 exception message
In-Reply-To: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
References: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
Message-ID: <x9l4sS2Zw8HASGrOw58fYHTCXCRz9ydTg3-IiUrGGa8=.1aca4336-6700-43c7-8f39-39002fcda112@github.com>

On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this small exception message fix.
> 
> Naoto

Looks good.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/841

From github.com+11685886+marcono1234 at openjdk.java.net  Sun Oct 25 00:03:39 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Sun, 25 Oct 2020 00:03:39 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v5]
In-Reply-To: <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>
Message-ID: <z3-ad0CCqit3JCQpg6828aIZRIgyXmxGlZhwRBMDfJw=.06f30db9-acc5-4184-bd92-db0cf46f82d8@github.com>

On Thu, 15 Oct 2020 19:20:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional specificity around width

Maybe it would be cleaner for `IllegalFormatArgumentIndexException`, `IllegalFormatWidthException` and `IllegalFormatPrecisionException` to provide no-arg constructors (which use `Integer.MIN_VALUE` as value) for the cases where the value cannot be represented.

Are you also planning to add some tests? That would probably be useful.

And would it be necessary to mention the exception for `index=0` in the release notes? I am personally a little bit afraid that there is code out there which uses it (since indices starting with 0 is not that uncommon). For example when someone used only one format specifier but wanted to be explicit, then a value of 0 would not have caused any issues for them in the past.

For what it's worth, personally I prefer having a separate exception type (`IllegalFormatArgumentIndexException`) to make it consistent with the other exceptions. The large number of exception types might not be ideal, especially since the user likely rarely needs to differentiate between them, but this pattern was chosen back then and it makes sense to stick to it now.

Might also be good to make the documentation for `getIndex()`, `getPrecision()` and `getWidth()` more consistent:
- `getIndex()`:
  - Starts with "Gets the ..."
  - "Returns ... if not ..."
- `getPrecision()`:
  - Starts with "Returns the ..."
  - "If the ... isn't ... will return"
- `getWidth()`:
  - Starts with "Returns the ..."
  - "If the ... is not ... then returns"

----

Note that I am neither an OpenJDK contributor nor have I signed the Terms of Use. Please let me know if should stop bothering you on this pull request.

src/java.base/share/classes/java/util/Formatter.java line 708:

> 706:  * <p> Values of <i>width</i> must be in the range one to
> 707:  * {@link Integer#MAX_VALUE}, inclusive, otherwise
> 708:  * {@link IllegalFormatWidthException} will be thrown

Missing period.
Suggestion:

 * {@link IllegalFormatWidthException} will be thrown.

src/java.base/share/classes/java/util/Formatter.java line 711:

> 709:  * Note that widths can appear to have a negative value, but the negative sign
> 710:  * is a <i>flag</i>. For example in the format string {@code "%-20s"} the
> 711:  * <i>width</i> is <i>20</i> and the <i>flag</i> is "-".</p>

Should the `"-"` here be formatted either as italic (to match the `<i>20</i>`; though not sure if italic is really needed there in the first place) or as code?

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Suggestion:

                    if (index <= 0) {

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 32:

> 30:  * range of supported argument index values. If an index value isn't
> 31:  * representable by an {@code int} type, then the value
> 32:  * {@code Integer.MIN_VALUE} will be used in the exception.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 53:

> 51:     /**
> 52:      * Gets the value of the illegal index.
> 53:      * Returns {@code Integer.MIN_VALUE} if the illegal index is not

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 32:

> 30:  * {@code -1}, the conversion does not support a precision, or the value is
> 31:  * otherwise unsupported. If the precision is not representable by an
> 32:  * {@code int} type, then the value {@code Integer.MIN_VALUE} will be used

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 56:

> 54:     /**
> 55:      * Returns the precision. If the precision isn't representable by an
> 56:      * integer type, then will return {@code Integer.MIN_VALUE}.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 56:

> 54:     /**
> 55:      * Returns the precision. If the precision isn't representable by an
> 56:      * integer type, then will return {@code Integer.MIN_VALUE}.

Suggestion:

     * {@code int} type, then will return {@code Integer.MIN_VALUE}.
To be consistent with other documentation and to be more explicit (`long` could also be understood as integer type).

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 54:

> 52: 
> 53:     /**
> 54:      * Returns the width. If the width is not representable by an integer type,

Suggestion:

     * Returns the width. If the width is not representable by an {@code int} type,
To be consistent with other documentation and to be more explicit (`long` could also be understood as integer type).

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 32:

> 30:  * than {@code -1} or is otherwise unsupported. If a given format width is not
> 31:  * representable by an {@code int} type, then the value
> 32:  * {@code Integer.MIN_VALUE} will be used in the exception.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 55:

> 53:     /**
> 54:      * Returns the width. If the width is not representable by an integer type,
> 55:      * then returns {@code Integer.MIN_VALUE}.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 30:

> 28: /**
> 29:  * Unchecked exception thrown when the precision is a negative value other than
> 30:  * {@code -1}, the conversion does not support a precision, or the value is

-1 being used by `java.util.Formatter.FormatSpecifier.precision(String, int, int)` as default value is in my opinion an implementation detail and should not be part of this documentation.

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 30:

> 28: /**
> 29:  * Unchecked exception thrown when the format width is a negative value other
> 30:  * than {@code -1} or is otherwise unsupported. If a given format width is not

-1 being used by `java.util.Formatter.FormatSpecifier.width(String, int, int)` as default value is in my opinion an implementation detail and should not be part of this documentation.

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 52:

> 50: 
> 51:     /**
> 52:      * Gets the value of the illegal index.

Maybe drop "illegal" here, for `@return` and for the constructor, or (preferred) add it to the existing `IllegalFormatPrecisionException` and `IllegalFormatWidthException` getter and constructor documentation for consistency.

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Note that the `java.util.Formatter.formatSpecifier` pattern does not permit a `-` in the first place, so maybe throwing an `AssertionError` would be more appropriate?

Same applies to `width` and `precision`.

src/java.base/share/classes/java/util/Formatter.java line 713:

> 711:  * <i>width</i> is <i>20</i> and the <i>flag</i> is "-".</p>
> 712:  *
> 713:  * <p> Values of <i>index</i> must be in the range one to

Suggestion:

 * <p> Values of <i>index</i> must be in the range 1 to
Maybe write a number here to make it faster to read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From naoto at openjdk.java.net  Sun Oct 25 18:26:38 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sun, 25 Oct 2020 18:26:38 GMT
Subject: <i18n dev> Integrated: 8255242: Bidi.requiresBidi has misleading
 exception message
In-Reply-To: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
References: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
Message-ID: <DoIutq83yMM1hSHY4wf9IprK-JkHdtHGNI2mhiCxpb8=.c54a7089-9b17-4b3e-a0c9-1966f538f9a8@github.com>

On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this small exception message fix.
> 
> Naoto

This pull request has now been integrated.

Changeset: 57d903bd
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57d903bd
Stats:     10 lines in 2 files changed: 7 ins; 0 del; 3 mod

8255242: Bidi.requiresBidi has misleading exception message

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.java.net/jdk/pull/841

From naoto at openjdk.java.net  Wed Oct 28 17:41:52 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Oct 2020 17:41:52 GMT
Subject: <i18n dev> RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
Message-ID: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>

Hi,

Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.

Naoto

-------------

Commit messages:
 - 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

Changes: https://git.openjdk.java.net/jdk/pull/908/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=908&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255533
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/908.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/908/head:pull/908

PR: https://git.openjdk.java.net/jdk/pull/908

From lancea at openjdk.java.net  Wed Oct 28 17:49:46 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 28 Oct 2020 17:49:46 GMT
Subject: <i18n dev> RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <bdzBwMqb-yw2cjeHyaJbnSDEfQBWk122hrWiRjszCd8=.dcb0596e-de11-4fb0-9bd9-8c521ec4c58c@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

Looks good

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/908

From rriggs at openjdk.java.net  Wed Oct 28 18:29:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 28 Oct 2020 18:29:51 GMT
Subject: <i18n dev> RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <vLDJvRsPx5C3koPI-l2PIYHz9iUPcWT6_X3r4PKEIcc=.d40bb753-2203-4f8f-8a09-c12d11ea4a29@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/908

From naoto at openjdk.java.net  Wed Oct 28 20:05:46 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Oct 2020 20:05:46 GMT
Subject: <i18n dev> Integrated: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <XR91mbPRaa-8Xn58SRjgwi5Mi3aFOVyZQZ_4QyT-HqE=.db0a0d2a-2f35-4864-aa11-dce1269e2677@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

This pull request has now been integrated.

Changeset: 790d6e2d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/790d6e2d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

Reviewed-by: lancea, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/908

From naoto at openjdk.java.net  Thu Oct 29 16:15:52 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Oct 2020 16:15:52 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support
Message-ID: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>

Hi,

Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:

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

Naoto

-------------

Commit messages:
 - 8247781: Day periods support

Changes: https://git.openjdk.java.net/jdk/pull/938/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247781
  Stats: 1022 lines in 17 files changed: 838 ins; 87 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From scolebourne at openjdk.java.net  Fri Oct 30 11:45:54 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 30 Oct 2020 11:45:54 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>

On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Changes requested by scolebourne (Author).

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 981:

> 979: 
> 980:             {"B", "Text(DayPeriod,SHORT)"},
> 981:             {"BB", "Text(DayPeriod,SHORT)"},

"BB" and "BBB" are not defined to do anything in the CSR. Java should match CLDR/LDML rules here.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 540:

> 538:         builder.appendDayPeriodText(TextStyle.FULL);
> 539:         DateTimeFormatter f = builder.toFormatter();
> 540:         assertEquals(f.toString(), "Text(DayPeriod,FULL)");

This should be "DayPeriod(FULL)", because an end user might create a `TemporalField` with the name "DayPeriod" and the toString should be unique.

src/java.base/share/classes/java/time/format/Parsed.java line 352:

> 350:                     (fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0);
> 351:             if (!dayPeriod.includes(mod)) {
> 352:                 throw new DateTimeException("Conflict found: " + changeField + " conflict with day period");

"conflict with day period" -> "conflicts with day period"

Should also include `changeValue` and ideally the valid range

src/java.base/share/classes/java/time/format/Parsed.java line 472:

> 470:         }
> 471:         if (dayPeriod != null) {
> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {

Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.

src/java.base/share/classes/java/time/format/Parsed.java line 497:

> 495:                         AMPM_OF_DAY.checkValidValue(ap);
> 496:                     }
> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);

No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.

src/java.base/share/classes/java/time/format/Parsed.java line 500:

> 498:                 }
> 499:             }
> 500:         }

Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).

On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1489:

> 1487:         Objects.requireNonNull(style, "style");
> 1488:         if (style != TextStyle.FULL && style != TextStyle.SHORT && style != TextStyle.NARROW) {
> 1489:             throw new IllegalArgumentException("Style must be either full, short, or narrow");

Nothing in the Javadoc describes this behaviour. It would make more sense to map FULL_STANDALONE to FULL and so on and not throw an exception.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1869:

> 1867:                 } else if (cur == 'B') {
> 1868:                     switch (count) {
> 1869:                         case 1, 2, 3 -> appendDayPeriodText(TextStyle.SHORT);

I think this should be `case 1`. The 2 and 3 are not in the Javadoc, and I don't think they are in LDML. I note that patterns G and E do this though, so there is precedent.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5094:

> 5092:         @Override
> 5093:         public String toString() {
> 5094:             return "Text(DayPeriod," + textStyle + ")";

Should be "DayPeriod(FULL)" to avoid possible `toString` clashes with the text printer/parser

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5153:

> 5151:          * minute-of-day of "at" or "from" attribute
> 5152:          */
> 5153:         private final long from;

Could these three instance variables be `int` ?

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5252:

> 5250:                         .getLocaleResources(CalendarDataUtility.findRegionOverride(l));
> 5251:                 String dayPeriodRules = lr.getRules()[1];
> 5252:                 final Map<DayPeriod, Long> pm = new ConcurrentHashMap<>();

`pm` is a confusing variable name given this method deals with AM/PM concept.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5289:

> 5287:                 .filter(dp -> dp.getIndex() == index)
> 5288:                 .findAny()
> 5289:                 .orElseThrow();

Isn't is likely that the user could pass in an unexpected `Locale`? If so, then this needs an exception message.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5137:

> 5135:      * <a href="https://www.unicode.org/reports/tr35/tr35-dates.html#dayPeriods">DayPeriod</a> defined in CLDR.
> 5136:      */
> 5137:     static final class DayPeriod {

Looks like this class could be `ValueBased` as per other PRs

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 712:

> 710:         }
> 711:     }
> 712: 

There don't seem to be any tests of the resolver logic in `Parsed`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 21:43:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 21:43:21 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v2]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>

On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed the following comments:
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 981:
> 
>> 979: 
>> 980:             {"B", "Text(DayPeriod,SHORT)"},
>> 981:             {"BB", "Text(DayPeriod,SHORT)"},
> 
> "BB" and "BBB" are not defined to do anything in the CSR. Java should match CLDR/LDML rules here.

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 540:
> 
>> 538:         builder.appendDayPeriodText(TextStyle.FULL);
>> 539:         DateTimeFormatter f = builder.toFormatter();
>> 540:         assertEquals(f.toString(), "Text(DayPeriod,FULL)");
> 
> This should be "DayPeriod(FULL)", because an end user might create a `TemporalField` with the name "DayPeriod" and the toString should be unique.

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 352:
> 
>> 350:                     (fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0);
>> 351:             if (!dayPeriod.includes(mod)) {
>> 352:                 throw new DateTimeException("Conflict found: " + changeField + " conflict with day period");
> 
> "conflict with day period" -> "conflicts with day period"
> 
> Should also include `changeValue` and ideally the valid range

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 472:
> 
>> 470:         }
>> 471:         if (dayPeriod != null) {
>> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {
> 
> Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.

MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.

> src/java.base/share/classes/java/time/format/Parsed.java line 500:
> 
>> 498:                 }
>> 499:             }
>> 500:         }
> 
> Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).
> 
> On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)

There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1489:
> 
>> 1487:         Objects.requireNonNull(style, "style");
>> 1488:         if (style != TextStyle.FULL && style != TextStyle.SHORT && style != TextStyle.NARROW) {
>> 1489:             throw new IllegalArgumentException("Style must be either full, short, or narrow");
> 
> Nothing in the Javadoc describes this behaviour. It would make more sense to map FULL_STANDALONE to FULL and so on and not throw an exception.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1869:
> 
>> 1867:                 } else if (cur == 'B') {
>> 1868:                     switch (count) {
>> 1869:                         case 1, 2, 3 -> appendDayPeriodText(TextStyle.SHORT);
> 
> I think this should be `case 1`. The 2 and 3 are not in the Javadoc, and I don't think they are in LDML. I note that patterns G and E do this though, so there is precedent.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5094:
> 
>> 5092:         @Override
>> 5093:         public String toString() {
>> 5094:             return "Text(DayPeriod," + textStyle + ")";
> 
> Should be "DayPeriod(FULL)" to avoid possible `toString` clashes with the text printer/parser

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5153:
> 
>> 5151:          * minute-of-day of "at" or "from" attribute
>> 5152:          */
>> 5153:         private final long from;
> 
> Could these three instance variables be `int` ?

It shares the code with other TempralFields which is Long, so it is more fit to take long imo.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5252:
> 
>> 5250:                         .getLocaleResources(CalendarDataUtility.findRegionOverride(l));
>> 5251:                 String dayPeriodRules = lr.getRules()[1];
>> 5252:                 final Map<DayPeriod, Long> pm = new ConcurrentHashMap<>();
> 
> `pm` is a confusing variable name given this method deals with AM/PM concept.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5289:
> 
>> 5287:                 .filter(dp -> dp.getIndex() == index)
>> 5288:                 .findAny()
>> 5289:                 .orElseThrow();
> 
> Isn't is likely that the user could pass in an unexpected `Locale`? If so, then this needs an exception message.

Although it will never throw an exception due to unknown locale (am/pm is always available), I added a DateTimeException w/ message supplier to orElseThrow().

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5137:
> 
>> 5135:      * <a href="https://www.unicode.org/reports/tr35/tr35-dates.html#dayPeriods">DayPeriod</a> defined in CLDR.
>> 5136:      */
>> 5137:     static final class DayPeriod {
> 
> Looks like this class could be `ValueBased` as per other PRs

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 712:
> 
>> 710:         }
>> 711:     }
>> 712: 
> 
> There don't seem to be any tests of the resolver logic in `Parsed`.

Test case added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 21:43:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 21:43:14 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v2]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <o3tZADaROPx5aE1AUUdqMy2mFKYSn4y--SXAYSf7JCY=.d67a2be3-86c5-48b8-8134-b52fb2189456@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
  - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
  - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
  - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
  - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
  - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
  - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
  - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
  - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
  - https://github.com/openjdk/jdk/pull/938#discussion_r515039056

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/7ac5fa03..6e1eade7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=00-01

  Stats: 99 lines in 3 files changed: 48 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 22:03:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 22:03:08 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed exception messages.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/6e1eade7..29c47afc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 22:31:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 22:31:00 GMT
Subject: <i18n dev> RFR: 8255671: Bidi.reorderVisually has misleading
 exception messages
Message-ID: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>

Hi,

Please review this simple message fix that follows JDK-8255242.

Naoto

-------------

Commit messages:
 - 8255671: Bidi.reorderVisually has misleading exception messages

Changes: https://git.openjdk.java.net/jdk/pull/973/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=973&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255671
  Stats: 35 lines in 2 files changed: 32 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/973/head:pull/973

PR: https://git.openjdk.java.net/jdk/pull/973

From joehw at openjdk.java.net  Fri Oct 30 23:27:58 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 30 Oct 2020 23:27:58 GMT
Subject: <i18n dev> RFR: 8255671: Bidi.reorderVisually has misleading
 exception messages
In-Reply-To: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
References: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
Message-ID: <sobH8ulbPEZIoTwNOGCgBvIMY7pK0dOL98GZuYermH0=.8e4f9c9f-a931-4845-a819-8b11e007f3d5@github.com>

On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple message fix that follows JDK-8255242.
> 
> Naoto

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/973