From redestad at openjdk.java.net  Mon Aug  2 11:22:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 2 Aug 2021 11:22:44 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11]
In-Reply-To: <bxpkAvClK09ExpSL7KeZj9nZqCKHj-b7thCYa75EfuE=.2ad4ad96-2529-47d8-96ea-d90db7fc0e12@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <bxpkAvClK09ExpSL7KeZj9nZqCKHj-b7thCYa75EfuE=.2ad4ad96-2529-47d8-96ea-d90db7fc0e12@github.com>
Message-ID: <1tMR5seQ0nt1U7RbpVx7RNgvMl9Eov8JRVmmjASa5HQ=.b4f65b78-74ee-457b-b9db-e1acbfff80c2@github.com>

On Mon, 26 Jul 2021 08:27:14 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().
>
> ?????? ??????? 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8268113
>  - 8270160 Revert changes in BitSet.hashCode
>  - Merge branch 'master' into 8268113
>  - 8270160 Revert changes in BitSet.hashCode
>  - Merge branch 'master' into 8268113
>  - Merge branch 'master' into 8268113
>  - Merge branch 'master' into 8268113
>  - Merge branch 'master' into 8268113
>  - Merge branch 'master' into 8268113
>  - Merge branch 'master' into 8268113
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/1d801fa0...bd762b7d

All changes look good to me, though 3rd party sources like xerces/.../DoubleDV.java should probably be dealt with in the upstream first. @AlanBateman probably knows who maintains and downstreams this usually (or whether we are now practically maintaining a fork of xerces)?

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

Marked as reviewed by redestad (Reviewer).

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Aug  2 12:52:34 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 2 Aug 2021 12:52:34 GMT
Subject: Integrated: 8268113: Re-use Long.hashCode() where possible
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <paTce5zPyhOZzHCbt7uZCUNtQSka7jeJBc0-05s7ins=.7e38d8c1-261d-4d2b-ba16-8817fd295d62@github.com>

On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

This pull request has now been integrated.

Changeset: 6a3f8343
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a3f8343bc0e92c29a87c5840cbef9ab2988f153
Stats:     10 lines in 6 files changed: 0 ins; 4 del; 6 mod

8268113: Re-use Long.hashCode() where possible

Reviewed-by: redestad

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

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

From jjg at openjdk.java.net  Thu Aug  5 19:26:50 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 19:26:50 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
Message-ID: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>

Please review a semi-automatic update of the nroff man pages from the upstream files.

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

Commit messages:
 - JDK-8270872: Final nroff manpage update for JDK 17

Changes: https://git.openjdk.java.net/jdk17/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270872
  Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/303/head:pull/303

PR: https://git.openjdk.java.net/jdk17/pull/303

From darcy at openjdk.java.net  Thu Aug  5 19:44:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 Aug 2021 19:44:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aWsXaUX5hmJ55kEcFzOXW7NqpE9NgjKXkZrDuNOHFJo=.2e213a1d-9d49-41ac-92d7-166ef9c08c67@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 20:01:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 20:01:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:

> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.

This seems not correct?

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 20:13:39 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 20:13:39 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <jv6rEFb4aLBK1e6FBH186cyOqbPFVYLvomqdfzafljA=.95892c77-ab88-422f-91fc-343dfe6f99c6@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by mr (Lead).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From iris at openjdk.java.net  Thu Aug  5 20:40:40 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 5 Aug 2021 20:40:40 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <liAhrSHq9y4NbW5DufoiKCG95FcISducefm4wUe8ocE=.57c889b5-b016-4678-9980-e62769b62f8d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 21:39:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 21:39:38 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
Message-ID: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>

On Thu, 5 Aug 2021 19:57:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review a semi-automatic update of the nroff man pages from the upstream files.
>
> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
> 
>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> This seems not correct?

According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.

I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.

This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.

I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
Message-ID: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>

On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
>> 
>>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>> 
>> This seems not correct?
>
> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
> 
> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
> 
> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
> 
> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

Thanks for the explanation, Jon. Fine by me.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:35 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aq2UDjtBswQl63RvqgMXPgYZu5Eo9b34GJqGM0YzOpE=.185c7174-d0dd-4b52-9815-f7909a45187a@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
 <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
Message-ID: <k4aobJsxKwpdOZQqr1GFaBhAGbMh16e4EUxpDAql-Us=.5d7d0799-8d1c-42a0-91a2-44b0912ed475@github.com>

On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
>> 
>> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
>> 
>> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
>> 
>> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.
>
> Thanks for the explanation, Jon. Fine by me.

I agree that fixing this date is not necessary at this time.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 22:15:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 22:15:29 GMT
Subject: [jdk17] Integrated: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <k3Bqh5GeG3FgEBh_9rbFrDjJrTd6VSoO2S-KYSPIY_s=.50ab8e33-39b0-4ca9-9931-61cb55ec5c0d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

This pull request has now been integrated.

Changeset: dfacda48
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/dfacda488bfbe2e11e8d607a6d08527710286982
Stats:     289 lines in 27 files changed: 117 ins; 31 del; 141 mod

8270872: Final nroff manpage update for JDK 17

Reviewed-by: darcy, mr, iris, naoto

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jwilhelm at openjdk.java.net  Thu Aug  5 23:57:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 5 Aug 2021 23:57:59 GMT
Subject: RFR: Merge jdk17
Message-ID: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8270872: Final nroff manpage update for JDK 17
 - 8271588: JFR Recorder Thread crashed with SIGSEGV in write_klass
 - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
  Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

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

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <1oUovSIU_RoljyN5VHPljZLMI5NpHqK3ys9BDhsuLI8=.15d53c62-802e-4982-9415-527c302b8ab4@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 440 commits:

 - Merge
 - 8271293: Monitor class should use ThreadBlockInVMPreprocess
   
   Reviewed-by: dholmes, dcubed
 - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS
   
   Reviewed-by: psadhukhan, aivanov
 - 8271905: mark hotspot runtime/Metaspace tests which ignore external VM flags
   
   Reviewed-by: stuefe
 - 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call
   
   Reviewed-by: alanb, vtewari
 - 8271953: fix mis-merge in JDK-8271878
   
   Reviewed-by: jwilhelm, ctornqvi
 - 8267840: Improve URLStreamHandler.parseURL()
   
   Reviewed-by: dfuchs, redestad
 - 8271840: Add simple Integer.toString microbenchmarks
   
   Reviewed-by: shade
 - 8271121: ZGC: stack overflow (segv) when -Xlog:gc+start=debug
   
   Reviewed-by: ayang, eosterlund
 - 8270903: sun.net.httpserver.HttpConnection: Improve toString
   
   Reviewed-by: chegar, vtewari
 - ... and 430 more: https://git.openjdk.java.net/jdk/compare/dfacda48...7e069880

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

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=01
  Stats: 97370 lines in 1522 files changed: 61891 ins; 27834 del; 7645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

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

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <lfK3BfjviJuRKG0C--gFo3MRja2_KrGtQjN4gEp4OsU=.9c421dfd-08de-40d5-8fb5-f88dcad215bb@github.com>

On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 14692d5e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14692d5ed0652b867fcf28baafa498a9441683ac
Stats:     307 lines in 32 files changed: 129 ins; 33 del; 145 mod

Merge

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

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

From serb at openjdk.java.net  Thu Aug 12 19:54:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 19:54:33 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US
Message-ID: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>

As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

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

Commit messages:
 - Initial fix of JDK-8272358

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

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

From jlahoda at openjdk.java.net  Fri Aug 13 15:26:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 Aug 2021 15:26:43 GMT
Subject: RFR: 8272135: jshell: Method cannot use its overloaded version
Message-ID: <ZsSyUI5k5vXFj6y0ZXEzc9RfhfRnoqapMK7sps_Q1Fo=.20148dc6-0f92-49a7-b9f0-78a6dabc5b81@github.com>

Consider separate snippets like:

int m(int i) { return 1; }

and:

int m(String s) { return m(0); }


If these are independent snippets, JShell will currently compile first the first snippet (say into class called `A`), and then the second snippet. The actual code for the second snippet will be in this direction:

import static A.m;
public class B {
    int m(String s) { return m(0); }
}


Note that here the method resolution, when seeing method name `m`, will not see the `m(int)` method at all, as the lookup will stop on the current class' method called `m` and will never proceed to look at the `m` method from the first snippet/class `A`.

JShell generally tries to coalescence processing of overloading methods (in the `Unit.setWrap` method), but the overloaded methods must be together part of the input, which is not the case in the above example.

The proposed solution is to detect the possibility of the above situation (call of a method that has the same name as the current snippet's method), and add all same-named overloads to the processing set.

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

Commit messages:
 - 8272135: jshell: Method cannot use its overloaded version

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

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

From vromero at openjdk.java.net  Wed Aug 18 17:36:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 18 Aug 2021 17:36:37 GMT
Subject: RFR: 8272135: jshell: Method cannot use its overloaded version
In-Reply-To: <ZsSyUI5k5vXFj6y0ZXEzc9RfhfRnoqapMK7sps_Q1Fo=.20148dc6-0f92-49a7-b9f0-78a6dabc5b81@github.com>
References: <ZsSyUI5k5vXFj6y0ZXEzc9RfhfRnoqapMK7sps_Q1Fo=.20148dc6-0f92-49a7-b9f0-78a6dabc5b81@github.com>
Message-ID: <KuMG14vRqXhX_mZysFju-eTSfHq2hz0V1y099SdFRq4=.1bca627b-4bc8-4137-9105-b50b53747124@github.com>

On Fri, 13 Aug 2021 15:20:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider separate snippets like:
> 
> int m(int i) { return 1; }
> 
> and:
> 
> int m(String s) { return m(0); }
> 
> 
> If these are independent snippets, JShell will currently compile first the first snippet (say into class called `A`), and then the second snippet. The actual code for the second snippet will be in this direction:
> 
> import static A.m;
> public class B {
>     int m(String s) { return m(0); }
> }
> 
> 
> Note that here the method resolution, when seeing method name `m`, will not see the `m(int)` method at all, as the lookup will stop on the current class' method called `m` and will never proceed to look at the `m` method from the first snippet/class `A`.
> 
> JShell generally tries to coalescence processing of overloading methods (in the `Unit.setWrap` method), but the overloaded methods must be together part of the input, which is not the case in the above example.
> 
> The proposed solution is to detect the possibility of the above situation (call of a method that has the same name as the current snippet's method), and add all same-named overloads to the processing set.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From serb at openjdk.java.net  Sun Aug 22 06:28:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 06:28:18 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
Message-ID: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>

This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

This change includes:
 * demo/utils
 * jdk.xx packages
 * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage.

Some performance discussion: https://github.com/openjdk/jdk/pull/5063

Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later).

Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

Commit messages:
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - Cleanup the UnsupportedEncodingException
 - aliases for ISO_8859_1
 - Update imageio
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/5210/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272805
  Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From weijun at openjdk.java.net  Sun Aug 22 13:22:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 22 Aug 2021 13:22:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

The security related change looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From alanb at openjdk.java.net  Sun Aug 22 15:12:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Aug 2021 15:12:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:

> 340: 
> 341:         try {
> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {

The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Aug 22 18:34:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 Aug 2021 18:34:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png)

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

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

From serb at openjdk.java.net  Sun Aug 22 23:02:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 23:02:06 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov 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 14 additional commits since the last revision:

 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644

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

  Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From naoto at openjdk.java.net  Mon Aug 23 00:26:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Aug 2021 00:26:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <YDjqMHQFk2IHLNrmd3MahBp6vvL4D3x4ncTa3PvvQWY=.39eace25-57d6-4981-a1ad-31901c061b25@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From dfuchs at openjdk.java.net  Mon Aug 23 09:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 Aug 2021 09:36:40 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <iwz79djzNlUzGYlpBbrLcycsmNcDy3bZF7qc4vozQAI=.e4aa79aa-f9cd-413a-bb5a-dc95023dc410@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644

Changes to http server look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From serb at openjdk.java.net  Mon Aug 23 19:34:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:34 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
Message-ID: <KyQxSd0IYEEoEC0acPE16G5CIvwqPTVGVZOP1M9Me8o=.f1d93383-8174-4731-8e16-ef72b415b34a@github.com>

On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.

Updated as suggested.

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

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

From serb at openjdk.java.net  Mon Aug 23 19:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
Message-ID: <aKpPQPgoXRthV1BM7HdtVLagya1bBbQnwQNj68kW_q8=.12c01c5d-b0d5-42a7-b7ce-6a03b5d05b59@github.com>

On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:
> 
>> 340: 
>> 341:         try {
>> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {
> 
> The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

Thank you for the suggestion, I have fixed this and a few other places as well.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug 23 20:54:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 Aug 2021 20:54:36 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <N67-urPlw_TC9qhch8RkndEzRrP3vUMmVDk-e_nEt-g=.b05fa6c6-04b4-449b-8f93-b00ce5f3e81e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644

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

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

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

From azvegint at openjdk.java.net  Tue Aug 24 13:09:37 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 13:09:37 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <cI5w9AqyTY2y-cy5LJA9fbGFkB2s_-hhoVOCP6w0CaE=.d56a95c4-0a92-45e2-944b-0d0e3dce165e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

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

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

From serb at openjdk.java.net  Thu Aug 26 17:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 17:42:33 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644

Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

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

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

From github.com+5709644+fdesu at openjdk.java.net  Thu Aug 26 18:33:27 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Thu, 26 Aug 2021 18:33:27 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <vjfSSXTwCTncHGyKQOw5M3cV_bCdmb89ZEFgZ8ggTkQ=.b617da20-0a0c-4b55-8011-184d1932e2aa@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

@mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are:
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
- src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java

would it make sense to go through them as well?

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

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

From serb at openjdk.java.net  Thu Aug 26 18:38:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 18:38:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <a97uQJLcPbeqHP6UVqNXMtqDq4bf4GytTvBLl4C5HPk=.3a50dcbe-d199-4df4-9af7-a94f7755bfe3@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

> @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. 
> would it make sense to go through them as well?

Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler.

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

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

From erikj at openjdk.java.net  Fri Aug 27 17:51:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 Aug 2021 17:51:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <LEmAelLl1suWas8ISeUc4p87XtgSBWwBTRPz5YSPguo=.6a717c6e-1d62-405e-9f65-2b2949f33c30@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644

Build tool change looks good.

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

Marked as reviewed by erikj (Reviewer).

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

From serb at openjdk.java.net  Mon Aug 30 23:46:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Aug 2021 23:46:15 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v3]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <TqRtp_210_WAMsWmEo00_0RH7ZdcoPgWKC0f5bt0YMQ=.a0f183a7-969d-4601-940e-d8a9558bddee@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov 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 15 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8

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

  Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From jlahoda at openjdk.java.net  Tue Aug 31 13:55:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 31 Aug 2021 13:55:43 GMT
Subject: RFR: 8271287: jdk/jshell/CommandCompletionTest.java fails with "lists
 don't have the same size expected"
Message-ID: <pxf2RaWZ2I-5JQjBbb8y4elVMzw0Eq-ip6oKUt7lnQE=.786df0c8-a8b9-479e-8acd-00c0e27243c9@github.com>

JShell has a test that verifies the file completion understands `~` is a home directory, by testing the completions after:

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

Commit messages:
 - 8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"

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

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

From serb at openjdk.java.net  Tue Aug 31 20:16:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:16:43 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <uq5KBwVStP5yT1Qu-wOx_RkCg1RTa6qMjDn2rLpwLpg=.efeffb26-2d1f-4f91-bab8-93ebd9838106@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

Any volunteers to take a look at the tests update?

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

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

From serb at openjdk.java.net  Tue Aug 31 20:17:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:17:25 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v4]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov 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 16 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e

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

  Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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