From jpai at openjdk.org  Thu Sep  1 06:32:04 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 1 Sep 2022 06:32:04 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation [v2]
In-Reply-To: <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
 <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>
Message-ID: <XuJVWWQ6dKmu8Vj2wN2lWtbNVUpmhSMLSHzs8uhvsko=.15b28926-68bd-4ebb-ba40-2552c9bcb86d@github.com>

On Wed, 31 Aug 2022 08:40:29 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/PatternEntry.java line 55:
>> 
>>> 53:      * Gets the current extension, quoted
>>> 54:      */
>>> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {
>> 
>> Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?
>
> Changed a few of methods to `private`

Thank you Andrey for doing those changes.

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

PR: https://git.openjdk.org/jdk/pull/10007

From naoto at openjdk.org  Thu Sep  1 15:49:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Sep 2022 15:49:17 GMT
Subject: <i18n dev> Integrated: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <IOrDps5yOI6Cn_4F-e84PjJFC4w5srCv_0PflrjHhjA=.b8926937-4332-4312-807f-012075e3afb8@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

This pull request has now been integrated.

Changeset: 6a1b0b56
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a1b0b5649dd4f2a970df0839bf77bdb899fbd6f
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8293154: TemporalQueries java doc error

Reviewed-by: rriggs, lancea

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

PR: https://git.openjdk.org/jdk/pull/10103

From ysatowse at openjdk.org  Fri Sep  2 12:44:14 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Sep 2022 12:44:14 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
Message-ID: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>

Please review this PR.  The PR adopts the official tzdata2022c as it is.
It means the pre-1970s data merged in tzdata2022c doesn't exist.
All tests have been passed with no failures.

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

Commit messages:
 - Merge branch 'master' into tz2022c
 - The first fix for tz2022c

Changes: https://git.openjdk.org/jdk/pull/10012/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292579
  Stats: 1021 lines in 15 files changed: 256 ins; 613 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/10012.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10012/head:pull/10012

PR: https://git.openjdk.org/jdk/pull/10012

From ysatowse at openjdk.org  Fri Sep  2 12:44:14 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Sep 2022 12:44:14 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <nTaD7dc81zimRwiA3LtERDRb5re55iW29C3pQJaEhOk=.33ba4b3c-6efd-49a8-9a67-e2d6f3bff840@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

The test failure seems to be irrelevant to this fix.
Problem listed by [JDK-8292498](https://bugs.openjdk.org/browse/JDK-8292498) and also mentioned as that the failure may occur on non-Windows platforms.

https://bugs.openjdk.org/browse/JDK-8292498?focusedCommentId=14518336&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14518336

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

PR: https://git.openjdk.org/jdk/pull/10012

From naoto at openjdk.org  Fri Sep  2 16:24:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Sep 2022 16:24:43 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <uFtogqDZlheTYFpDBAMSEksag8cg8flSitscaHFvUjk=.bf9ec68e-c7b3-4a2f-bb43-2042ea24083b@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10012

From alanb at openjdk.org  Sat Sep  3 07:27:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Sep 2022 07:27:42 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <VF0kY5jdbwsZRo4nz9zR9TKVrEU00SANMxjL8ujRBOI=.521bad94-0a4f-4a17-9fdf-223d6d6b727c@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10012

From ihse at openjdk.org  Tue Sep  6 12:29:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:29:23 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v7]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes in libjpeg
 - Revert changes in libfreetype

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8328/files
  - new: https://git.openjdk.org/jdk/pull/8328/files/98e635a5..19409c23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=05-06

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Tue Sep  6 12:42:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:42:05 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes in libjpeg
 - Revert changes in libfreetype
 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=07
  Stats: 1028 lines in 486 files changed: 0 ins; 0 del; 1028 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Tue Sep  6 12:42:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:42:05 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v7]
In-Reply-To: <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>
Message-ID: <Hl542x4zGsdM4vphDlHp_4mI0ngo5EhyWwaY8pT1Tgs=.f1c199d1-f56a-467b-8328-68592abe6c5b@github.com>

On Tue, 6 Sep 2022 12:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype

I have now removed the changes to libfreetype, and also libjpeg. These were the only 3rd party source I could locate.

I apologize for this PR. It was too huge. If it is of any comfort, I've learnt my lesson and won't repeat it. And once it started getting pushed down by more prioritized work, I got  a bit scared about going back and look through all this for additional (unspecified) 3rd party sources, so it got left behind, hanging around.

@prrace I hope this is acceptable to merge now.

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

PR: https://git.openjdk.org/jdk/pull/8328

From ysatowse at openjdk.org  Tue Sep  6 16:09:09 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 6 Sep 2022 16:09:09 GMT
Subject: <i18n dev> Integrated: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <LxIbeC8-1Fw2dEtmteVCuXd3rq0cL438YQ-gVdbLPJE=.7f590598-e12b-4d2b-a154-8253f0b7e081@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

This pull request has now been integrated.

Changeset: 98d85e6f
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98d85e6f594bf34b97407c470b14791af0a2bc53
Stats:     1021 lines in 15 files changed: 256 ins; 613 del; 152 mod

8292579: (tz) Update Timezone Data to 2022c

Reviewed-by: naoto, alanb

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

PR: https://git.openjdk.org/jdk/pull/10012

From naoto at openjdk.org  Tue Sep  6 17:36:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Sep 2022 17:36:38 GMT
Subject: <i18n dev> RFR: 8293146: Strict DateTimeFormatter fails to report
 an invalid week 53
Message-ID: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>

Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

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

Commit messages:
 - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

Changes: https://git.openjdk.org/jdk/pull/10184/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293146
  Stats: 65 lines in 2 files changed: 61 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10184.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10184/head:pull/10184

PR: https://git.openjdk.org/jdk/pull/10184

From naoto at openjdk.org  Tue Sep  6 19:06:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Sep 2022 19:06:45 GMT
Subject: <i18n dev> RFR: 8293146: Strict DateTimeFormatter fails to
 report an invalid week 53 [v2]
In-Reply-To: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
Message-ID: <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>

> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

Naoto Sato 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:

 - Merge branch 'master' into JDK-8293146-StrictDateTimeFormatter
 - Fixed typo
 - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10184/files
  - new: https://git.openjdk.org/jdk/pull/10184/files/7c7a532c..be54a7be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10184&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10184&range=00-01

  Stats: 27962 lines in 532 files changed: 10072 ins; 12327 del; 5563 mod
  Patch: https://git.openjdk.org/jdk/pull/10184.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10184/head:pull/10184

PR: https://git.openjdk.org/jdk/pull/10184

From rriggs at openjdk.org  Wed Sep  7 17:46:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Sep 2022 17:46:43 GMT
Subject: <i18n dev> RFR: 8293146: Strict DateTimeFormatter fails to
 report an invalid week 53 [v2]
In-Reply-To: <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
 <p5aZI5V2M65EtDlnIPeG4OiaCPxFehoWkTabex9vPaA=.2e240b4e-fe7e-47f2-b8bd-bf4457415fe2@github.com>
Message-ID: <Sm4RGS25JMCI4vX2w7NpPsHUJEl8ag2WdU8zhsT1ydE=.ce11cda2-ecd3-479c-9d92-6dff9a70d0c7@github.com>

On Tue, 6 Sep 2022 19:06:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.
>
> Naoto Sato 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:
> 
>  - Merge branch 'master' into JDK-8293146-StrictDateTimeFormatter
>  - Fixed typo
>  - 8293146: Strict DateTimeFormatter fails to report an invalid week 53

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10184

From naoto at openjdk.org  Wed Sep  7 18:37:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Sep 2022 18:37:51 GMT
Subject: <i18n dev> Integrated: 8293146: Strict DateTimeFormatter fails to
 report an invalid week 53
In-Reply-To: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
References: <VxElPtTH8m2HoBuHuxIQ7JT-N0jePRGAQTvFkDz5MKI=.bc698e1c-beaa-4d1e-8c82-0caf02bd15c9@github.com>
Message-ID: <ZTMWrY_wpL8qy9i-W1vuFWWMDoGIqxJAterSA5j7yPM=.12ad4e1a-94f7-456e-a573-c9524ff1fd46@github.com>

On Tue, 6 Sep 2022 17:30:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed the max week number on parsing the week of week-based year field in strict mode. It used to be always returning the largest maximum, which should be adjusted by the actual week-based year.

This pull request has now been integrated.

Changeset: 32c7b628
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32c7b6283daf6f3876ff62693d5a0cb7c4af4232
Stats:     65 lines in 2 files changed: 61 ins; 0 del; 4 mod

8293146: Strict DateTimeFormatter fails to report an invalid week 53

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/10184

From smarks at openjdk.org  Wed Sep  7 23:23:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 7 Sep 2022 23:23:42 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
Message-ID: <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>

On Fri, 26 Aug 2022 21:48:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the paragraph to @implSpec

src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 47:

> 45:      */
> 46:     public static int nextBoundary(CharSequence src, int off, int limit) {
> 47:         Objects.checkFromToIndex(0, limit - off, src.length());

Is this right? The old code's use of `checkFromToIndex` method seems to be the right way to check that `off` and `limit` are a valid from-to range within `[0, src.length)`. The new code subtracts `off` from both args but the arithmetic seems to allow for some errors. For example, depending on the value of `limit`, this might permit `off` to be a small negative number.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 135:

> 133:     public BreakIterator getCharacterInstance(Locale locale) {
> 134:         return new GraphemeBreakIterator();
> 135:     }

It looks like there is some kind of table Since CHARACTER_INDEX is no longer used, does it mean there is now dead code for the CHARACTER break iterator class, and dead resources for CharacterData and CharacterDictionary? Should this be removed? Or maybe this is all in each locale or something and should be cleaned up later?

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

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Thu Sep  8 16:11:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 16:11:57 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v5]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <1FaPRQjWWE3I3jAyr2vyRnecYFIve45caRkDzNRLr1g=.fa0237b6-2793-49a1-8349-ab09371bf151@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Naoto Sato 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 ten additional commits since the last revision:

 - Reverted the index checking fix
 - Removed character break data which is no longer needed
 - Merge branch 'master' into JDK-8291660-graphemes
 - Changed the paragraph to @implSpec
 - Reverting the fix to BreakIterator.isBoundary()
 - Fixing JCK failures
 - Addressing review comments
 - 8291660: Grapheme support in BreakIterator
 - 8291660: Add a method to stream extended grapheme clusters in a String

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/06cfc222..2f31d417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=03-04

  Stats: 74365 lines in 1082 files changed: 32063 ins; 34006 del; 8296 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Thu Sep  8 16:14:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 16:14:30 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>
 <B7pt8BV5F7b0lfXYePq3cRVxri7HE7WJC_AOjUWAi7U=.7ceff804-9a59-4d9d-ba47-e50fbfccc54c@github.com>
Message-ID: <_ROpfVbWGm458N8rQ6gUOmfUArxrl7Ufm3slZUwjX5A=.06e59d20-50c8-4d03-a16f-4fdc7fdcd85c@github.com>

On Wed, 7 Sep 2022 21:27:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the paragraph to @implSpec
>
> src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 47:
> 
>> 45:      */
>> 46:     public static int nextBoundary(CharSequence src, int off, int limit) {
>> 47:         Objects.checkFromToIndex(0, limit - off, src.length());
> 
> Is this right? The old code's use of `checkFromToIndex` method seems to be the right way to check that `off` and `limit` are a valid from-to range within `[0, src.length)`. The new code subtracts `off` from both args but the arithmetic seems to allow for some errors. For example, depending on the value of `limit`, this might permit `off` to be a small negative number.

Thanks for the catch! Yes, this was a leftover before I fixed a couple of JCK failures which correctly fixed edge cases. Reverted the change.

> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 135:
> 
>> 133:     public BreakIterator getCharacterInstance(Locale locale) {
>> 134:         return new GraphemeBreakIterator();
>> 135:     }
> 
> It looks like there is some kind of table Since CHARACTER_INDEX is no longer used, does it mean there is now dead code for the CHARACTER break iterator class, and dead resources for CharacterData and CharacterDictionary? Should this be removed? Or maybe this is all in each locale or something and should be cleaned up later?

Right. Removed the now-dead code.

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

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Thu Sep  8 18:32:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Sep 2022 18:32:56 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v6]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

  Removed unnecessary comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/2f31d417..e8e037c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/9991

From itakiguchi at openjdk.org  Fri Sep  9 06:29:44 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 9 Sep 2022 06:29:44 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Windows command
 prompt
In-Reply-To: <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
 <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>
Message-ID: <EP299LVn48-t5mVWSu7N7SoN5S7HGConRvSRHQOsU_k=.0a50e6d3-65a9-4001-a7a0-bb1714b83201@github.com>

On Tue, 9 Aug 2022 20:38:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
>> 
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> I looked at this issue a bit more. It looks to me that the issue is caused by the fact that the encoding of `System.out` falls back to the default encoding, as `IBM864` is not in `java.base`. This issue seems not new and reproducible with the releases since JDK9 where modularization has been introduced. Also, I think other encodings than those `IBM*` listed here, can possibly cause this issue. In order to fix this completely, those obscure encodings also have to be in `java.base` which I don't think we would want to do.

Hello @naotoj .
Sorry for my bad reaction.

I checked these charsets with IBM CDRA definitions.
These are also same, but some round-trip definitions are not same, like #9661 .
I think there come from files under https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/ .
As you know, `CP860/CP861/CP863/CP864/CP865/CP869` are defined into [IANA Character Sets](https://www.iana.org/assignments/character-sets/character-sets.xhtml) as an alias.
Even if the registered names are `IBM*`, these charset implementations are from Microsoft.
I think these charset should be usable as default charset on Windows command prompt.
Please reconsider current Java implementation.

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

PR: https://git.openjdk.org/jdk/pull/9761

From smarks at openjdk.org  Fri Sep  9 17:07:42 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 9 Sep 2022 17:07:42 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v6]
In-Reply-To: <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <-vMSsSpfdN9yInhc30W0R3MNURpC7WuLr0xehsufqxs=.479c0683-e3c3-47cb-b83e-e83108077094@github.com>
Message-ID: <UVNyv7_-VHGVutCdBIH2wWSQcT9lkPPAk01sCM6KibA=.78652eb9-4727-401c-80ce-d62bd7a00106@github.com>

On Thu, 8 Sep 2022 18:32:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary comments

Updates look good, assuming all the tests pass.

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

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Fri Sep  9 17:17:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Sep 2022 17:17:49 GMT
Subject: <i18n dev> Integrated: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <GyZI7XYjr-LusgzJFOQUCey0_TdWYRg7acOJaJ4B3gc=.3bcd5089-2a9e-49cb-94d1-ffcde1a1b298@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

This pull request has now been integrated.

Changeset: b8598b02
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8598b02979dff8a947a523a6d76768a1bfe594b
Stats:     348 lines in 15 files changed: 199 ins; 103 del; 46 mod

8291660: Grapheme support in BreakIterator

Reviewed-by: smarks

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

PR: https://git.openjdk.org/jdk/pull/9991

From naoto at openjdk.org  Fri Sep  9 22:30:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Sep 2022 22:30:41 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Windows command
 prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <wUsVvxt2BvERyA9ogVz9rgrWSXESTlkYfU1ro8pAMFM=.7b3a48f3-ea75-4bb2-aa7a-c2de2cea3975@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

Considering those code page encodings are legacy ones (Microsoft now endorses UTF-8 (cp65001) as the default encoding), I still don't think moving those charsets into java.base module is a good idea. Keeping the base module small is more important IMO.

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

PR: https://git.openjdk.org/jdk/pull/9761

From aivanov at openjdk.org  Tue Sep 13 20:07:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Sep 2022 20:07:53 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
Message-ID: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>

On Tue, 6 Sep 2022 12:42:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

Is `src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c` a third-party code?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 87:

> 85:         J2dTraceLn4(J2D_TRACE_VERBOSE,
> 86:                     "MTLLayer.blitTexture: uninitialized (mtlc=%p, javaLayer=%p, buffer=%p, device=%p)", self.ctx,
> 87:                     self.javaLayer, self.buffer, ctx.device);

Is this an intended change? Or does it come from a merge?

May I suggest wrapping the line after the format string before `self.ctx`? It would make it easier to read.

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

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Tue Sep 13 21:26:53 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:26:53 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
Message-ID: <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>

On Tue, 13 Sep 2022 19:48:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 87:
> 
>> 85:         J2dTraceLn4(J2D_TRACE_VERBOSE,
>> 86:                     "MTLLayer.blitTexture: uninitialized (mtlc=%p, javaLayer=%p, buffer=%p, device=%p)", self.ctx,
>> 87:                     self.javaLayer, self.buffer, ctx.device);
> 
> Is this an intended change? Or does it come from a merge?
> 
> May I suggest wrapping the line after the format string before `self.ctx`? It would make it easier to read.

This is from the merge. The only difference wrt to current code is "devide" => "device". I can change wrapping if you request it, but I'd prefer to only fix typos.

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

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Tue Sep 13 21:30:43 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:30:43 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
Message-ID: <0dmtHVVEvfGWQ94u7xMbddzoHbESy3mV5Gh3vdDrh-A=.10ffa679-739f-457c-b77e-c8b26c36146d@github.com>

On Tue, 13 Sep 2022 20:04:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is `src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c` a third-party code?

I don't think so. I find no comments in the source code, or any kind of indication on this being so. If you say it is, I can revert the changes in that file.

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

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Tue Sep 13 21:36:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:36:10 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
Message-ID: <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>

On Tue, 6 Sep 2022 12:42:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

I see now that Phil cryptically said:

> Regarding changes in gif + freetype
diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
\
diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c \
\
Please exclude ALL 3rd party libraries from this PR.

That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.

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

PR: https://git.openjdk.org/jdk/pull/8328

From prr at openjdk.org  Tue Sep 13 22:05:46 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 13 Sep 2022 22:05:46 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
Message-ID: <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>

On Tue, 13 Sep 2022 21:32:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I see now that Phil cryptically said:
> 
> > Regarding changes in gif + freetype
> > diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c 
> > 
> > diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c 
> > 
> > Please exclude ALL 3rd party libraries from this PR.
> 
> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.

I don't know why I mentioned those two files like that but those particular two are JDK code so are fair game.

I did write 
"Please exclude ALL 3rd party libraries from this PR."
and later :
"We need to revert the native code changes to "libfreetype".
and those points are correct.

You did fix the latter, but there are still some 3rd party files in there that are edited : glext.h, wsutils.h, multiVis.c

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

PR: https://git.openjdk.org/jdk/pull/8328

From andrew at openjdk.org  Wed Sep 14 16:09:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 14 Sep 2022 16:09:50 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <VPDj8Cj9iuKQ0rtWRUGzCJaJsSqM92uEwcbDsouKNy0=.e0767a00-c3f8-44dc-874c-6649ed3ad136@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Should this not have included an update to the resource bundles - as with https://github.com/openjdk/jdk/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 - so that `Europe/Kyiv` is recognised?

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

PR: https://git.openjdk.org/jdk/pull/10012

From andrew at openjdk.org  Wed Sep 14 16:14:47 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 14 Sep 2022 16:14:47 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <suc7iuNWnUL_cV36NJ8p4nGQyiq2OnEQz176x_K2W4I=.931a8930-9c9b-4e6b-a202-62d2cc7e0149@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

That is something we've patched locally e.g. https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/163 and we have a test which fails without and passes with, though it does use `sun.util.resources` directly.

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

PR: https://git.openjdk.org/jdk/pull/10012

From naoto at openjdk.org  Wed Sep 14 19:30:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Sep 2022 19:30:48 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <cZEzP7KDxtNO2fHSNYtsa1voeZpmOySWEETANI33xgQ=.9d727895-bd3b-4827-b3c1-c71cf31ddc29@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Names are retrieved through aliases, so I think there is no need to add extra names in the COMPAT resource bundles.

% ./build/macosx-aarch64/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "?????????"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "?????????"

CLDR incorporated the Kyiv/Kiev aliasing in their upcoming version 42, JDK does not have the alias yet, thus:

%  ./build/macosx-aarch64/jdk/bin/jshell JAVASE                                 
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Kyiv Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "Kyiv??"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "????????"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)

This will be fixed once we incorporate CLDR v42 into JDK repository. Since we don't backport CLDR, TZ backports should separately cherry-pick the changes in timezone.xml, such as:

diff --git a/make/data/cldr/common/bcp47/timezone.xml b/make/data/cldr/common/bcp47/timezone.xml
index f0812776d5d..ddbccff077c 100644
--- a/make/data/cldr/common/bcp47/timezone.xml
+++ b/make/data/cldr/common/bcp47/timezone.xml
@@ -394,7 +394,7 @@ For terms of use, see http://www.unicode.org/copyright.html
             <type name="tvfun" description="Funafuti, Tuvalu" alias="Pacific/Funafuti"/>
             <type name="twtpe" description="Taipei, Taiwan" alias="Asia/Taipei ROC"/>
             <type name="tzdar" description="Dar es Salaam, Tanzania" alias="Africa/Dar_es_Salaam"/>
-            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev"/>
+            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev Europe/Kyiv"/>
             <type name="uaozh" description="Zaporizhia (Zaporozhye), Ukraine" alias="Europe/Zaporozhye"/>
             <type name="uasip" description="Simferopol, Ukraine" alias="Europe/Simferopol"/>
             <type name="uauzh" description="Uzhhorod (Uzhgorod), Ukraine" alias="Europe/Uzhgorod"/>

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

PR: https://git.openjdk.org/jdk/pull/10012

From aivanov at openjdk.org  Wed Sep 14 20:08:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Sep 2022 20:08:47 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
 <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>
Message-ID: <iaKFPi1yXKpSGs9qou4bPbOrZ4T4SC7SwluAtTB4gzo=.be8d2610-82a1-4e72-86d5-30860bad0ae9@github.com>

On Tue, 13 Sep 2022 21:23:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I'd prefer to only fix typos.

Let us keep only the typos.

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

PR: https://git.openjdk.org/jdk/pull/8328

From andrew at openjdk.org  Thu Sep 15 02:01:52 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 15 Sep 2022 02:01:52 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <PDozDO_6mHovqzwEKa81CPMutXS3DMqS6YiH3DjfCVU=.238d2900-113d-47ff-ba76-95551a39dded@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

Interesting, I remember changes like this causing failures in the past. Maybe they were introducing completely new zones. It looks good for the old `java.util` API as well:

~~~
$ ~/builder/trunk/images/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> TimeZone.getTimeZone("Europe/Kyiv").getDisplayName(false, TimeZone.LONG, Locale.US)
$179 ==> "Eastern European Time"
~~~

and similar for 11u & 17u with an updated tzdb. I guess we just need the CLDR change in a backport then.

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

PR: https://git.openjdk.org/jdk/pull/10012

From andrew at openjdk.org  Thu Sep 15 02:22:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 15 Sep 2022 02:22:50 GMT
Subject: <i18n dev> RFR: 8292579: (tz) Update Timezone Data to 2022c
In-Reply-To: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
References: <-TnMh7j1g6YYNA-EIE11kVkTxwPRSHlVHGJUXvrG8SM=.1c2263a9-b90c-478e-bcab-63a40f4d6ac4@github.com>
Message-ID: <i1K28HsAtEV2IvDDaJeUQa9UiMp-9hovbDZy9ZH-AQM=.ac052d80-1ed8-43b5-963d-ee02791336b6@github.com>

On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.

I've opened https://bugs.openjdk.org/browse/JDK-8293834 for the CLDR backport and will open a PR tomorrow for 19u.

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

PR: https://git.openjdk.org/jdk/pull/10012

From naoto at openjdk.org  Mon Sep 19 19:20:18 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 19:20:18 GMT
Subject: <i18n dev> RFR: 8294008: Graphme implementation of setText() throws
 IndexOutOfBoundsException
Message-ID: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>

Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

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

Commit messages:
 - 8294008: Graphme implementation of setText() throws IndexOutOfBoundsException

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

PR: https://git.openjdk.org/jdk/pull/10349

From joehw at openjdk.org  Mon Sep 19 20:49:48 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 20:49:48 GMT
Subject: <i18n dev> RFR: 8294008: Graphme implementation of setText()
 throws IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:

> 327:         @Override
> 328:         public int length() {
> 329:             return src.getEndIndex();

Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.

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

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Mon Sep 19 21:04:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 21:04:52 GMT
Subject: <i18n dev> RFR: 8294008: Graphme implementation of setText()
 throws IndexOutOfBoundsException
In-Reply-To: <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
Message-ID: <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>

On Mon, 19 Sep 2022 20:46:08 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
>
> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:
> 
>> 327:         @Override
>> 328:         public int length() {
>> 329:             return src.getEndIndex();
> 
> Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.

It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.

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

PR: https://git.openjdk.org/jdk/pull/10349

From joehw at openjdk.org  Mon Sep 19 22:10:16 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 22:10:16 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <whMN5DuXhD3HucrHMLxwG1n4JFEWBfesz5FnqwpQSEY=.b4cc3b4c-6d58-4ae3-8308-cce242bb2393@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10349

From joehw at openjdk.org  Mon Sep 19 22:10:17 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 19 Sep 2022 22:10:17 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException
In-Reply-To: <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
Message-ID: <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>

On Mon, 19 Sep 2022 21:02:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 329:
>> 
>>> 327:         @Override
>>> 328:         public int length() {
>>> 329:             return src.getEndIndex();
>> 
>> Could the issue be somewhere else?  I mean it feels correct for length = endIndex - beginIndex.
>
> It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.

Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
286             for (int b = ci.getBeginIndex(); b < end;) {
287                 boundaries.add(b);
288                 b = Grapheme.nextBoundary(text, b, end);
289             }

and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.

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

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Mon Sep 19 22:21:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 22:21:44 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v2]
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <NR-tVVCQ9bpstL82QUacICiw9giirn5eOZMF2gfJlgA=.8df3f0b4-8dcb-4c8e-ab8e-333ed124dab1@github.com>

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

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

  Added comments to length()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10349/files
  - new: https://git.openjdk.org/jdk/pull/10349/files/2b176cd6..85291040

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10349.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10349/head:pull/10349

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Mon Sep 19 22:21:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 Sep 2022 22:21:45 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v2]
In-Reply-To: <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
Message-ID: <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>

On Mon, 19 Sep 2022 22:07:13 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> It's somewhat confusing as this class adapts `CharacterIterator` into `CharSequence` which are similar to each other (thus the bug). Those `beginIndex`/`endIndex` designate the range in the source `CharacterIterator`, and this `length()` method should return the entire text length of the `CharSequence` nevertheless, thus it should start from `0` to `endIndex`.
>
> Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
> 286             for (int b = ci.getBeginIndex(); b < end;) {
> 287                 boundaries.add(b);
> 288                 b = Grapheme.nextBoundary(text, b, end);
> 289             }
> 
> and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.

Thanks, Joe. Added comment to the method.

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

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Mon Sep 19 23:07:43 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 19 Sep 2022 23:07:43 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v2]
In-Reply-To: <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
Message-ID: <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>

On Mon, 19 Sep 2022 22:18:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yeah, I saw there's a mismatch between the src and limit in this call that led to the index check Exception:
>> 286             for (int b = ci.getBeginIndex(); b < end;) {
>> 287                 boundaries.add(b);
>> 288                 b = Grapheme.nextBoundary(text, b, end);
>> 289             }
>> 
>> and nextBoundary could walk through the entire CharSequence. Maybe it's worth a note to the length() method.
>
> Thanks, Joe. Added comment to the method.

OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call

    src.setIndex(index + src.getBeginIndex());

The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.

I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.

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

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Tue Sep 20 01:14:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 01:14:38 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v3]
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

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

  Refine the comments by adding class level description in CharacterIteratorCharSequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10349/files
  - new: https://git.openjdk.org/jdk/pull/10349/files/85291040..f0a65ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10349&range=01-02

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10349.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10349/head:pull/10349

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Tue Sep 20 01:14:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 01:14:39 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v3]
In-Reply-To: <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
 <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
Message-ID: <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>

On Mon, 19 Sep 2022 23:04:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Thanks, Joe. Added comment to the method.
>
> OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call
> 
>     src.setIndex(index + src.getBeginIndex());
> 
> The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.
> 
> I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.

Thanks, Stuart. I used the paragraph almost intact for the class description ?

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

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Tue Sep 20 15:56:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 15:56:02 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v3]
In-Reply-To: <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <OM6U1eNJOgC0WeTitQ2eI0_UGRb9_r2kNbmoSN9TUkg=.8f04c208-46cc-4184-bc66-b30cc1c49c07@github.com>
Message-ID: <ck3ob2bFGMmPHTF7dN88J0gVp2OkqovoixoCB9xjgaw=.e9a2e4d7-77d4-4f4e-835c-12b51cc74b5b@github.com>

On Tue, 20 Sep 2022 01:14:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the comments by adding class level description in CharacterIteratorCharSequence

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10349

From smarks at openjdk.org  Tue Sep 20 15:56:02 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 15:56:02 GMT
Subject: <i18n dev> RFR: 8294008: Grapheme implementation of setText()
 throws IndexOutOfBoundsException [v3]
In-Reply-To: <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
 <9q1PEg15HYOhUIrTfUdKhpbUcXjpppP6JANXsj6Mlsw=.b5a81583-9470-4b68-b824-7a11583a8b70@github.com>
 <8o6GmYySek8iJI4rvXiSMxKhjI8UZyRORQeCVwaidzM=.ae213824-aca7-4162-a0c0-9cd39682160a@github.com>
 <9Zrf4UTRoFOdKg2lMZjHngzPuPnpiR3TgNtgpg_P1Go=.258d28fe-e571-40b9-b5b1-5154d09df9eb@github.com>
 <rJrb_Srn7Q286QXnt6BQjMO4lM3F8tkO9ujKkdVYI74=.0a0830d2-8e56-4bd9-8c19-b09d2c9fe554@github.com>
 <jskb_0PWmITMwGYWcAd95VctIrkEXh_PpC5btLmstZM=.49282989-7524-42c3-a8f4-8b87f7f918c3@github.com>
 <cHC-nc8NQE81Htm6j-uWdr_oLC7AhlHqI1lS-80SejI=.fb87f5d9-5cd5-44b7-96a3-4e1ed8e0c6c0@github.com>
Message-ID: <EB-MSNpWbgoYRihA-sYo6ahG67z52g1Aw47RaT5W7_A=.c88a203b-1672-4aa6-8569-4f4764ff591f@github.com>

On Tue, 20 Sep 2022 01:09:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> OK yeah this is really confusing. One might ask a similar question in `charAt` about why it doesn't call
>> 
>>     src.setIndex(index + src.getBeginIndex());
>> 
>> The answer is that this is a special-purpose `CharSequence` that represents characters in the index range [0..endIndex) of the underlying `CharacterIterator`, **even if** that `CharacterIterator` represents the subrange of some string. As Joe noted, the calling code in `GraphemeBreakIterator` takes care to ensure that only valid indexes into the `src` are used.
>> 
>> I think the comment on `length` helps a little bit but maybe a class-level comment would be better, since it applies to the whole model of this special `CharSequence` and not just the `length` method. Just a sentence or two is sufficient. Feel free to crib from the above.
>
> Thanks, Stuart. I used the paragraph almost intact for the class description ?

OK looks good.

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

PR: https://git.openjdk.org/jdk/pull/10349

From naoto at openjdk.org  Tue Sep 20 16:49:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Sep 2022 16:49:54 GMT
Subject: <i18n dev> Integrated: 8294008: Grapheme implementation of
 setText() throws IndexOutOfBoundsException
In-Reply-To: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
References: <UQtRcEeIUF7NbZYclZu1RNLoLEA8bIfAVkrJ_YpmjhQ=.1243b760-28f1-4433-b269-6a84ef660d6b@github.com>
Message-ID: <KoNMvktPzCGaQzs91scQrMBRjPHMz_z3NNSA_CyB4Sk=.5952203b-42cb-42e5-93ab-6d9ad606d322@github.com>

On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing JCK failures caused by the new grapheme implementation. The length of a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.

This pull request has now been integrated.

Changeset: e3358e77
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3358e77f524f4d448c2ebb7c5afd0aa432f0d44
Stats:     18 lines in 2 files changed: 16 ins; 0 del; 2 mod

8294008: Grapheme implementation of setText() throws IndexOutOfBoundsException

Reviewed-by: joehw, smarks

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

PR: https://git.openjdk.org/jdk/pull/10349

From ihse at openjdk.org  Wed Sep 21 11:49:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:49:11 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v9]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <Z-vGVQyCFE5X1N4KLD21UXXI6z2XF309PkIQU8hgzKw=.cf11bc16-75a9-4ecf-8b41-54304233a686@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes to glext.h
 - Revert changes to multiVis.c and wsutils.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8328/files
  - new: https://git.openjdk.org/jdk/pull/8328/files/1ce28314..e9f67a30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=07-08

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Wed Sep 21 11:52:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:52:57 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes to glext.h
 - Revert changes to multiVis.c and wsutils.h
 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes in libjpeg
 - Revert changes in libfreetype
 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=09
  Stats: 1018 lines in 483 files changed: 0 ins; 0 del; 1018 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328

From ihse at openjdk.org  Wed Sep 21 11:52:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:52:57 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
 <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
Message-ID: <9vrVAfhskr81N1Y120kxvtI9Y9y_Y5G50uDkW1Ynvh0=.569c74fd-5ae2-46f5-8bea-7e903e53ffc9@github.com>

On Tue, 13 Sep 2022 22:03:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> I see now that Phil cryptically said:
>> 
>>> Regarding changes in gif + freetype
>> diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
>> \
>> diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c \
>> \
>> Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
>
>> I see now that Phil cryptically said:
>> 
>> > Regarding changes in gif + freetype
>> > diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c 
>> > 
>> > diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c 
>> > 
>> > Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
> 
> I don't know why I mentioned those two files like that but those particular two are JDK code so are fair game.
> 
> I did write 
> "Please exclude ALL 3rd party libraries from this PR."
> and later :
> "We need to revert the native code changes to "libfreetype".
> and those points are correct.
> 
> You did fix the latter, but there are still some 3rd party files in there that are edited : glext.h, wsutils.h, multiVis.c

@prrace I have now reverted the changes to glext.h, wsutils.h and multiVis.c. Is this finally ready for merging?

(Going forward, I think we absolutely need to have some way to document in the code tree that certain files is 3rd party, like the UPSTREAM notation I previously suggested, or some variant thereof. This "tribal knowledge" about what is 3rd party is not beneficial to anyone, and only wastes both your and my time...)

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Thu Sep 22 01:31:33 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:31:33 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:

> 66: public abstract class MetalTheme {
> 67: 
> 68:     // Constants identifying the various Fonts that a Theme can support

I think this is possibly meant to say "constants that *our* theme can support"?

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Thu Sep 22 01:39:24 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:39:24 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:

> 1432: 
> 1433:     /**
> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).

Suggestion:

     * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Thu Sep 22 01:56:31 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:56:31 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <XCg0TwFX1eu2C06QhdXUNs95QGqcb4COV8MHi7V7Uuc=.894a9033-7a80-4232-8d4b-8527a1c3c6b3@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

Everything looks fine, and you can freely ignore my suggestions. They are just thoughts. And yeah we should probably earmark third party files to avoid "tribal knowledge".

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

PR: https://git.openjdk.org/jdk/pull/8328

From aivanov at openjdk.org  Thu Sep 22 16:58:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 16:58:39 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
Message-ID: <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>

On Thu, 22 Sep 2022 01:29:24 GMT, SWinxy <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes to glext.h
>>  - Revert changes to multiVis.c and wsutils.h
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:
> 
>> 66: public abstract class MetalTheme {
>> 67: 
>> 68:     // Constants identifying the various Fonts that a Theme can support
> 
> I think this is possibly meant to say "constants that *our* theme can support"?

Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.

Possibly it meant to say ?_the_ theme?.

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

PR: https://git.openjdk.org/jdk/pull/8328

From aivanov at openjdk.org  Thu Sep 22 17:03:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 17:03:27 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
Message-ID: <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>

On Thu, 22 Sep 2022 01:35:49 GMT, SWinxy <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes to glext.h
>>  - Revert changes to multiVis.c and wsutils.h
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d
>
> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:
> 
>> 1432: 
>> 1433:     /**
>> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).
> 
> Suggestion:
> 
>      * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.
> 
> I mean this suggestion [might not be warranted](https://github.com/openjdk/jdk/pull/8328/files#r872596373).

I'm for a clearer message:

Parameterless version of `{@code realsSync}` which uses _the_ default timeout of `{@link #DEFAULT_WAIT_TIME}`.

Let us address this in a separate issue.

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Thu Sep 22 17:23:29 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 17:23:29 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
Message-ID: <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>

On Thu, 22 Sep 2022 16:54:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:
>> 
>>> 66: public abstract class MetalTheme {
>>> 67: 
>>> 68:     // Constants identifying the various Fonts that a Theme can support
>> 
>> I think this is possibly meant to say "constants that *our* theme can support"?
>
> Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.
> 
> Possibly it meant to say ?_the_ theme?.

I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.

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

PR: https://git.openjdk.org/jdk/pull/8328

From aivanov at openjdk.org  Thu Sep 22 20:22:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:22:47 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
 <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
Message-ID: <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>

On Thu, 22 Sep 2022 17:21:05 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.
>> 
>> Possibly it meant to say ?_the_ theme?.
>
> I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.

I think the text is correct here: ?that _**a** Theme_ can support

`MetalTheme` is a superclass for classes which implement Themes. Thus the constants define fonts which _a particular theme_ may use.

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

PR: https://git.openjdk.org/jdk/pull/8328

From aivanov at openjdk.org  Thu Sep 22 20:22:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:22:48 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
 <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>
Message-ID: <8wgnrs5UNZfQxgyoSNxQzjszOCUTxDZY2TGXXUs-1W0=.9ce61a4c-9375-4c80-a4f2-645d7972c96c@github.com>

On Thu, 22 Sep 2022 16:59:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:
>> 
>>> 1432: 
>>> 1433:     /**
>>> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).
>> 
>> Suggestion:
>> 
>>      * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.
>> 
>> I mean this suggestion [might not be warranted](https://github.com/openjdk/jdk/pull/8328/files#r872596373).
>
> I'm for a clearer message:
> 
> Parameterless version of `{@code realsSync}` which uses _the_ default timeout of `{@link #DEFAULT_WAIT_TIME}`.
> 
> Let us address this in a separate issue.

[JDK-8294255](https://bugs.openjdk.org/browse/JDK-8294255): Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

Feel free to provide a patch.

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

PR: https://git.openjdk.org/jdk/pull/8328

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.

Done: https://bugs.openjdk.org/browse/SKARA-1566

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
Message-ID: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

Commit messages:
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294321
  Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Sun Sep 25 17:04:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
Message-ID: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>

On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.
> 
> Done: https://bugs.openjdk.org/browse/SKARA-1566

Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue.

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
Message-ID: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>

On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> these changes are mostly fine.

Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?  It doesn't seem useful to make a pull request with known deficiencies.

> we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
 <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
Message-ID: <RWGt4_adstjnxq1OHM-jBMqSjzlLdAqNrpTu3JozTYM=.36dbfb8e-bbfc-4853-ad43-dbeb78bfd92d@github.com>

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?

These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

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

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Sun Sep 25 17:04:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Hello Michael,

> > these changes are mostly fine.
> 
> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies.

I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `<bugid>: <bug summary>`). 
I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
Message-ID: <kqbMO6iHpa3xNDX1Ooa6zLtG9rZJK7mBogbO83RQQLs=.b1cb0e4a-032b-438e-b1a4-7644680ecd6b@github.com>

On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

OK.  I'll repeat my comment from before:

> Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Oh no what happened
![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:

> 1051:    * fetch will take place at index 1.
> 1052:    *
> 1053:    * @return The current position index.

Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
Message-ID: <MnLhhKzLqR1jb7PbtrJu2AlU4xQ5EolX_Zi7TUsJ96g=.e03c2f32-7815-40e8-9450-b66e425c31ef@github.com>

On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Oh no what happened

Oops!  Thanks for pointing out the goof.  It seems to be fixed now.

It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly.  It would be great to merge this pull request to avoid the need for more merges.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:
> 
>> 1051:    * fetch will take place at index 1.
>> 1052:    *
>> 1053:    * @return The current position index.
> 
> Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

Thanks for pointing out the inconsistency.  I have fixed it.  (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.)

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

PR: https://git.openjdk.org/jdk/pull/10029

From alanb at openjdk.org  Sun Sep 25 17:04:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

src/java.base/share/native/libzip/zlib/zlib.h line 756:

> 754:    If this is done, the old level and strategy will be applied to the data
> 755:    compressed before deflateParams(), and the new level and strategy will be
> 756:    applied to the data compressed after deflateParams().

This is an issue for the upstream zlib project, we probably don't want to change it here.

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

PR: https://git.openjdk.org/jdk/pull/10029

From lancea at openjdk.org  Sun Sep 25 17:04:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
Message-ID: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>

On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 
>> 754:    If this is done, the old level and strategy will be applied to the data
>> 755:    compressed before deflateParams(), and the new level and strategy will be
>> 756:    applied to the data compressed after deflateParams().
> 
> This is an issue for the upstream zlib project, we probably don't want to change it here.

Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Sun Sep 25 17:04:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
 <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
Message-ID: <rIuyz9yAlhyXwOpBnnAnmL0xQZbMk6bbr8QP4iogfzk=.33cce124-d245-46de-bb74-f3eaf9dbdfd8@github.com>

On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>> 
>>> 754:    If this is done, the old level and strategy will be applied to the data
>>> 755:    compressed before deflateParams(), and the new level and strategy will be
>>> 756:    applied to the data compressed after deflateParams().
>> 
>> This is an issue for the upstream zlib project, we probably don't want to change it here.
>
> Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

OK.  I backed out the change to zlib.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Sun Sep 25 17:23:28 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:23:28 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <l_BuZBAL5oEJ3CbI12q_XE9gFcXd-qEwGsRrSaIJDd0=.dea17f4e-b629-43e4-bc7e-47fccac4cb3a@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would.

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

PR: https://git.openjdk.org/jdk/pull/10029

From joehw at openjdk.org  Mon Sep 26 16:16:34 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 16:16:34 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <pGtnJ74g_UpsFiU5TaZ6E9jk1p0koWYtWUaoecRoxxk=.e98efc77-50d4-4959-a289-23e6a54380b8@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc.  Otherwise, I would suggest you contribute such changes to the upstream projects.  Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Mon Sep 26 16:41:42 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 16:41:42 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <Kn4w0MAVSML79mjHW-0E4OuGF92CuQ9M5qLOhawWfAA=.2bfefbde-13ac-4b60-b16d-faa9b9d6a553@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/8328

From duke at openjdk.org  Mon Sep 26 16:41:42 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 16:41:42 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
 <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
 <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>
Message-ID: <VYecr3WzqkpHiR2aus9V1J03qMSfZTJkypcNAXtQMm4=.cddd5b34-6887-4b8b-8edd-7f6b02c9eba2@github.com>

On Thu, 22 Sep 2022 20:19:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.
>
> I think the text is correct here: ?that _**a** Theme_ can support
> 
> `MetalTheme` is a superclass for classes which implement Themes. Thus the constants define fonts which _a particular theme_ may use.

Makes sense.

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

PR: https://git.openjdk.org/jdk/pull/8328

From mernst at openjdk.org  Mon Sep 26 16:51:36 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Mon, 26 Sep 2022 16:51:36 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01
  Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From joehw at openjdk.org  Mon Sep 26 17:04:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 17:04:25 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <tTqHK2uU740KHuTMKapHnLcgfUbNs-4NqM-tQpds9HQ=.ba0b289d-011f-4f84-beeb-e20dd15a7d67@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thanks for the update!

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

PR: https://git.openjdk.org/jdk/pull/10029

From lancea at openjdk.org  Mon Sep 26 19:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:38:20 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thank you for your efforts on the cleaning up these typos

I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.  

I realize the changes are fairly trivial but this will most likely expedite getting your changes back

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Mon Sep 26 22:17:41 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: <i18n dev> RFR: 8272687: Replace StringBuffer with StringBuilder in
 RuleBasedCollator
Message-ID: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>

Problem: Unnecessary instances of StringBuffer + .toString()

Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible

Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder

automated testing run passed cleanly

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

Commit messages:
 - Copyright update for fix
 - Merge master into fix branch
 - Fix: replace instances of StringBuffer with StringBuilder, drop String conversion

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

PR: https://git.openjdk.org/jdk/pull/10432

From lancea at openjdk.org  Mon Sep 26 22:17:41 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: <i18n dev> RFR: 8272687: Replace StringBuffer with
 StringBuilder in RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <LBRXLw0d5JKs6r5PnXvmh1CAWTdMFwHaXwFpD9WiqCY=.41629ae8-8ba3-4eef-a35a-f4f96e22c71e@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

The changes look good Justin.

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10432

From naoto at openjdk.org  Mon Sep 26 22:17:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: <i18n dev> RFR: 8272687: Replace StringBuffer with
 StringBuilder in RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <9wwdMSrZ0ie0sGXoxDcX9XWLL7Syb-Z2jqvaj3qlTwE=.a2cc6270-a657-4aa2-97ff-4f91925de043@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10432

From bchristi at openjdk.org  Mon Sep 26 22:17:41 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 26 Sep 2022 22:17:41 GMT
Subject: <i18n dev> RFR: 8272687: Replace StringBuffer with
 StringBuilder in RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <HBcmRAAZJ8EBhtr5yIbdSfpoUDo_rnG3Ja3SCn_SG-o=.8f435d77-d8a0-4c13-84e0-0bb6e65778f1@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Looks good!

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

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10432

From bpb at openjdk.org  Mon Sep 26 22:23:45 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Sep 2022 22:23:45 GMT
Subject: <i18n dev> RFR: 8272687: Replace StringBuffer with
 StringBuilder in RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <bMCB2iteqxKE3HJR5TMEHkK_J3xkAUTR6YOTRkyywuQ=.b16d9182-0a81-4b90-963d-c359e9324bcb@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10432

From duke at openjdk.org  Mon Sep 26 22:34:40 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 26 Sep 2022 22:34:40 GMT
Subject: <i18n dev> Integrated: 8272687: Replace StringBuffer with
 StringBuilder in RuleBasedCollator
In-Reply-To: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
References: <6FHBd4vRdnguVSgq1IM3wg569qKcwmgUyPFSDGTDfdU=.9591d145-88c4-4d57-bb34-5b0a12b5e46c@github.com>
Message-ID: <2R35rpu5H3silZ4Neb4dhA5qnS6y0PUivFH17OgYUTQ=.ffca51b2-95f8-48b2-acaa-c385b73216ec@github.com>

On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer + .toString()
> 
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when possible
> 
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion, but removing that instance requires changing the RuleBasedCollationKey constructor's second parameter type from String to StringBuilder
> 
> automated testing run passed cleanly

This pull request has now been integrated.

Changeset: 43eff2b3
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43eff2b309e2ef275bdd5adf196da81d4e23f535
Stats:     10 lines in 2 files changed: 0 ins; 0 del; 10 mod

8272687: Replace StringBuffer with StringBuilder in RuleBasedCollator

Reviewed-by: lancea, naoto, bchristi, bpb

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

PR: https://git.openjdk.org/jdk/pull/10432

From aturbanov at openjdk.org  Tue Sep 27 19:21:09 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 Sep 2022 19:21:09 GMT
Subject: <i18n dev> RFR: 8294472: Remove redundant rawtypes suppression in
 AbstractChronology
Message-ID: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>

Found this redundant suppressions by IntelliJ IDEA inspection.
Seems initially `Chronology` was generic class?

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

Commit messages:
 - [PATCH] Remove redundant rawtypes suppression in AbstractChronology

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

PR: https://git.openjdk.org/jdk/pull/10433

From lancea at openjdk.org  Tue Sep 27 19:40:16 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Sep 2022 19:40:16 GMT
Subject: <i18n dev> RFR: 8294472: Remove redundant rawtypes suppression
 in AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <f2JqJ_hv8G7iS6_H2oikR3ZTC_QQre2NMxSM81Z4yDQ=.883258a4-516f-4d20-afd2-d66d5ec2a05c@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10433

From naoto at openjdk.org  Tue Sep 27 20:45:32 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Sep 2022 20:45:32 GMT
Subject: <i18n dev> RFR: 8294472: Remove redundant rawtypes suppression
 in AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <qd2fQKXxfLF6tBN1cVELZgLwOzeeEViHvbmhqJJMWLw=.6a376e2b-2adc-486d-992c-9d787613dc8c@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

+1

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10433

From mernst at openjdk.org  Tue Sep 27 23:16:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Sep 2022 23:16:16 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>

On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for your efforts on the cleaning up these typos
> 
> I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.
> 
> I realize the changes are fairly trivial but this will most likely expedite getting your changes back

Feel free to break up the pull request if that is what is needed to free it from red tape.
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10029

From dfuchs at openjdk.org  Wed Sep 28 13:24:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:24:26 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
 <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
Message-ID: <aY7BXF5EIYZFFZcE_IWj3PwKjQLD35cJPnaJkvQpQmU=.5464c3b4-6a6b-4841-b24f-969b371dfc74@github.com>

On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Feel free to break up the pull request if that is what is needed to free it from red tape.

Only you can do that @mernst

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Wed Sep 28 14:49:20 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 14:49:20 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Regarding breaking up the pull request:
 * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
 * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
 * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.

I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections.

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

PR: https://git.openjdk.org/jdk/pull/10029

From dfuchs at openjdk.org  Wed Sep 28 15:13:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 15:13:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
Message-ID: <kTzLFBRbJQt3hKHD094hV-0zXH9FY4Fg2wdrOvFeK34=.c79081a5-df9a-4ea0-b481-19f903f56bd9@github.com>

On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> Regarding breaking up the pull request:
>  * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
>  * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams.  The only reasons stated have been custom and bureaucracy.
>  * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
>  * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions.  No pointer to documentation in the JDK itself, about pull requests, was given.
>  * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.
> 
> I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions.

Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas:

-     client
-     compiler
-     core-libs
-     hotspot
-     i18n
-     javadoc
-     jmx
-     net
-     nio
-     security
-     serviceability

Jaikiran suggested to reduce the scope of this PR in his first comment:
https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632

as did several other reviewers. Sorry if the meaning (or reason) was not clear.

best regards,

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

PR: https://git.openjdk.org/jdk/pull/10029

From aivanov at openjdk.org  Wed Sep 28 15:28:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:28:24 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Wed Sep 28 15:35:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 15:35:40 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
Message-ID: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>

On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

The title was edited by someone other than me, as you can see from the PR history.

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

PR: https://git.openjdk.org/jdk/pull/10029

From aturbanov at openjdk.org  Wed Sep 28 18:47:22 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 28 Sep 2022 18:47:22 GMT
Subject: <i18n dev> Integrated: 8294472: Remove redundant rawtypes
 suppression in AbstractChronology
In-Reply-To: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
References: <Mfc999qMfld7wI8f3N9OKJUHXPqGfyfqKDHWQVabH88=.e04341d2-1a91-4489-ae69-100343891d62@github.com>
Message-ID: <FJ8GhPRS6A0V281YruR0ItAEMU6Nvl0esMiaAN4NlgY=.65bea7f0-b337-42f1-bc83-3b866af5e95f@github.com>

On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?

This pull request has now been integrated.

Changeset: 9309786d
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9309786dbfa584e7762c8011e3942f02d352d2e6
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8294472: Remove redundant rawtypes suppression in AbstractChronology

Reviewed-by: lancea, naoto

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

PR: https://git.openjdk.org/jdk/pull/10433

From duke at openjdk.org  Thu Sep 29 21:27:02 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 21:27:02 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with StringBuilder
 within java.text
Message-ID: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>

Problem: Unnecessary instances of StringBuffer within java.text (internal only)

Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

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

Commit messages:
 - Update PatternEntry test case for StringBuilder
 - Copyright update
 - Replace buffer in both, adjust addToBuilder dependencies
 - Adjust variable names within DigitList
 - Fix: Replace StringBuffer in CollationElementIterator
 - Fix: replace StringBuffer with StringBuilder

Changes: https://git.openjdk.org/jdk/pull/10475/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294397
  Stats: 35 lines in 5 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 21:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 21:38:20 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Looks good.

should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 21:51:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 21:51:43 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
Message-ID: <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>

On Thu, 29 Sep 2022 21:34:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?

Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen

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

PR: https://git.openjdk.org/jdk/pull/10475

From bchristi at openjdk.org  Thu Sep 29 21:51:43 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 29 Sep 2022 21:51:43 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
 <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
Message-ID: <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>

On Thu, 29 Sep 2022 21:48:52 GMT, Justin Lu <duke at openjdk.org> wrote:

> should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?


/*
    (this test doesn't have an at-test tag because it's run by Bug4170614TestRun.java
     instead of directly by the test harness)
*/

:)

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

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 21:58:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 21:58:21 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <Rn_ql55nLv1vN-Zoq6NPAipzUQulUAjuJBZvei2hj7Y=.085c2b36-5de8-4bcf-81e3-aeaa94958154@github.com>
 <cX5-qU_wl7WQRuBoCC0RrFAgZgFvXZqcE_tWNDf8OGA=.b205ca38-1548-4aa8-8d7e-0d627f3fe97d@github.com>
 <0V9OZIDGjTl4mNUFSqeGQXRZUzG8hIBLjixuoISbS1I=.c5c0d643-2e83-4870-b27e-fae90e16aafb@github.com>
Message-ID: <9_WnJ6L0hddDDWuv0_ePWSASObEVohCHIJqCCRacFvw=.9cae45d1-5d97-423e-96ee-aeed57c78ecd@github.com>

On Thu, 29 Sep 2022 21:49:05 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> ```
> /*
>     (this test doesn't have an at-test tag because it's run by Bug4170614TestRun.java
>      instead of directly by the test harness)
> */
> ```
> 
> :)

Justin, Brent

Thanks for pointing that out.   Do either of you know why this is configured as it is as I am not sure I see a reason for the wrapper?

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

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Thu Sep 29 22:12:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Sep 2022 22:12:30 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

AFAICT, the reason is described in the test class description, i.e., tweak to be in `java.text` package so that it can test the internal `hashCode` method.

btw I find a typo there:

* Bug #4170614 complained that we had two iternal classes that

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 22:15:00 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 22:15:00 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v2]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust typo within test description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/ea2bc5e7..e02edf67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 22:26:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 22:26:35 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v2]
In-Reply-To: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
Message-ID: <uVmN8TUOx2B9EiSYVLfoXl5IuP9QoumcR00ZDNNKWu8=.2b7ba17a-d7b4-4f7f-a739-c7c053de170c@github.com>

On Thu, 29 Sep 2022 22:15:00 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust typo within test description

Marked as reviewed by lancea (Reviewer).

> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen



> > should we update test/jdk/sun/text/IntHashtable/patch-src/java.base/java/text/Bug4170614Test.java to include `@test, @bug, @run, @summary`?
> 
> Brent actually pointed that out to me as well. I believe since Bug4170614Test.java is managed by Bug4170614TestRun.java which has tags, then it would be fine to not include the tags(in Bug4170614Test.java), but please let me know your thoughts. @LanceAndersen

Hi Justin,

Yes if the wrapper class is needed then we do not need the tags in the actual test.

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

PR: https://git.openjdk.org/jdk/pull/10475

From lancea at openjdk.org  Thu Sep 29 22:26:35 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Sep 2022 22:26:35 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
Message-ID: <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>

On Thu, 29 Sep 2022 22:07:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> AFAICT, the reason is described in the test class description, i.e., tweak to be in `java.text` package so that it can test the internal `hashCode` method.

Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety  I am missing (wouldn't be the first time ;-) )

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

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Thu Sep 29 22:34:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Sep 2022 22:34:19 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
Message-ID: <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>

On Thu, 29 Sep 2022 22:19:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )

The runner has a @library/@build tag to build the test case as a library for the said reason.

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

PR: https://git.openjdk.org/jdk/pull/10475

From bchristi at openjdk.org  Thu Sep 29 22:34:24 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 29 Sep 2022 22:34:24 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v2]
In-Reply-To: <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
Message-ID: <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>

On Thu, 29 Sep 2022 22:15:00 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust typo within test description

src/java.base/share/classes/java/text/DigitList.java line 808:

> 806:         }
> 807:         return tempBuilder;
> 808:     }

Is it worth considering whether it's still necessary to cache and reuse a single String[Buffer|Builder] instance when using 2022 garbage collectors?

src/java.base/share/classes/java/text/PatternEntry.java line 117:

> 115:                      boolean showExtension,
> 116:                      boolean showWhiteSpace,
> 117:                      PatternEntry lastEntry)

Nit: update the indentation on these lines

src/java.base/share/classes/java/text/PatternEntry.java line 291:

> 289:         // We re-use these objects in order to improve performance
> 290:         private StringBuilder newChars = new StringBuilder();
> 291:         private StringBuilder newExtension = new StringBuilder();

Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Thu Sep 29 22:44:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 29 Sep 2022 22:44:43 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v3]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <lo5pfg_gUjctlGjXpVwkYWAvAGgrC3D7sU-YdxFOy0M=.da974483-38f8-477d-9e6e-398a59765fb0@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Tweak indentation in PaternEntry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/e02edf67..cd966f31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Fri Sep 30 00:03:35 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 00:03:35 GMT
Subject: <i18n dev> RFR: 8294307: ISO 4217 Amendment 173 Update
Message-ID: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>

Problem: Amendment number outdated

Fix: Update amendment number + date in properties file and test case data file

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

Commit messages:
 - Update amendment number in test case data file
 - Update amendment number

Changes: https://git.openjdk.org/jdk/pull/10499/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294307
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10499.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10499/head:pull/10499

PR: https://git.openjdk.org/jdk/pull/10499

From lancea at openjdk.org  Fri Sep 30 00:21:36 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Sep 2022 00:21:36 GMT
Subject: <i18n dev> RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <57AQADcwjE5ew8vvvRKjcfW9l5HgzXGaPdEK-T_jC-k=.0b6f11a6-ac0d-44ea-ba92-88312b6d1f29@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

looks good to me

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10499

From lancea at openjdk.org  Fri Sep 30 00:29:17 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Sep 2022 00:29:17 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
 <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
Message-ID: <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>

On Thu, 29 Sep 2022 22:29:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )
> 
> The runner has a @library/@build tag to build the test case as a library for the said reason.

Ok, thanks Naoto

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

PR: https://git.openjdk.org/jdk/pull/10475

From ysatowse at openjdk.org  Fri Sep 30 00:36:54 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 00:36:54 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
Message-ID: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>

Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

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

Commit messages:
 - Added minor changes in comment lines
 - reverting irrelvant change in pom.xml
 - 1st commit for tz2022d

Changes: https://git.openjdk.org/jdk/pull/10460/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294357
  Stats: 105 lines in 11 files changed: 31 ins; 55 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10460.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10460/head:pull/10460

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 00:36:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 00:36:54 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <Ud-PCouqcyoN3FVsKkkuGjcLIXLiuKGkocs0wY9Kuec=.c08af7dc-ced8-42c6-a9fb-72c8c0f0cf33@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

Some minor comments

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 588:

> 586:                     // will not work for Asia/Gaza and Asia/Hebron which follow
> 587:                     // Palestine DST rules.
> 588:                     // No need of hacking for Plaestine DST rules from tz2022d

Should this comment be removed, or at least modified to be better explained?

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

> 199:                 zid.equals("Asia/Tehran") || // last rule mismatch
> 200:                 zid.equals("Asia/Gaza") ||
> 201:                 zid.equals("Asia/Hebron") ||

It'd be helpful to append `// uses "Palestine" rule`.

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

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 03:36:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 03:36:15 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text
In-Reply-To: <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <I0pOPJcXxnvEQH4YWOgPUOLAQEwemkWbmOODGTvX9VI=.9bf13cd7-3da9-4698-b3ac-354152acb6d1@github.com>
 <ulkwaHRYr1Z7P9CfNSfpGy3aFKoSTu5Zo4TBPLMKXVU=.abbfd0db-69a5-4984-a0d9-9a2aaae3a882@github.com>
 <4-c7dC9feD9vgVdjtLf3rgcmBi6yM2kvYErlwzqvDhQ=.2dce9d38-d3af-4038-8ba9-ce462191ddd1@github.com>
 <K1Her0bg1xAMH_07XqEQqycDK9psBgeedS-guo0ewio=.27ea5945-e599-4c63-aab8-9ac8c0eac6e9@github.com>
Message-ID: <lAFpj8p2EvfLjYgToKW1x82QcaSrqLP1MnBKRymqB_M=.5fcffa24-9c25-4f5f-8c20-1341fead7b94@github.com>

On Fri, 30 Sep 2022 00:25:24 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > Understand, I guess I don't see the difference from moving the tags to the actual test but there could be a subtlety I am missing (wouldn't be the first time ;-) )
> > 
> > 
> > The runner has a @library/@build tag to build the test case as a library for the said reason.
> 
> Ok, thanks Naoto

You are correct, Lance. Yes, the wrapper can be removed. Sorry for the confusion.

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

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Fri Sep 30 04:20:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 04:20:39 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:

> 168: Europe/Vilnius EET EEST
> 169: Europe/Warsaw CET CEST
> 170: Europe/Zaporozhye EET EEST

Do we need to remove those newly linked zone ids from testing?

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

PR: https://git.openjdk.org/jdk/pull/10460

From ysatowse at openjdk.org  Fri Sep 30 04:56:30 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 04:56:30 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
 <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
Message-ID: <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>

On Fri, 30 Sep 2022 04:17:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.
>
> test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
> 
>> 168: Europe/Vilnius EET EEST
>> 169: Europe/Warsaw CET CEST
>> 170: Europe/Zaporozhye EET EEST
> 
> Do we need to remove those newly linked zone ids from testing?

This file is not maintained by hand but generated from java/util/TimeZone/TimeZoneData/tools/share/Makefile.  
These two Ukraine zones are integrated to Europe/Kyiv and removed from tzdata/europe, so the entries disappeared in this file.

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

PR: https://git.openjdk.org/jdk/pull/10460

From coffeys at openjdk.org  Fri Sep 30 05:45:07 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 30 Sep 2022 05:45:07 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <Pg3Rhe2fBD_qIBhL18JqYIpBbcMt2Vt9F-G8UjjZi8Y=.a6b19cbc-a774-41ab-98d0-0e50ae73c03d@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 12:46:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 12:46:17 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <y1vih96QjE9A2a5HuLNVRMiLu6GgYncxrq3FEnSxUBw=.5daa91f6-4bf0-40e0-877e-d19ee93f9a6f@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10460

From naoto at openjdk.org  Fri Sep 30 12:46:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 12:46:19 GMT
Subject: <i18n dev> RFR: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
 <AyAedAdzSPb37eR0YHi3PV34HeMQFsNJnZNvduK3kys=.8ec5fbc6-faa6-4400-8bec-a9ef93d9caf9@github.com>
 <q54rfW8kz15BHtjpf_SgCYHxL1iGlNTM8YvkdER9Uwo=.f341d1f7-529d-4dc7-b68b-174831bd4a07@github.com>
Message-ID: <WbJ6usbWjyaTYL8QSbXYhPhURoCpljE-sFpIfTG99I8=.5b850f4b-872d-41a0-8557-a34b865d2ad9@github.com>

On Fri, 30 Sep 2022 04:54:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
>> 
>>> 168: Europe/Vilnius EET EEST
>>> 169: Europe/Warsaw CET CEST
>>> 170: Europe/Zaporozhye EET EEST
>> 
>> Do we need to remove those newly linked zone ids from testing?
>
> This file is not maintained by hand but generated from java/util/TimeZone/TimeZoneData/tools/share/Makefile.  
> These two Ukraine zones are integrated to Europe/Kyiv and removed from tzdata/europe, so the entries disappeared in this file.

OK. It's a bit odd that the links are removed for the test because they still exist as zone ids, and should have the same name as `Europe/Kyiv`.

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

PR: https://git.openjdk.org/jdk/pull/10460

From ysatowse at openjdk.org  Fri Sep 30 12:49:20 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 30 Sep 2022 12:49:20 GMT
Subject: <i18n dev> Integrated: 8294357: (tz) Update Timezone Data to 2022d
In-Reply-To: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
References: <d0VR2DsGI8lvviROr676OVP_uGBkzt1CSrVOGS0l5xY=.8e79029d-ca1d-4c41-acfc-c308395319b3@github.com>
Message-ID: <GWvkSe-WnZ0EWgds_kCyuNnyaYmeMms0zzfZMshVZqg=.d0040a44-0746-49e7-a38d-3f316d198ef4@github.com>

On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  The change include some code changes in ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks TestZoneInfo310.java.

This pull request has now been integrated.

Changeset: f0157336
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f01573368f905f27d26f1d07d9cfd26dcc736a54
Stats:     105 lines in 11 files changed: 31 ins; 55 del; 19 mod

8294357: (tz) Update Timezone Data to 2022d

Reviewed-by: naoto, coffeys

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

PR: https://git.openjdk.org/jdk/pull/10460

From duke at openjdk.org  Fri Sep 30 13:52:36 2022
From: duke at openjdk.org (Eivind =?UTF-8?B?QmVyZ3N0w7hs?=)
Date: Fri, 30 Sep 2022 13:52:36 GMT
Subject: <i18n dev> RFR: 8282227: Locale information for nb is not
 working properly
In-Reply-To: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
References: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
Message-ID: <D2QYXTtITb4HrMLQH5Jj56hAwS6hiqc1wM2fv2GQ9lU=.fd177356-bfb3-4410-8ab1-4c1e960c32f3@github.com>

On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue.

Will this fix make its way back to java 17?

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

PR: https://git.openjdk.org/jdk/pull/8394

From bpb at openjdk.org  Fri Sep 30 14:57:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Sep 2022 14:57:23 GMT
Subject: <i18n dev> RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <XSXpq-6ATmG-dljbyL95rhbxhHoMF-dw5M9z4XIx1kk=.629424cb-24c4-4e1d-afab-1a6461816726@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10499

From duke at openjdk.org  Fri Sep 30 16:18:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 30 Sep 2022 16:18:28 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v3]
In-Reply-To: <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
Message-ID: <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>

On Thu, 29 Sep 2022 22:29:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak indentation in PaternEntry
>
> src/java.base/share/classes/java/text/PatternEntry.java line 291:
> 
>> 289:         // We re-use these objects in order to improve performance
>> 290:         private StringBuilder newChars = new StringBuilder();
>> 291:         private StringBuilder newExtension = new StringBuilder();
> 
> Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.

Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903

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

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Fri Sep 30 16:30:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 16:30:42 GMT
Subject: <i18n dev> RFR: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <bZmqEoNm0_k288-BbsAEw0eu24BxgcagCTPX7HhFoAk=.8015e2a7-fcc8-4f89-9844-af0de61435a6@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10499

From bchristi at openjdk.org  Fri Sep 30 16:56:20 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 30 Sep 2022 16:56:20 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v3]
In-Reply-To: <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
 <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
Message-ID: <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>

On Fri, 30 Sep 2022 16:14:38 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/PatternEntry.java line 291:
>> 
>>> 289:         // We re-use these objects in order to improve performance
>>> 290:         private StringBuilder newChars = new StringBuilder();
>>> 291:         private StringBuilder newExtension = new StringBuilder();
>> 
>> Again, in 2022, I don't know that this cache+reuse pattern is needed for performance.
>
> Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903

Thanks. I was not suggesting that we use string concatenation, but rather just remove the `newChar`/`newExtension` fields, and replace, e.g.:
`214             newChars.setLength(0);`
with
`214            StringBuilder newChars = new StringBuilder();`
though I'll admit that I don't have a good sense of whether that's worth doing.

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Fri Sep 30 17:13:26 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 17:13:26 GMT
Subject: <i18n dev> Integrated: 8294307: ISO 4217 Amendment 173 Update
In-Reply-To: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
References: <LwGHj6uO96npFnZooUdQhkCGynrdTGVsTKW5ogE27nY=.b4b6e06b-fd1f-40f4-bd3a-dca742540e8b@github.com>
Message-ID: <yjgIDDp_cgMvpQxNNMmmk1N_UwjTQYMKbeBKPt-om7c=.dfe6f82b-43de-4066-b2bd-b2918178804c@github.com>

On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Amendment number outdated
> 
> Fix: Update amendment number + date in properties file and test case data file

This pull request has now been integrated.

Changeset: 3b1bc217
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b1bc21727636cb50cd04d958031832f48fe17e3
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8294307: ISO 4217 Amendment 173 Update

Reviewed-by: lancea, bpb, naoto

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

PR: https://git.openjdk.org/jdk/pull/10499

From rriggs at openjdk.org  Fri Sep 30 17:36:24 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Sep 2022 17:36:24 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v3]
In-Reply-To: <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <xrmZ8iFlP7a0nxPA63ytSX4LMbwfX74Ql5LLmQ2MBpg=.a71088ce-2541-4151-a765-2badff8d6f86@github.com>
 <7R_FJi6DYp4rE7nHNvpW6LPOsa5L_e7ul1ii1t8QeIA=.a8628f49-e0ce-41ee-8c7e-4e8f7faf983e@github.com>
 <tc5rcYHhEMUUnxTi7Mxsr1oeEZfSp5lCwO_d-J_DN9s=.6d770e42-75cd-4b27-b5b4-06bfc50e5b87@github.com>
 <z8HUkpBrbxW8--Em1sgnTG29-sTk6ruQRn4ck182Gus=.b69f830a-12c9-4ef8-adbf-ea46346e4d1d@github.com>
Message-ID: <_A18rxGSIcrT7YHYxDUF23T4Vt3FWKl0Tm9e8wQmt14=.10babfbc-fd94-4af1-9a6a-01c837a7568e@github.com>

On Fri, 30 Sep 2022 16:52:40 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Due to some [bootstrapping issues](https://stackoverflow.com/questions/71834059/why-invokedynamic-based-string-concatenation-is-not-available-for-javac-in-java) in `java.base` explicit String concatenation is not translated into invokedynamic, so in practice it's faster to use `StringBuilder.append()` than `str1 + str2`, see e.g. https://github.com/openjdk/jdk/pull/3903
>
> Thanks. I was not suggesting that we use string concatenation, but rather just remove the `newChar`/`newExtension` fields, and replace, e.g.:
> `214             newChars.setLength(0);`
> with
> `214            StringBuilder newChars = new StringBuilder();`
> though I'll admit that I don't have a good sense of whether that's worth doing.

Memory you don't allocate doesn't need to be GC'd.  I'd leave it alone and save the GC overhead.

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

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Fri Sep 30 20:08:10 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 30 Sep 2022 20:08:10 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove comment typo
 - Remove test wrapper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/cd966f31..442c2a4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=02-03

  Stats: 45 lines in 3 files changed: 9 ins; 35 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Fri Sep 30 23:53:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Sep 2022 23:53:28 GMT
Subject: <i18n dev> RFR: 8294397: Replace StringBuffer with
 StringBuilder within java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <i4l8P0SMuF6c5ERrJfU8lLNegPzBwtIE6SGaZ6EJZOo=.fdbed496-97cd-45e7-a070-b615fa83f8c2@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

LGTM. Thanks for removing the unnecessary wrapper.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475