From wetmore at openjdk.org  Thu Dec  1 02:04:52 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 1 Dec 2022 02:04:52 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v3]
In-Reply-To: <gfEB05XGx6kKKorFns9AzR71Cdc1osa6GH_m8FVhQV0=.424447a3-abfa-48d8-abaf-19d97653b1b4@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
 <gfEB05XGx6kKKorFns9AzR71Cdc1osa6GH_m8FVhQV0=.424447a3-abfa-48d8-abaf-19d97653b1b4@github.com>
Message-ID: <fSX1d_0QqoUJQKUVYjaLJegU6U6LzrwUJ7EJk9srwRM=.794a852a-d97f-41c0-af9b-bc70d2c665b5@github.com>

On Tue, 22 Nov 2022 22:14:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8293412
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

Would you consider removing SHA1PRNG from sun/security/ssl/ServerHandshaker/ClassCastExceptionTest, or else file a separate bug to track (if it hasn't been done already.  This test was likely written when SHA1PRNG was the primary RNG, and thus can be updated to just use the default (i.e. NativePRNG) which won't block.

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

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

From valeriep at openjdk.org  Thu Dec  1 02:12:32 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Dec 2022 02:12:32 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
Message-ID: <9OMgPh5hlFAGvMIHS8_sI4hH4xL_0p8chksfWqnM3NY=.414ac124-6224-488a-ba15-ed45f4e8470f@github.com>

On Mon, 21 Nov 2022 18:20:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment cleanup & finesse ByteBuffer implGCMCrypt better

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 778:

> 776:                             gctr, ghash);
> 777:                     } else {
> 778:                         int ofs = src.arrayOffset() + src.position();

Isn't this also used on line 774? Why not move this up and directly refer to it for both places?

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

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

From valeriep at openjdk.org  Thu Dec  1 03:25:18 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Dec 2022 03:25:18 GMT
Subject: RFR: 8297505: Declare fields in some sun.security.pkcs11 classes
 as final
In-Reply-To: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
References: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
Message-ID: <e-9tyZSQ6_6Xoo8yfs9FGHfkpvM_NsKRhf4SYNVVIpI=.aba968ba-1d8d-4255-a387-f05ecced4e33@github.com>

On Thu, 24 Nov 2022 08:13:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring some fields as `final` to potentially unlock performance optimisations and improve thread visibility (e.g. for GC threads). The PR also fixes a "synchronising on a non-final field" anti-pattern.

Looks fine. Have you run all the security regression tests? Or do you need me to run them?

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

Marked as reviewed by valeriep (Reviewer).

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

From ascarpino at openjdk.org  Thu Dec  1 04:14:24 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 1 Dec 2022 04:14:24 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <9OMgPh5hlFAGvMIHS8_sI4hH4xL_0p8chksfWqnM3NY=.414ac124-6224-488a-ba15-ed45f4e8470f@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
 <9OMgPh5hlFAGvMIHS8_sI4hH4xL_0p8chksfWqnM3NY=.414ac124-6224-488a-ba15-ed45f4e8470f@github.com>
Message-ID: <tkpht-XdxW7Qx-SvYGM6W5R4diu2Mpwg9kcoP4qmJ6o=.db0c502b-2765-45a4-98d2-9fc19405cfad@github.com>

On Thu, 1 Dec 2022 02:10:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment cleanup & finesse ByteBuffer implGCMCrypt better
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 778:
> 
>> 776:                             gctr, ghash);
>> 777:                     } else {
>> 778:                         int ofs = src.arrayOffset() + src.position();
> 
> Isn't this also used on line 774? Why not move this up and directly refer to it for both places?

The line 774 case only uses the calculated value once.  I'm avoiding the unnecessary store & load operations when it is set the value to a variable. I see it when I run  javap -c to view the bytecode.  It's purely an optimization for performance.   I do set it to the variable in the line 778 case because calculating the value twice is probably more expensive than once with the store & load operations.

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

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

From ascarpino at openjdk.org  Thu Dec  1 04:19:37 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 1 Dec 2022 04:19:37 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v3]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <ixsfgj-usc-4OysVXwpr6PgNRxCp_kVux-05HBy9on0=.8e56f1e8-9907-4d6e-8828-19e4ded9d1b8@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11121/files
  - new: https://git.openjdk.org/jdk/pull/11121/files/f595dc24..340ab22f

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

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

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

From jlaskey at openjdk.org  Thu Dec  1 13:18:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Dec 2022 13:18:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <xhPzR2HTM7U0UEhvRxjpaE0ff169w3tCBX0yCpLOoY4=.be878d0b-bfc3-4d4c-a9d5-37369616e413@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

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

From alanb at openjdk.org  Thu Dec  1 15:11:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:11:23 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <Scdy9u1XjWQU5gWdMdr_25uiTCXFpTSToGd46dM8frw=.acb5fc20-e233-436e-a39b-c94836bbeb7c@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/io/Console.java line 604:

> 602:                             GetPropertyAction.privilegedGetProperty("jdk.console",
> 603:                                     JdkConsoleProvider.DEFAULT_PROVIDER);
> 604:                     cons = ServiceLoader.load(JdkConsoleProvider.class).stream()

We might need a test to verify that this works when running with a security manager? That execution mode is still supported.

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

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

From alanb at openjdk.org  Thu Dec  1 15:18:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:18:39 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/lang/System.java line 2133:

> 2131:     }
> 2132: 
> 2133:     private static InputStream initIn = null;

I think it would be helpful to rename this to `initialIn` and move this to be with `in` and `out`. It might also be helpful to have a  comment to say that it's the initial value of `in`, set in initPhase1.  It doesn't need to be initialized to null as that it's default value anyway.

src/java.base/share/classes/sun/security/util/Password.java line 63:

> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
> 62:                 // to be compatible with old Password class, change to null
> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {

@wangweij Would you have cycles to build with this change to see that keytool is okay?

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

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

From alanb at openjdk.org  Thu Dec  1 15:35:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:35:34 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <R4aKXarc67PDUTPbROJ23XQVirwJEVTMRkBIdSGGTtY=.ee02bf33-a445-44aa-a9f9-5e65284506ab@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

A general point is that it's difficult to test Console and it looks like we don't have many existing tests in test/jdk/java/io/Console. The test that is there doesn't seem to exercise most of the methods. I wonder should improve this and have the tests run with `--limit-modules java.base` so they run with the default the is in java.base rather than the provider in jdk.intenal.le.

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

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

From weijun at openjdk.org  Thu Dec  1 15:53:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 15:53:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
Message-ID: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>

On Thu, 1 Dec 2022 15:16:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adds a test
>>  - Removed JavaIOAccess.charset() which is no longer needed
>
> src/java.base/share/classes/sun/security/util/Password.java line 63:
> 
>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>> 62:                 // to be compatible with old Password class, change to null
>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
> 
> @wangweij Would you have cycles to build with this change to see that keytool is okay?

Sure. Trying out now...

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

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

From weijun at openjdk.org  Thu Dec  1 16:11:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 16:11:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
Message-ID: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>

On Thu, 1 Dec 2022 15:49:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Password.java line 63:
>> 
>>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>>> 62:                 // to be compatible with old Password class, change to null
>>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
>> 
>> @wangweij Would you have cycles to build with this change to see that keytool is okay?
>
> Sure. Trying out now...

I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.

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

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

From djelinski at openjdk.org  Thu Dec  1 16:57:51 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Dec 2022 16:57:51 GMT
Subject: RFR: 8267617: Certificate's IP x509 NameConstraints raises
 ArrayIndexOutOfBoundsException
Message-ID: <Xib64SYD-Ke0N-4JSQyt9VsSRS_ltrrU_KeBIDWmBQk=.9582ab29-8124-48b9-a64a-0f08e94af2e8@github.com>

This patch fixes the exceptions that may occur when merging IP address NameConstraints from different certificates in a chain.

The included test reports 3 exceptions without the fix, passes with the fix applied.

Tiers 1-3 continue to pass.

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

Commit messages:
 - Add test
 - Fix name constraint comparison

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

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

From duke at openjdk.org  Thu Dec  1 16:59:12 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 16:59:12 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v2]
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <H3KQT8LukCAhYi8u3c156ipmGz0Vaz02KBOOjXnfOL8=.205762d7-0748-4bf6-9781-0ff3451ee5bc@github.com>

> Regarding mainline:
> - I decided not to 'unroll' the top while loop (i.e. `engineUpdate(byte[] input, int offset, int len)` is unrolled)
>    - It is debatable which version is easier to understand. If this version is 'too complex', I can unroll the top while loop. 
> - I do think this version is incremental (i.e. easier to review?):
>    - Move `remaining -= bytesToWrite;` into each `if` branch
>    - Change first `if` case to process multiple blocks instead of one
> 
> This `while` loop has a lot of cases to remember; Very roughly:
> 
> 1. process from previous call
> 2. process current data
> 3. store overflow
> 
> Interesting situations:
> - `blockOffset` might be non-`0`
> - `remaining+blockOffset` might not be enough to fill a single block. Or just enough for one block and to leave an overflow again..
> - etc.
> 
> Regarding testing
> - Correctness of intrinsic was already tested in https://github.com/openjdk/jdk/pull/10582 so not adding any tests there (i.e. no KAT)
> - In principle, fuzz test should also be sufficient to test bytebuffer (did increase repetitions)

Volodymyr Paprotski 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 four additional commits since the last revision:

 - bench and handle buf.position()
 - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
 - whitespace
 - ByteBuffer support and tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11338/files
  - new: https://git.openjdk.org/jdk/pull/11338/files/b31d7902..e307e344

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

  Stats: 13608 lines in 487 files changed: 8557 ins; 2924 del; 2127 mod
  Patch: https://git.openjdk.org/jdk/pull/11338.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11338/head:pull/11338

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

From weijun at openjdk.org  Thu Dec  1 17:56:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 17:56:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
Message-ID: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>

On Thu, 1 Dec 2022 16:08:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sure. Trying out now...
>
> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
> 
> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
> |  Welcome to JShell -- Version 20-internal
> |  For an introduction type: /help intro
> 
> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
> Enter keystore password:  changeit
> Re-enter new password: changeit
> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
> 	for: CN=A

What's the expected behavior?

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

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

From duke at openjdk.org  Thu Dec  1 18:23:45 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 18:23:45 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>

> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
> 
> Fuzzing test expanded to also include ByteBuffer payloads.
> 
> Performance is now matched:
> 
> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  remove comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11338/files
  - new: https://git.openjdk.org/jdk/pull/11338/files/e307e344..14726d7b

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

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

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

From duke at openjdk.org  Thu Dec  1 18:36:42 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 18:36:42 GMT
Subject: RFR: 8297972: Poly1305 Endianness on ByteBuffer not enforced
Message-ID: <d5Eh66F_jaKsA7WCj4Gjdu1iND8Inz6Z-kBVwHzCF7s=.b5da3bb1-dae7-4ff2-b711-b405b008ca29@github.com>

Per rfc7539 Section 2.5, "Read the block as a little-endian number."

sun.security.util.math.intpoly.IntegerPolynomial1305 enforces this on input when input is provided as `[]byte` but not when input is in `ByteBuffer`

Tested with `Poly1305IntrinsicFuzzTest.java` from https://github.com/openjdk/jdk/pull/11338 which compares Poly1305 MAC between `ByteBuffer` and `[]byte`

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

Commit messages:
 - enforce reading input as little_endian numbers

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

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

From duke at openjdk.org  Thu Dec  1 18:48:19 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 18:48:19 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <e0ydkQxEpSfM0lVVgUjPrYI6LK1zpRqtam4thCSd7qA=.75c4b408-ff9a-42e1-9713-a7a7b331d48d@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <e0ydkQxEpSfM0lVVgUjPrYI6LK1zpRqtam4thCSd7qA=.75c4b408-ff9a-42e1-9713-a7a7b331d48d@github.com>
Message-ID: <Zx8k_FL8bhDkgjvVwAnkkp0Hwru1Hrg_pcTDg7qiuJQ=.700a01ef-abf0-43e5-97df-ed99b224f09a@github.com>

On Tue, 29 Nov 2022 01:16:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove comment
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 260:
> 
>> 258:         if (buf.hasArray()) {
>> 259:             byte[] input = buf.array();
>> 260:             int offset = buf.arrayOffset();
> 
> arrayOffset returns the offset of the first element of the backing buffer. Need to also take into account the position() of the buffer here. We should also add test case for this.

Thanks for catching this!! Fixed the mainline to handle position(). I have now reworked the test case quite a bit.

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

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

From duke at openjdk.org  Thu Dec  1 18:48:21 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 18:48:21 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <EieNIEXEMM5bEPzYTrUh2qpN7ntMXKsTZiEqcfCe9rE=.497404e9-6ed9-439d-abdc-d5d4fb9790f3@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <EieNIEXEMM5bEPzYTrUh2qpN7ntMXKsTZiEqcfCe9rE=.497404e9-6ed9-439d-abdc-d5d4fb9790f3@github.com>
Message-ID: <jmWKqnzk2K_-LZaw5DtMHwoJnc1tKb7kLLNr3s15Zsk=.75030819-8ed0-45e1-a84a-3c027a6f1bdc@github.com>

On Thu, 24 Nov 2022 18:42:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove comment
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 268:
> 
>> 266:         } else {
>> 267:             while (blockMultipleLength > 0) {
>> 268:                 processBlock(buf, BLOCK_LENGTH);
> 
> For native byte buffers, you can pass the buffer address and base.

Spent some time thinking about this one.. Originally, (from the sample you shared) I thought I had to use `Unsafe`, which I don't think is 'safe' to do in a crypto library. After some searching, I found a 'safe' alternative, `sun.nio.ch.DirectBuffer` interface, which would give me the `long address()`.

The problem is that the current java signature for the intrinsic expects a `[]byte` not a long. I could certainly change the existing intrinsic (or more likely add a new instrinsic calling existing stub assembly).

I would lean towards not supporting Direct Byte buffers right now. (Also, it doesn't seem like other crypto intrinsics do either. At least GCM does not..)

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

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

From duke at openjdk.org  Thu Dec  1 18:48:23 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 1 Dec 2022 18:48:23 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <jmWKqnzk2K_-LZaw5DtMHwoJnc1tKb7kLLNr3s15Zsk=.75030819-8ed0-45e1-a84a-3c027a6f1bdc@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <EieNIEXEMM5bEPzYTrUh2qpN7ntMXKsTZiEqcfCe9rE=.497404e9-6ed9-439d-abdc-d5d4fb9790f3@github.com>
 <jmWKqnzk2K_-LZaw5DtMHwoJnc1tKb7kLLNr3s15Zsk=.75030819-8ed0-45e1-a84a-3c027a6f1bdc@github.com>
Message-ID: <57uXegsH8-YhAbjevV0HlBaA2nanNmcC9rQZYSGDwto=.cc8753e6-b1b8-4659-9e8b-84fed35a02fb@github.com>

On Thu, 1 Dec 2022 18:41:42 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 268:
>> 
>>> 266:         } else {
>>> 267:             while (blockMultipleLength > 0) {
>>> 268:                 processBlock(buf, BLOCK_LENGTH);
>> 
>> For native byte buffers, you can pass the buffer address and base.
>
> Spent some time thinking about this one.. Originally, (from the sample you shared) I thought I had to use `Unsafe`, which I don't think is 'safe' to do in a crypto library. After some searching, I found a 'safe' alternative, `sun.nio.ch.DirectBuffer` interface, which would give me the `long address()`.
> 
> The problem is that the current java signature for the intrinsic expects a `[]byte` not a long. I could certainly change the existing intrinsic (or more likely add a new instrinsic calling existing stub assembly).
> 
> I would lean towards not supporting Direct Byte buffers right now. (Also, it doesn't seem like other crypto intrinsics do either. At least GCM does not..)

JMH also added (and main PR comment modified to match)

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

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

From jnimeh at openjdk.org  Thu Dec  1 19:11:24 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 1 Dec 2022 19:11:24 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v3]
In-Reply-To: <ixsfgj-usc-4OysVXwpr6PgNRxCp_kVux-05HBy9on0=.8e56f1e8-9907-4d6e-8828-19e4ded9d1b8@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ixsfgj-usc-4OysVXwpr6PgNRxCp_kVux-05HBy9on0=.8e56f1e8-9907-4d6e-8828-19e4ded9d1b8@github.com>
Message-ID: <DIRCo5bNTuubivGAaX-l6xQQ8HIDKURGgTDzke3xTz4=.f2616e9a-e33d-4e27-b735-60c0a79aa6a0@github.com>

On Thu, 1 Dec 2022 04:19:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment update

This looks good, I only have nit comments.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 580:

> 578:      * an upper limit on the number of blocks encrypted in the intrinsic.
> 579:      *
> 580:      * For decrypting in-place byte[], calling methods must ct must set to null

Typo nit?  Should it be "calling methods must set ct to null"

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1642:

> 1640:                 // Clear output data
> 1641:                 dst.reset();
> 1642:                 // If this is no an in-place array, zero the dst buffer

nit: no -> not

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

Marked as reviewed by jnimeh (Reviewer).

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

From naoto at openjdk.org  Thu Dec  1 19:34:35 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 19:34:35 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
Message-ID: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>

On Thu, 1 Dec 2022 17:53:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
>> 
>> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
>> |  Welcome to JShell -- Version 20-internal
>> |  For an introduction type: /help intro
>> 
>> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
>> Enter keystore password:  changeit
>> Re-enter new password: changeit
>> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
>> 	for: CN=A
>
> What's the expected behavior?

I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

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

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

From jjg at openjdk.org  Thu Dec  1 19:36:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:36:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Jonathan Gibbons 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 five additional commits since the last revision:

 - Change ietf.org URLs to use rfc-editor.org
 - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
 - Remove updates from unexported files
 - Prefix RFC titles with `RFC NNNN:`
 - JDK-8296547: Add @spec tags to API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc

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

  Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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

From jjg at openjdk.org  Thu Dec  1 19:40:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
Message-ID: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>

On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jonathan Gibbons 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 five additional commits since the last revision:
>> 
>>  - Change ietf.org URLs to use rfc-editor.org
>>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>>  - Remove updates from unexported files
>>  - Prefix RFC titles with `RFC NNNN:`
>>  - JDK-8296547: Add @spec tags to API
>
> src/java.base/share/classes/java/lang/Character.java line 172:
> 
>> 170:  * occur. For example, in a future release, synchronization may fail.
>> 171:  *
>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
> 
> This should probably be removed, as the original link (explaining `U+n` notation) is broken.

@naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

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

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

From jjg at openjdk.org  Thu Dec  1 19:57:33 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:57:33 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
Message-ID: <XVUIV3LMzWV4Y-0veldczkRr4bD_X-2JxbRLJRDikeI=.36f81c4a-f467-4352-90ba-cc3fc656791f@github.com>

On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:
> 
>> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
>> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
>> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition
> 
> Hi Jon,
> 
> I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
> points to the fifth edition while @see second.
> 
> A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.
> 
> [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work.   The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list.

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

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

From valeriep at openjdk.org  Thu Dec  1 20:53:01 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Dec 2022 20:53:01 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v2]
In-Reply-To: <tkpht-XdxW7Qx-SvYGM6W5R4diu2Mpwg9kcoP4qmJ6o=.db0c502b-2765-45a4-98d2-9fc19405cfad@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ou7e_ZdGVZUQXF_fZIUX-ssabz-9ggfd0dVPRchNUdo=.e36b0b9f-abed-4c1e-abc2-1c8eec14981f@github.com>
 <9OMgPh5hlFAGvMIHS8_sI4hH4xL_0p8chksfWqnM3NY=.414ac124-6224-488a-ba15-ed45f4e8470f@github.com>
 <tkpht-XdxW7Qx-SvYGM6W5R4diu2Mpwg9kcoP4qmJ6o=.db0c502b-2765-45a4-98d2-9fc19405cfad@github.com>
Message-ID: <h09NZ0ZRqEhcmoHa-YEiXMVVARF1-cf-PhsFZxkwZQ0=.841b476b-a4a1-4ab0-be55-4919eb0c2656@github.com>

On Thu, 1 Dec 2022 04:10:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 778:
>> 
>>> 776:                             gctr, ghash);
>>> 777:                     } else {
>>> 778:                         int ofs = src.arrayOffset() + src.position();
>> 
>> Isn't this also used on line 774? Why not move this up and directly refer to it for both places?
>
> The line 774 case only uses the calculated value once.  I'm avoiding the unnecessary store & load operations when it is set the value to a variable. I see it when I run  javap -c to view the bytecode.  It's purely an optimization for performance.   I do set it to the variable in the line 778 case because calculating the value twice is probably more expensive than once with the store & load operations.

I see.

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

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

From naoto at openjdk.org  Thu Dec  1 21:23:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 21:23:09 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
 <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
Message-ID: <NzMOOFfncZ1U5XWrfhkWjwcvhKxiand9c5VfptjGehM=.9d78d127-3374-4c48-8a7d-614b64fcdb0a@github.com>

On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 172:
>> 
>>> 170:  * occur. For example, in a future release, synchronization may fail.
>>> 171:  *
>>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
>> 
>> This should probably be removed, as the original link (explaining `U+n` notation) is broken.
>
> @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

Either way is fine with me. I will fix it up if you choose the latter.

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

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

From sviswanathan at openjdk.org  Thu Dec  1 23:06:26 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 1 Dec 2022 23:06:26 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
Message-ID: <LV_ilAVlZXaS3JzIrh23HANrSNXae2iTyK3PodrvzpI=.5d25bb6e-7709-4221-9f4e-a2d84ce3e6ad@github.com>

On Thu, 1 Dec 2022 18:23:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

Marked as reviewed by sviswanathan (Reviewer).

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

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

From sviswanathan at openjdk.org  Thu Dec  1 23:30:34 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 1 Dec 2022 23:30:34 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
Message-ID: <2KZnRjiOZO1KgrCBw_x8RI1aCRIKMH6uG51CmvWM4dk=.81ca191d-f3a9-4dc0-9d39-be1262d49ac6@github.com>

On Thu, 1 Dec 2022 18:23:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

The PR looks good to me.
@ascarpino Could you please help review this?

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

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

From weijun at openjdk.org  Thu Dec  1 23:41:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 23:41:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
Message-ID: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>

On Thu, 1 Dec 2022 19:30:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> What's the expected behavior?
>
> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

If the console cannot be used anyway inside jshell, then this is good enough.

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

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

From valeriep at openjdk.org  Thu Dec  1 23:48:51 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Dec 2022 23:48:51 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v3]
In-Reply-To: <ixsfgj-usc-4OysVXwpr6PgNRxCp_kVux-05HBy9on0=.8e56f1e8-9907-4d6e-8828-19e4ded9d1b8@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <ixsfgj-usc-4OysVXwpr6PgNRxCp_kVux-05HBy9on0=.8e56f1e8-9907-4d6e-8828-19e4ded9d1b8@github.com>
Message-ID: <KjLWiQh4VIbwolvGxQ7iGF-Kuj6DRnqHGt4a-XCuNfY=.003aded3-f4e6-4f03-b5e6-75ec15445835@github.com>

On Thu, 1 Dec 2022 04:19:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment update

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1053:

> 1051:                     return new byte[out.length];
> 1052:                 }
> 1053:                 inPlaceArray = (!encryption);

Is the "inPlaceArray" reset somewhere? When inOfs >= outOfs and the function will return on line 1051, the inPlaceArray value will not be set on line 1053. Is this intentional? My vacation is coming up and I can't finish off this review before I leave. I see that Jamil has approved it. No need to hold up this for me. Thanks.

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

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

From alanb at openjdk.org  Fri Dec  2 08:21:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Dec 2022 08:21:05 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
Message-ID: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>

On Thu, 1 Dec 2022 23:38:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.
>
> If the console cannot be used anyway inside jshell, then this is good enough.

Naoto has confirmed that the password prompt from keytool does not echo, good!

The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

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

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

From dfuchs at openjdk.org  Fri Dec  2 12:15:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 12:15:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com>

On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons 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 five additional commits since the last revision:
> 
>  - Change ietf.org URLs to use rfc-editor.org
>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>  - Remove updates from unexported files
>  - Prefix RFC titles with `RFC NNNN:`
>  - JDK-8296547: Add @spec tags to API

I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 62:

> 60:      * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams
> 61:      * @see <a href="http://www.ietf.org/rfc/rfc919.txt">RFC&nbsp;929:
> 62:      * Broadcasting Internet Datagrams</a>

This `@see` line should now be removed since it's referencing the exact same document.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 83:

> 81:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 82:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122
> 83:      * Requirements for Internet Hosts -- Communication Layers</a>

Same remark here: please remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 154:

> 152:      * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance
> 153:      * @see <a href="http://www.ietf.org/rfc/rfc1323.txt">RFC&nbsp;1323: TCP
> 154:      * Extensions for High Performance</a>

Remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 186:

> 184:      *
> 185:      * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol
> 186:      * @see <a href="http://www.ietf.org/rfc/rfc793.txt">RFC&nbsp;793: Transmission

Remove the @see

src/java.base/share/classes/java/net/StandardSocketOptions.java line 377:

> 375:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 376:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122:
> 377:      * Requirements for Internet Hosts -- Communication Layers</a>

Remove the @see

src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122:

> 120:  * @see <a
> 121:  * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609,
> 122:  * "Service Templates and <code>Service:</code> Schemes"</a>

The two `@see` should now be removed

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

Changes requested by dfuchs (Reviewer).

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

From weijun at openjdk.org  Fri Dec  2 15:18:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 15:18:39 GMT
Subject: Withdrawn: 5066842: PKCS8EncodedKeySpec needs getAlgorithm method
In-Reply-To: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
References: <tx3mKOJ7cizV3JTvahc7CHXlp7bKmM59hmEyPnnaUAE=.d92c285d-72b3-48ff-8fc8-72d338fcfcf7@github.com>
Message-ID: <iMXv1jRlmT_O_KwQkkUviulOaOyxSLit7IGlWnup8Lg=.243e881f-e1ee-4e97-8f72-0878100f85b4@github.com>

On Thu, 1 Sep 2022 23:25:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Since the algorithm is already encoded inside a PKCS #8 data block, it is not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is created. The same for `X509EncodedKeySpec`.

This pull request has been closed without being integrated.

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

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

From weijun at openjdk.org  Fri Dec  2 15:23:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 15:23:51 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
Message-ID: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>

On Fri, 2 Dec 2022 08:18:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If the console cannot be used anyway inside jshell, then this is good enough.
>
> Naoto has confirmed that the password prompt from keytool does not echo, good!
> 
> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

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

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

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
Message-ID: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

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

Commit messages:
 - 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code

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

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

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <fFxu85P9b4eRFBowNuiSYQdyCA9OJvRPVPm5C_mqB70=.2b7eac64-ec95-49df-b3fd-cebcb18e674b@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

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

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

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

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties
 files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

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

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

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

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

From weijun at openjdk.org  Fri Dec  2 18:51:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 18:51:07 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <xp58-oyXNmSSI1GSAZfCbYGVMUMRACd1cfBV8gUqwug=.757bf432-e9c8-4a80-abe9-d9f94cd45a12@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

Useless space. Should remove.

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

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

From naoto at openjdk.org  Fri Dec  2 21:55:24 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 21:55:24 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v3]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <HM5Wmd_ENr7tE83zt4n2wIIdfaD4OIapOcA5VfsYE1E=.55aff254-32c6-4771-9b5e-daedb07af297@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Added more tests, loading with doPrivileged()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/3d2b01f6..4c38b01b

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

  Stats: 137 lines in 5 files changed: 121 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Fri Dec  2 22:03:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 22:03:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
 <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
Message-ID: <sLn0o9FkgSCSAKP-FGJCFYrPXh8soGDTi8I-1jktmzU=.02e644b1-48a6-41c2-b488-8b9ad7deeb17@github.com>

On Fri, 2 Dec 2022 15:21:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Naoto has confirmed that the password prompt from keytool does not echo, good!
>> 
>> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.
>
> Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

I thought that in `jshell`, `System.console()` returns null, so it is always not using `Console.readPassword`. Anyway, I think the scenario is not practical (changing password using jshell), and in the future, jshell can provide its own Console implementation (that's a part of this enhancement's motivation) that would nicely handle this situation.

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

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

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

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

From valeriep at openjdk.org  Sat Dec  3 00:49:11 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 3 Dec 2022 00:49:11 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v2]
In-Reply-To: <HitlCYT_gi_ETSUdU62Lh2QYCLD7OEmVx1BvB03u98A=.01face4b-154d-4b93-b32b-44a6f15b758b@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <0YWxXMEUahIvl2temsbPBkP913bSUZy97_ICojoFTzY=.cccce54b-b1fb-4b13-b338-cf594207406a@github.com>
 <HitlCYT_gi_ETSUdU62Lh2QYCLD7OEmVx1BvB03u98A=.01face4b-154d-4b93-b32b-44a6f15b758b@github.com>
Message-ID: <JLAwPTigLqt8nTIdcGr4_Auk12fgMTbf43nBz5YbLTE=.192b8972-50b9-4d98-9496-e427c06724ac@github.com>

On Mon, 28 Nov 2022 20:09:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove extra whitespace
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 325:
> 
>> 323:          * index 2: padding component (e.g., PKCS5Padding)
>> 324:          */
>> 325:         String[] parts = { "", "", "" };
> 
> 1. Do you want to add a test for the `PBEWithHmacSHA512/256AndAES_128/CBC/PKCS5Padding` cipher transformation?
> 2. Is `transformation` case-sensitive? `transformation.indexOf(SHA512TRUNCATED)` might not be able to detect "sha512/2".

Yes, good catch. I added the additional algorithm to the existing PBES2Test and also updated the indexOf(...) call with additional toUpperCase(...) call.

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

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

From valeriep at openjdk.org  Sat Dec  3 00:53:28 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 3 Dec 2022 00:53:28 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v3]
In-Reply-To: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
Message-ID: <oUSuwahIYgm1F39BGLh_L3FP0jH95sgKVVckjR40VHw=.c58e77fa-327d-46c9-a794-245e21cbaab7@github.com>

> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  handle the "SHA512/2" lookup of the cipher transformation in a case-insensitive way.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11339/files
  - new: https://git.openjdk.org/jdk/pull/11339/files/3bb914b1..2bf57b16

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

  Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11339.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11339/head:pull/11339

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

From xuelei at openjdk.org  Sat Dec  3 06:02:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 3 Dec 2022 06:02:15 GMT
Subject: RFR: 8294248: Use less limbs for P256 in EC implementation [v4]
In-Reply-To: <yu2gHhbx9MF0KL9wefAB15gxiIYUXEKG_6uxGYpDb3c=.b83c8ff6-16f9-4b69-9c42-f8e658373a89@github.com>
References: <QND0bwwPfCwWRvI5YWjhqLk-ZtlHm3hT-9AnpkvgAD8=.31a8920b-2809-45b2-87c4-4515a50a4ee8@github.com>
 <0pXx3wYDSwt27ueLb9BN3lsnPoCJHZc2HJQns4z7YJI=.71858b34-e421-4bf3-8992-e74bb4ae6c7c@github.com>
 <_TUofu2fuJKrPmUfetQA2E-jmE95GaWoVaCzeET-O1g=.b7788425-5af3-436b-8094-117a431c9bbf@github.com>
 <yu2gHhbx9MF0KL9wefAB15gxiIYUXEKG_6uxGYpDb3c=.b83c8ff6-16f9-4b69-9c42-f8e658373a89@github.com>
Message-ID: <uOGq7CgLMrstWIBOmfcCb7OSIM0HsOAaZw1fiOdmvoo=.6b8be981-0be4-4450-871c-fb91dbf351ee@github.com>

On Wed, 30 Nov 2022 19:44:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Please add a test that verifies that the worst case calculation still produces correct results. That is:
> > 
> > * build a number where the limb values are as high as possible (2^(numLimbs*bitsPerLimb)-1, or something close)
> > * sum that number with itself until numAdds = maxAdds
> > * square the result
> > * compare the result with the same calculations on BigInteger
> 
> It makes senses to me. I would like to have an improvement in FieldGen.java instead, so that no illegal params could be set. Let's see if I could make it before integration of this patch.

The FieldGen.java improvement is not a small patch.  It's on my plan, but it may be not something right for JDK 20 as the deadline is approaching.  I will see if it is possible for JDK 21.  Close this PR for now.  I will open it again if the FieldGen.java get improved.  @djelinski Thank you for your time and extremely helpful feedback.

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

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

From weijun at openjdk.org  Sat Dec  3 15:40:15 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 3 Dec 2022 15:40:15 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v3]
In-Reply-To: <oUSuwahIYgm1F39BGLh_L3FP0jH95sgKVVckjR40VHw=.c58e77fa-327d-46c9-a794-245e21cbaab7@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <oUSuwahIYgm1F39BGLh_L3FP0jH95sgKVVckjR40VHw=.c58e77fa-327d-46c9-a794-245e21cbaab7@github.com>
Message-ID: <YXtyf8DRHbvCYYoqJbo6UtNRbeZ32uxKrzsx7QMdtrA=.609b27da-4bed-4d79-a0b0-eb1b9da54afd@github.com>

On Sat, 3 Dec 2022 00:53:28 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle the "SHA512/2" lookup of the cipher transformation in a case-insensitive way.

LGTM. Only 2 tiny style-related comments.

src/java.base/share/classes/javax/crypto/Cipher.java line 331:

> 329:         int sha512Idx = transformation.toUpperCase(Locale.ENGLISH).indexOf
> 330:                 (SHA512TRUNCATED);
> 331:         int startIdx = (sha512Idx == -1? 0 :

1. Line 329: break the line before ".".
2. Line 331: add a space before "?".

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

Marked as reviewed by weijun (Reviewer).

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

From naoto at openjdk.org  Sat Dec  3 19:18:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 3 Dec 2022 19:18:48 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Changed the expected behavior when the SecurityManager is enabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/4c38b01b..7c0740aa

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

  Stats: 28 lines in 3 files changed: 5 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From aturbanov at openjdk.org  Sun Dec  4 12:10:13 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 4 Dec 2022 12:10:13 GMT
Subject: Integrated: 8297683: Use enhanced-for cycle instead of Enumeration in
 java.security.jgss
In-Reply-To: <pyQf2FNDpgDmd9iLBWkhsWu3eN3t8Nf8WJl9Ny-yHsw=.8cbc9c2b-f155-4068-bd29-3eaf24122302@github.com>
References: <pyQf2FNDpgDmd9iLBWkhsWu3eN3t8Nf8WJl9Ny-yHsw=.8cbc9c2b-f155-4068-bd29-3eaf24122302@github.com>
Message-ID: <bFb8C9oJnTWMs5q6AJ0hKlCgowL3r0hIkiA3OK_b1Pc=.7f8cc86e-d223-4d41-a8f9-4da0239c6a58@github.com>

On Sun, 27 Nov 2022 13:21:25 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
> 
> sun.security.jgss.ProviderList#addAllMechsFromProvider
> sun.security.jgss.GSSCredentialImpl#dispose
> sun.security.jgss.GSSCredentialImpl#getRemainingLifetime
> sun.security.jgss.GSSCredentialImpl#getUsage()
> sun.security.jgss.GSSCredentialImpl#getElements

This pull request has now been integrated.

Changeset: 0edb5d08
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0edb5d08055d8c06ed318a6c32e44a070ab4d002
Stats:     31 lines in 2 files changed: 0 ins; 23 del; 8 mod

8297683: Use enhanced-for cycle instead of Enumeration in java.security.jgss

Reviewed-by: weijun

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

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

From alanb at openjdk.org  Sun Dec  4 17:17:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Dec 2022 17:17:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

This is well done. I've been through all the latest src changes.

src/java.base/share/classes/java/io/Console.java line 627:

> 625:         });
> 626:     }
> 627:     private static Console cons;

The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 33:

> 31: /**
> 32:  * Delegate interface for custom Console implementations.
> 33:  * Methods defined here are duplicating ones in Console class.

There's a typo here, probably should be be "duplicates the" or "are duplicates of the methods".

src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java line 40:

> 38:      * The default provider of JdkConsole.
> 39:      */
> 40:     String DEFAULT_PROVIDER = "jdk.internal.le";

This is really the module name of the preferred provider, maybe it should have _MODULE_NAME as the suffix.

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

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

From duke at openjdk.org  Mon Dec  5 07:01:59 2022
From: duke at openjdk.org (yansendao)
Date: Mon, 5 Dec 2022 07:01:59 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout [v2]
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <Pmi4sAl_npmVK5GT4PTOFekryR5r7w1uqbi0XuCSrcQ=.4607c151-706e-4b99-a249-ffd7670c3c4d@github.com>

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

yansendao 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into jbs8296384
 - 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11014/files
  - new: https://git.openjdk.org/jdk/pull/11014/files/b89f5bb3..ee62b7d1

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

  Stats: 96642 lines in 1874 files changed: 39781 ins; 39482 del; 17379 mod
  Patch: https://git.openjdk.org/jdk/pull/11014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11014/head:pull/11014

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

From duke at openjdk.org  Mon Dec  5 07:05:03 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:05:03 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <p7O7axVhjrW0uR55B1J3EgTaorzOkz7lU9wVQelsgbg=.5b4102ac-af17-4c53-98f9-c90081087bdf@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties line 281:

> 279: # Namespaces support
> 280: # 4. Using Qualified Names
> 281:         IllegalQName = L'\u00E9l\u00E9ment ou l'attribut ne correspond pas \u00E0 la production QName : QName::=(NCName':')?NCName.\u0020

XMLMessages.properties does not have a trailing space for IllegalQName. For consistency with the original, there should probably be no space (unless the original is incorrect).

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

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

From duke at openjdk.org  Mon Dec  5 07:06:23 2022
From: duke at openjdk.org (yansendao)
Date: Mon, 5 Dec 2022 07:06:23 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout [v3]
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <bmxiVttN-R1DBknFSsb0KhZtC18ywdl9qMrxcFKml0o=.d1adf958-541e-48f1-aaf6-c2c405982f17@github.com>

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

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

 - Merge branch 'jbs8296384' of github.com:sendaoYan/jdk-ysd into jbs8296384
 - Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11014/files
  - new: https://git.openjdk.org/jdk/pull/11014/files/ee62b7d1..304e98b3

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

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

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

From aturbanov at openjdk.org  Mon Dec  5 07:08:38 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:08:38 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <dt5iQtdPZY3ZYgGq9Ol237Cp3z9DR5M6k_p1XsDHXh4=.bf2a1103-c8e8-4f7c-9b54-fcc908ece4f1@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

src/java.base/share/classes/java/io/ProxyingConsole.java line 62:

> 60:      */
> 61:     @Override
> 62:     public Console format(String fmt, Object ...args) {

Suggestion:

    public Console format(String fmt, Object ... args) {

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 40:

> 38:     PrintWriter writer();
> 39:     Reader reader();
> 40:     JdkConsole format(String fmt, Object ...args);

nit
Suggestion:

    JdkConsole format(String fmt, Object ... args);

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 67:

> 65:         }
> 66: 
> 67:         public synchronized JdkConsole format(String fmt, Object ...args) {

Nit:
Suggestion:

        public synchronized JdkConsole format(String fmt, Object ... args) {

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

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

From duke at openjdk.org  Mon Dec  5 07:31:46 2022
From: duke at openjdk.org (yansendao)
Date: Mon, 5 Dec 2022 07:31:46 GMT
Subject: RFR: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout [v4]
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <jS2QryPw8LPwVU2oKd8Yyji2o7QXOyygAYFwzl3iwm0=.7763a58e-0deb-49e5-9bb4-966ead0adaf4@github.com>

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

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

  change copyright 2016 to 2016, 2022

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11014/files
  - new: https://git.openjdk.org/jdk/pull/11014/files/304e98b3..6d639569

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

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

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

From duke at openjdk.org  Mon Dec  5 07:44:30 2022
From: duke at openjdk.org (yansendao)
Date: Mon, 5 Dec 2022 07:44:30 GMT
Subject: Integrated: 8296384: [TESTBUG]
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently
 timeout
In-Reply-To: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
References: <R7EIQKTVY2og4E4DM4P-xmSSUs3JhpzjIHoKyJe0QVQ=.2f0f83f1-84e7-48e0-a89c-1a1034b960a3@github.com>
Message-ID: <G6N7ROtRrzWGpQiRlOPflRkZk0sRJ9QcMAwkmWc9g-8=.79e66c20-ff4e-461c-ad34-e816c30f7e9d@github.com>

On Mon, 7 Nov 2022 09:04:45 GMT, yansendao <duke at openjdk.org> wrote:

> 8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

This pull request has now been integrated.

Changeset: 82561de7
Author:    sendaoYan <yansendao.ysd at alibaba-inc.com>
Committer: Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82561de722b9ca580c0c1a53050c711b64611352
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8296384: [TESTBUG] sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java intermittently timeout

Reviewed-by: weijun, wetmore

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

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

From mullan at openjdk.org  Mon Dec  5 15:24:04 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 5 Dec 2022 15:24:04 GMT
Subject: RFR: 8267617: Certificate's IP x509 NameConstraints raises
 ArrayIndexOutOfBoundsException
In-Reply-To: <Xib64SYD-Ke0N-4JSQyt9VsSRS_ltrrU_KeBIDWmBQk=.9582ab29-8124-48b9-a64a-0f08e94af2e8@github.com>
References: <Xib64SYD-Ke0N-4JSQyt9VsSRS_ltrrU_KeBIDWmBQk=.9582ab29-8124-48b9-a64a-0f08e94af2e8@github.com>
Message-ID: <IpAMd3FFIAeREIATDAk7VxiEU5rYZTZ8bzz208eha4M=.9117003a-27b6-4242-8ec9-4f00a3fd6f6a@github.com>

On Thu, 1 Dec 2022 16:37:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the exceptions that may occur when merging IP address NameConstraints from different certificates in a chain.
> 
> The included test reports 3 exceptions without the fix, passes with the fix applied.
> 
> Tiers 1-3 continue to pass.

Looks good.

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

Marked as reviewed by mullan (Reviewer).

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

From sgehwolf at openjdk.org  Mon Dec  5 15:32:20 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 5 Dec 2022 15:32:20 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684
Message-ID: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>

Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?

Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

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

Commit messages:
 - 8298108: Add a regression test for JDK-8297684

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

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

From sgehwolf at openjdk.org  Mon Dec  5 17:50:48 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 5 Dec 2022 17:50:48 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v2]
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <NlXzCUTGtCnxWayqsHBW2GGwhp_mCMcR9IhIREwroys=.9a825322-7f50-4162-9e82-3dd0b1917e05@github.com>

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove extraneous process builder creation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11515/files
  - new: https://git.openjdk.org/jdk/pull/11515/files/c2418a8d..c380b8ae

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

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

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

From sgehwolf at openjdk.org  Mon Dec  5 17:56:49 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 5 Dec 2022 17:56:49 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v3]
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <Fh7j9hupkSMYWGgSSsX9PedmJfDw1XW3HeRlDd-5vHQ=.81888aa1-706b-45f2-978c-ad7ac40a0747@github.com>

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused Path arg for test invocation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11515/files
  - new: https://git.openjdk.org/jdk/pull/11515/files/c380b8ae..ebc86659

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

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

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

From sviswanathan at openjdk.org  Mon Dec  5 18:24:19 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 5 Dec 2022 18:24:19 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
Message-ID: <LJ_pfBhTBrHJjeN46E8JtCoaSnUYJ-Nw1DJpwi5FbAc=.8050c03a-5106-41af-b7b9-fe5c8f0d6d21@github.com>

On Thu, 1 Dec 2022 18:23:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

@valeriepeng Could you please take a look at this PR?

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

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

From naoto at openjdk.org  Mon Dec  5 18:26:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:26:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v5]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <ynj7DlOjqZgdAGPXz_J-CMPBPLJk6jsLCLpPPYKlDKg=.906b2710-397c-4411-831a-783000cf70cf@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/7c0740aa..00a0e3fc

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

  Stats: 57 lines in 5 files changed: 26 ins; 22 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Mon Dec  5 18:33:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:33:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  oleole -> ole

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/00a0e3fc..31656331

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

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

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

From jnimeh at openjdk.org  Mon Dec  5 18:42:06 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 5 Dec 2022 18:42:06 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <LJ_pfBhTBrHJjeN46E8JtCoaSnUYJ-Nw1DJpwi5FbAc=.8050c03a-5106-41af-b7b9-fe5c8f0d6d21@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
 <LJ_pfBhTBrHJjeN46E8JtCoaSnUYJ-Nw1DJpwi5FbAc=.8050c03a-5106-41af-b7b9-fe5c8f0d6d21@github.com>
Message-ID: <CmPX_7L06grEfYbE-RGA4lrfOnog84fBIAArnVphNY0=.c5d649cd-12d8-4efc-8824-2849d959cb9f@github.com>

On Mon, 5 Dec 2022 18:22:00 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove comment
>
> @valeriepeng Could you please take a look at this PR?

@sviswa7 I will be looking at this today

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

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

From mpowers at openjdk.org  Mon Dec  5 18:49:43 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 5 Dec 2022 18:49:43 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
 [v4]
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <VV46Pub5bH00N8_7_msqsMudxYxkQBJrgJ23VG1guEQ=.44c5c01c-e3c2-4663-8cfa-d9fcaa3f4a0e@github.com>

> https://bugs.openjdk.org/browse/JDK-8293412

Mark Powers 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 eight additional commits since the last revision:

 - Merge
 - javadoc update
 - yes we need /dev/urandom
 - Merge
 - Merge
 - second iteration
 - Merge
 - first iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10716/files
  - new: https://git.openjdk.org/jdk/pull/10716/files/80be7e6b..8076b616

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

  Stats: 89795 lines in 1773 files changed: 38018 ins; 35347 del; 16430 mod
  Patch: https://git.openjdk.org/jdk/pull/10716.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10716/head:pull/10716

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

From jlaskey at openjdk.org  Mon Dec  5 19:10:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 19:10:40 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
Message-ID: <za2uEjGQFEz5J5OE0DGGh4CM8ReMsVWDEH1CP3tqn0Q=.ade0c382-0cba-4807-9590-ceae0ee59876@github.com>

On Mon, 5 Dec 2022 18:33:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oleole -> ole

LGTM

src/java.base/share/classes/jdk/internal/access/JavaIOAccess.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.access;

Update copyright

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

Marked as reviewed by jlaskey (Reviewer).

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

From duke at openjdk.org  Mon Dec  5 19:50:15 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 19:50:15 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <H-oM4Aas2MEYORLUsUE03ay3ewD3OLnFeTly7dQSesw=.f385a1ac-22c4-4645-a04d-d9a219ea8082@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties line 160:

> 158: xmlrch.errupdate = \u5EFA\u69CB\u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 159: xmlrch.errupdrow = \u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 160: xmlrch.chars = \u5B57\u5143:\u0020

Likely not needed, since the original and all other l10n versions of RowSetResourceBundle.properties do not have a trailing space for `xmlrch.chars`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n\u0020\u0020

Likely a mistake, since as you stated, it is not in the format ?foo:\u0020? as there is a newline before the trailing spaces.

However if intentional it should probably be `FormatFailed = An internal error occurred while formatting the following message:\n\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 139:

> 137:         EncodingByteOrderUnsupported = Given byte order for encoding \"{0}\" is not supported.
> 138:         InvalidByte = Invalid byte {0} of {1}-byte UTF-8 sequence.
> 139:         ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020\u0020

Same here as well, either a mistake or should be ` ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 219:

> 217:         MSG_NOTATION_NAME_REQUIRED_FOR_UNPARSED_ENTITYDECL = The notation name is required after \"NDATA\" in the declaration for the entity \"{0}\".
> 218:         EntityDeclUnterminated = The declaration for the entity \"{0}\" must end with ''>''.
> 219: 	MSG_DUPLICATE_ENTITY_DEFINITION = Entity \"{0}\" is declared more than once.\u0020\u0020\u0020\u0020\u0020\u0020\u0020\u0020

Likely not intentional, but if it is then perhaps `MSG_DUPLICATE_ENTITY_DEFINITION = Entity "{0}" is declared more than once.\u0009` instead.

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

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

From bhuang at openjdk.org  Mon Dec  5 19:52:18 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 19:52:18 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang 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 five additional commits since the last revision:

 - Merge branch 'master' into JDK-8295087
 - Added an extra line to the end of the policy file.
 - AssertThrows an exception in InconsistentEntries test.
 - Refactored to use testng framework for test enviroment setup.
 - Converted security manual tests to automated tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/8b45f39f..32b656ca

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

  Stats: 297635 lines in 3764 files changed: 148190 ins; 96710 del; 52735 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

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

From naoto at openjdk.org  Mon Dec  5 19:52:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:52:59 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Fixed the copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/31656331..8b6859ed

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

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

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

From naoto at openjdk.org  Mon Dec  5 19:53:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:53:03 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
 <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
Message-ID: <RmT1uDPVJaVYkXuvqLhsNo2qMYrJ6INV5Q84sREuzp8=.23beb44f-4e94-499b-9e0f-f6b07d789558@github.com>

On Sun, 4 Dec 2022 17:09:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the expected behavior when the SecurityManager is enabled
>
> src/java.base/share/classes/java/io/Console.java line 627:
> 
>> 625:         });
>> 626:     }
>> 627:     private static Console cons;
> 
> The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

Changed it to final

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

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

From jlaskey at openjdk.org  Mon Dec  5 20:07:45 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 20:07:45 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <UR7qa0ZKDOWbPDheSyV0-EdLU1f5RQn1eLUFbG-VWsQ=.b6701fd3-6968-4b9f-9506-0a866f095b1e@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Marked as reviewed by jlaskey (Reviewer).

Marked as reviewed by jlaskey (Reviewer).

LGTM

Marked as reviewed by jlaskey (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11421Marked as reviewed by jlaskey (Reviewer).

From mullan at openjdk.org  Mon Dec  5 21:09:53 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 5 Dec 2022 21:09:53 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v3]
In-Reply-To: <Fh7j9hupkSMYWGgSSsX9PedmJfDw1XW3HeRlDd-5vHQ=.81888aa1-706b-45f2-978c-ad7ac40a0747@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <Fh7j9hupkSMYWGgSSsX9PedmJfDw1XW3HeRlDd-5vHQ=.81888aa1-706b-45f2-978c-ad7ac40a0747@github.com>
Message-ID: <cer81SHUGNvBqayzVVIkOQh1Vyp-gdG0quspFJiUJXs=.1e73f89e-37c8-4e42-a1a9-bf7d6b20c4b7@github.com>

On Mon, 5 Dec 2022 17:56:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused Path arg for test invocation

A regression test was added as part of the fix for https://bugs.openjdk.org/browse/JDK-8280890. See the commit log for more details: https://github.com/openjdk/jdk/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d#diff-6de8303e80bab41e34a29b272cff64a68d3b255f0f147ee16ef21680abf7f41a

Since this is a different way of testing the same underlying issue and the problem shows up in more than one way, I agree it is a good idea to add another regression test. However, I would put in the same test directory as 8280890: test/jdk/java/security/SignedJar

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

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

From ascarpino at openjdk.org  Mon Dec  5 21:51:26 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 5 Dec 2022 21:51:26 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
Message-ID: <0GoXaEqwMXUsJfJnks-QJqgarFMY5zWxk5eW32Y8-YM=.5e942b3e-a9b5-453d-a972-00766a85b95b@github.com>

On Thu, 1 Dec 2022 18:23:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

The changes look ok to me

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

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

From duke at openjdk.org  Mon Dec  5 22:05:51 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 5 Dec 2022 22:05:51 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v4]
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <p7Wnh0p2l6MP2AzkiYaO-tMCFKbbRFLW55xo9_u_1J0=.e5504291-0fd6-4361-989e-eb52c0a24006@github.com>

> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
> 
> Fuzzing test expanded to also include ByteBuffer payloads.
> 
> Performance is now matched:
> 
> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
> 
> Relates to:
> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.

Volodymyr Paprotski 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
 - remove comment
 - bench and handle buf.position()
 - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
 - whitespace
 - ByteBuffer support and tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11338/files
  - new: https://git.openjdk.org/jdk/pull/11338/files/14726d7b..a87297f3

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

  Stats: 45355 lines in 999 files changed: 17638 ins; 21210 del; 6507 mod
  Patch: https://git.openjdk.org/jdk/pull/11338.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11338/head:pull/11338

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

From duke at openjdk.org  Mon Dec  5 22:05:54 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 5 Dec 2022 22:05:54 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v3]
In-Reply-To: <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <-PZoxQ6OXiIRj5niVWF4gdmN7T7x7Dm8LX4TdXd9ICc=.d3c50769-6305-42de-85f5-4e8d0854321f@github.com>
Message-ID: <dZ4ftCGq03X_eKGdjQKq9IZ-ja9cv6vrOpN3WF11Pjc=.197aa6b8-2340-44f2-9879-9cb850174509@github.com>

On Thu, 1 Dec 2022 18:23:45 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

(The build failures do not look related to this PR, trying to see if fixed in main branch)

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

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

From ascarpino at openjdk.org  Mon Dec  5 22:13:24 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 5 Dec 2022 22:13:24 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v4]
In-Reply-To: <p7Wnh0p2l6MP2AzkiYaO-tMCFKbbRFLW55xo9_u_1J0=.e5504291-0fd6-4361-989e-eb52c0a24006@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <p7Wnh0p2l6MP2AzkiYaO-tMCFKbbRFLW55xo9_u_1J0=.e5504291-0fd6-4361-989e-eb52c0a24006@github.com>
Message-ID: <abDdhi2hk3RfWAVMPQ4dD75MUWWSRplqGPzIg3iCvYA=.e94d95e4-7cd0-46c4-b71f-c06ff53eb9a7@github.com>

On Mon, 5 Dec 2022 22:05:51 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
>  - remove comment
>  - bench and handle buf.position()
>  - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
>  - whitespace
>  - ByteBuffer support and tests

Marked as reviewed by ascarpino (Reviewer).

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

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

From ascarpino at openjdk.org  Mon Dec  5 23:53:11 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 5 Dec 2022 23:53:11 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v4]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <6I7QWU-lEUA9ElWYHJOtEXkfUJJmqbqalJ2i0MNGtNw=.3c47ae3c-7d23-44a3-b257-5c19d4123e9d@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  another comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11121/files
  - new: https://git.openjdk.org/jdk/pull/11121/files/340ab22f..99e350b2

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

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

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

From jnimeh at openjdk.org  Tue Dec  6 02:50:05 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 6 Dec 2022 02:50:05 GMT
Subject: RFR: 8297379: Enable the ByteBuffer path of Poly1305 optimizations
 [v4]
In-Reply-To: <p7Wnh0p2l6MP2AzkiYaO-tMCFKbbRFLW55xo9_u_1J0=.e5504291-0fd6-4361-989e-eb52c0a24006@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
 <p7Wnh0p2l6MP2AzkiYaO-tMCFKbbRFLW55xo9_u_1J0=.e5504291-0fd6-4361-989e-eb52c0a24006@github.com>
Message-ID: <KV6yMpyVg2-s3s1AsKGXsOIDuvSX-9zuf5l1uXhBtRQ=.5d326060-e33d-4750-a278-a5d3fb55a111@github.com>

On Mon, 5 Dec 2022 22:05:51 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
>> 
>> Fuzzing test expanded to also include ByteBuffer payloads.
>> 
>> Performance is now matched:
>> 
>> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
>> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
>> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
>> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
>> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
>> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
>> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
>> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
>> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
>> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
>> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
>> 
>> Relates to:
>> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
>> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.
>
> Volodymyr Paprotski 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
>  - remove comment
>  - bench and handle buf.position()
>  - Merge remote-tracking branch 'origin/master' into avx512-poly-buf
>  - whitespace
>  - ByteBuffer support and tests

Changes look fine.  tier1-5 + hs-precheckin-comp test jobs came back clean with the exception of two jaxp failures only on linux-x64 but they don't appear to be related to your changes.

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

Marked as reviewed by jnimeh (Reviewer).

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

From jpai at openjdk.org  Tue Dec  6 06:06:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:06:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <jCZcWYzVC1Sp_rkTvRHeSBUowXx1BCkTA_HnB8Be9KQ=.af7eb51a-5d9a-4666-bf34-65d48dae1319@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 50:

> 48:      * {@inheritDoc}
> 49:      */
> 50:     public JdkConsole console(boolean isTTY) {

Hello Naoto, this is missing a `@Override`.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 58:

> 56:      * public Console class.
> 57:      */
> 58:     public static class JdkConsoleImpl implements JdkConsole {

Can this be `private` class? Also, the methods in this class are missing the `@Override`.

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

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

From jpai at openjdk.org  Tue Dec  6 06:16:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:16:09 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <WOH-ibxViM4sSleRr3z7nWv1y_MsN7M6EZCNZhUBfbU=.ad011b20-1bd1-4b75-9926-29c8ce6317d9@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:

> 111:         public JdkConsoleImpl() {
> 112:             try {
> 113:                 terminal = TerminalBuilder.builder().build();

The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

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

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

From jpai at openjdk.org  Tue Dec  6 06:22:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:22:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 99:

> 97:  */
> 98: 
> 99: public class Console implements Flushable

Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

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

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

From jpai at openjdk.org  Tue Dec  6 07:02:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:02:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <CkmM7v_Lh-rsQ8_sRfxIuHqsonz2GzXleEQ44vTD0Ig=.d3b44b2c-6d14-4f12-aeba-805ad2a62539@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 615:

> 613:                 var consModName = System.getProperty("jdk.console",
> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()

Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?

I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?


public class Hello {
	public static void main(final String[] args) {
	}
}


java -verbose:class Hello.java


Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:


final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
// ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

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

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

From jpai at openjdk.org  Tue Dec  6 07:11:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:11:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 616:

> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 616:                         .map(ServiceLoader.Provider::get)

Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

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

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

From jpai at openjdk.org  Tue Dec  6 07:18:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:18:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <GATX3t9zGQviww5AKhDFAkThUgIg6Woa04HuZw3ZlsA=.d580348b-e014-4020-aec3-034cff83d1e6@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (ServiceConfigurationError ignore) {

Should we perhaps just catch `Throwable` here since it's possible that the `PrivelegedAction` code could throw unchecked exception (for example the call to `JdkConsoleProvider.console()` could, in theory, lead to any kind of unchecked exceptions or errors like `NoClassDefFoundError`).

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

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

From jpai at openjdk.org  Tue Dec  6 07:38:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:38:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Hello Naoto, the class level javadoc of `java.io.Console` currently specifies synchronization expectations in the context of multithreaded use:

>  Read and write operations are synchronized to guarantee the atomic
>  completion of critical operations; therefore invoking methods
>  {@link #readLine()}, {@link #readPassword()}, {@link #format format()},
>  {@link #printf printf()} as well as the read, format and write operations
>  on the objects returned by {@link #reader()} and {@link #writer()} may
>  block in multithreaded scenarios.

So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

While we are at it, the Console class level javadoc also states:

> If the virtual machine is started from an
> interactive command line without redirecting the standard input and
> output streams then its console will exist and will typically be
> connected to the keyboard and display from which the virtual machine
> was launched.

With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

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

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

From alanb at openjdk.org  Tue Dec  6 07:38:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 07:38:55 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
Message-ID: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>

On Tue, 6 Dec 2022 07:08:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

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

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

From xuelei at openjdk.org  Tue Dec  6 07:58:02 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 6 Dec 2022 07:58:02 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - check duplicate
 - Merge
 - Merge
 - Merge
 - add test cases
 - 8281236: (D)TLS key exchange algorithms

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

Changes: https://git.openjdk.org/jdk/pull/9776/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=03
  Stats: 982 lines in 17 files changed: 746 ins; 195 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9776.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9776/head:pull/9776

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

From djelinski at openjdk.org  Tue Dec  6 08:27:14 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 6 Dec 2022 08:27:14 GMT
Subject: Integrated: 8267617: Certificate's IP x509 NameConstraints raises
 ArrayIndexOutOfBoundsException
In-Reply-To: <Xib64SYD-Ke0N-4JSQyt9VsSRS_ltrrU_KeBIDWmBQk=.9582ab29-8124-48b9-a64a-0f08e94af2e8@github.com>
References: <Xib64SYD-Ke0N-4JSQyt9VsSRS_ltrrU_KeBIDWmBQk=.9582ab29-8124-48b9-a64a-0f08e94af2e8@github.com>
Message-ID: <wPKhqtzK_Vh2DB7Rp4291kwRludKzZh4nInFw-go-Do=.98e42c84-35e2-4a10-a6cc-850fba2b0c2f@github.com>

On Thu, 1 Dec 2022 16:37:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the exceptions that may occur when merging IP address NameConstraints from different certificates in a chain.
> 
> The included test reports 3 exceptions without the fix, passes with the fix applied.
> 
> Tiers 1-3 continue to pass.

This pull request has now been integrated.

Changeset: 2a243a33
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a243a33cc09f4674b232d89f36fb731055009d9
Stats:     86 lines in 2 files changed: 81 ins; 0 del; 5 mod

8267617: Certificate's IP x509 NameConstraints raises ArrayIndexOutOfBoundsException

Reviewed-by: mullan

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

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

From sgehwolf at openjdk.org  Tue Dec  6 09:51:06 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 09:51:06 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v3]
In-Reply-To: <cer81SHUGNvBqayzVVIkOQh1Vyp-gdG0quspFJiUJXs=.1e73f89e-37c8-4e42-a1a9-bf7d6b20c4b7@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <Fh7j9hupkSMYWGgSSsX9PedmJfDw1XW3HeRlDd-5vHQ=.81888aa1-706b-45f2-978c-ad7ac40a0747@github.com>
 <cer81SHUGNvBqayzVVIkOQh1Vyp-gdG0quspFJiUJXs=.1e73f89e-37c8-4e42-a1a9-bf7d6b20c4b7@github.com>
Message-ID: <xe55n_2DNQ1Pe46ZFT3W3Z1a8QjyM2BlCAq2bksZPhs=.6fdb33a9-0cf2-4e16-a45a-4fea637fcc4a@github.com>

On Mon, 5 Dec 2022 21:07:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Since this is a different way of testing the same underlying issue and the problem shows up in more than one way, I agree it is a good idea to add another regression test. However, I would put in the same test directory as 8280890: test/jdk/java/security/SignedJar

Sounds good. I'll do that.

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

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

From pminborg at openjdk.org  Tue Dec  6 10:06:28 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 Dec 2022 10:06:28 GMT
Subject: RFR: 8296024: Usage of DirectBuffer::address should be guarded
 [v18]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <qPCDfZtLtQZXFvPU1SADYcB_V6t0TKVyhTlHi98_CZ8=.055b5ef4-44b0-4c16-8111-d483c027da82@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge master
 - Remove session exposure
 - Re-introduce yet another address vairable
 - Re-introduce address variables
 - Reformat and fix comment
 - Remove redundant method
 - Cleanup
 - Refactor to try-finally handling
 - Remove redundant guard and fix comment permanently
 - Rework Acquisition
 - ... and 9 more: https://git.openjdk.org/jdk/compare/a6139985...cd95bc86

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

Changes: https://git.openjdk.org/jdk/pull/11260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=17
  Stats: 809 lines in 24 files changed: 377 ins; 172 del; 260 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Tue Dec  6 10:47:59 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 Dec 2022 10:47:59 GMT
Subject: Integrated: 8296024: Usage of DirectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <qx7uCPevkZ16sZWBJ3TC0_USr-FcMYAxOMNx6WDlYyg=.6681bd04-2dbf-4c06-9098-f05e067c4e25@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

This pull request has now been integrated.

Changeset: 84b927a0
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84b927a05bcb7bf32a12829070ffd3a5670066d2
Stats:     809 lines in 24 files changed: 377 ins; 172 del; 260 mod

8296024: Usage of DirectBuffer::address should be guarded

Reviewed-by: mcimadamore, alanb, psandoz, bpb

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

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

From sgehwolf at openjdk.org  Tue Dec  6 10:50:30 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 10:50:30 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v4]
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <epd8Az5MB0T5O9mzNQCUoEtssuuSA2SaV9blALmuH2g=.cdebd25d-9375-4f01-bb68-d35ea282986b@github.com>

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Move test to test/jdk/java/security/SignedJar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11515/files
  - new: https://git.openjdk.org/jdk/pull/11515/files/ebc86659..381ff2d8

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

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

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

From sgehwolf at openjdk.org  Tue Dec  6 11:13:29 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 11:13:29 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v5]
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <1IpLWJf06hru5H5Wpbqdb2P85NeSHU00Ag9_VY_jQq0=.897a03d0-0fc6-41da-b550-97c3901995ab@github.com>

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Adjust test setup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11515/files
  - new: https://git.openjdk.org/jdk/pull/11515/files/381ff2d8..052d6835

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

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

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

From sgehwolf at openjdk.org  Tue Dec  6 11:15:28 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 11:15:28 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v4]
In-Reply-To: <epd8Az5MB0T5O9mzNQCUoEtssuuSA2SaV9blALmuH2g=.cdebd25d-9375-4f01-bb68-d35ea282986b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <epd8Az5MB0T5O9mzNQCUoEtssuuSA2SaV9blALmuH2g=.cdebd25d-9375-4f01-bb68-d35ea282986b@github.com>
Message-ID: <dEySASp77yMI-zw3TRUdSXLA-GuufZhjlyHhpCZtOX4=.fb197a43-dfbf-4228-a04d-1f294ae4a362@github.com>

On Tue, 6 Dec 2022 10:50:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test to test/jdk/java/security/SignedJar

Should be ready now, thanks!

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

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

From alanb at openjdk.org  Tue Dec  6 12:11:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 12:11:08 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
Message-ID: <qHY5N00TioxM21y-BFNYHepWP6wM7O-0xBvTMkHmiGM=.6897a418-7b87-44f4-aa76-ee206a2d29ac@github.com>

On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

As it happens I was chatting with Naoto about this area yesterday. There are effectively two Console implementations, the base implementation in Console, and the subclass in ProxyingConsole. When using ProxyingConsole then the state/implementation in the superclass isn't used. So either the locks are exposed to the subclass or there is a bit more surgery done so there are two subclasses, each with their own read and write locks. Subclasses might be cleaned as there is state in Console that is not interesting for the new implementation.

> With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

That is a good observation, instead of "will typically not have a console" then it should probably say "may not have a console".

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

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

From mullan at openjdk.org  Tue Dec  6 15:12:55 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 15:12:55 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v5]
In-Reply-To: <1IpLWJf06hru5H5Wpbqdb2P85NeSHU00Ag9_VY_jQq0=.897a03d0-0fc6-41da-b550-97c3901995ab@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <1IpLWJf06hru5H5Wpbqdb2P85NeSHU00Ag9_VY_jQq0=.897a03d0-0fc6-41da-b550-97c3901995ab@github.com>
Message-ID: <xxhBJTpxIqO2VQZBm0R0tsm7OOPT40tKqqPtrXZ4wyU=.0c38b40e-1dc2-4df5-aaa5-cafa7d2e6a5d@github.com>

On Tue, 6 Dec 2022 11:13:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test setup

test/jdk/java/security/SignedJar/spi-calendar-provider/provider/baz/CalendarDataProviderImpl.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.

Did you copy this code from somewhere else? In any case, the impl seems trivial so I don't think it needs to have the Oracle copyright. Otherwise, you should probably use your own company here, and just put 2022 as the date.

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

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

From mbaesken at openjdk.org  Tue Dec  6 15:30:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Dec 2022 15:30:08 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
Message-ID: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>

We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

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

Commit messages:
 - JDK-8298170

Changes: https://git.openjdk.org/jdk/pull/11539/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298170
  Stats: 87 lines in 7 files changed: 32 ins; 39 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11539/head:pull/11539

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

From duke at openjdk.org  Tue Dec  6 16:51:13 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 6 Dec 2022 16:51:13 GMT
Subject: Integrated: 8297379: Enable the ByteBuffer path of Poly1305
 optimizations
In-Reply-To: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
References: <YsdrfsCDtl6tLU62Q6V2IJlH2DAIgnk4SvbKdZ6NejU=.f9432c61-91cf-42f9-8161-c8411a8c9094@github.com>
Message-ID: <hbr9wO_ROzmqx4GjR1DPcORuukdDlI1v0c8j93j5fSM=.c996105f-5093-4e84-867d-f8511f9d72ef@github.com>

On Wed, 23 Nov 2022 23:33:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> There is now an intrinsic for Poly1305, which is only enabled on the `engineUpdate([]byte)` path. This PR adds intrinsic support `engineUpdate(ByteBuffer)` (when the bytebuffer `hasArray`).
> 
> Fuzzing test expanded to also include ByteBuffer payloads.
> 
> Performance is now matched:
> 
> Benchmark                         (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.digestBuffer          64              thrpt    3  3320909.857 ? 787300.545  ops/s
> Poly1305DigestBench.digestBuffer         256              thrpt    3  3006447.324 ? 704790.796  ops/s
> Poly1305DigestBench.digestBuffer        1024              thrpt    3  2645041.509 ? 664904.622  ops/s
> Poly1305DigestBench.digestBuffer       16384              thrpt    3   893389.209 ?   6288.743  ops/s
> Poly1305DigestBench.digestBuffer     1048576              thrpt    3    14932.680 ?    170.238  ops/s
> Poly1305DigestBench.digestBytes           64              thrpt    3  3548298.515 ? 859964.530  ops/s
> Poly1305DigestBench.digestBytes          256              thrpt    3  3083261.994 ? 141802.417  ops/s
> Poly1305DigestBench.digestBytes         1024              thrpt    3  2704357.584 ? 554683.019  ops/s
> Poly1305DigestBench.digestBytes        16384              thrpt    3   898913.339 ?  99733.295  ops/s
> Poly1305DigestBench.digestBytes      1048576              thrpt    3    14961.872 ?     38.003  ops/s
> Finished running test 'micro:org.openjdk.bench.javax.crypto.full.Poly1305DigestBench'
> 
> Relates to:
> - https://github.com/openjdk/jdk/pull/11463: Found inconsistency between processing `[]byte` and `ByteBuffer`. When that one is fixed, `Poly1305IntrinsicFuzzTest.java` should not be setting the endianness on the `ByteBuffer`
> - Intrinsic introduced by https://github.com/openjdk/jdk/pull/10582.

This pull request has now been integrated.

Changeset: 203251ff
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/203251ffc0ea8b9bb9c8b95c50434e4185020d84
Stats:     86 lines in 3 files changed: 67 ins; 3 del; 16 mod

8297379: Enable the ByteBuffer path of Poly1305 optimizations

Reviewed-by: sviswanathan, ascarpino, jnimeh

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

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

From mullan at openjdk.org  Tue Dec  6 16:55:18 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 16:55:18 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
Message-ID: <OT3SNsaccgtS1vTtWGRfgBazYDa3HYCWHjVuOJeATrU=.0001a54b-f99d-45bc-8b67-c146667bd29b@github.com>

On Tue, 6 Dec 2022 07:58:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - check duplicate
>  - Merge
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 27:

> 25:  * @test
> 26:  * @bug 8281236
> 27:  * @summary (D)TLS key exchange named groups

Can you write a more specific summary of what this test is testing? The @summary doesn't have to match the bug title (and often should not IMO). Since this doesn't test DTLS, that should not be included.

Same comment for the other tests.

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

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

From mullan at openjdk.org  Tue Dec  6 17:02:14 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 17:02:14 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
Message-ID: <W0D1h57pT3H3B82mFm4Ok8KhOuWDKwaJtAjf0PNnhqM=.09cae893-8145-44d9-a0e9-c3da76446aa7@github.com>

On Tue, 6 Dec 2022 07:58:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - check duplicate
>  - Merge
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 34:

> 32: public class NamedGroupsSpec {
> 33:     public static void main(String[] args) throws Exception {
> 34:         runTest(new String[] {

How about adding a test for a `null` array?

test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 68:

> 66:         SSLParameters sslParams = new SSLParameters();
> 67:         try {
> 68:             sslParams.setNamedGroups(namedGroups);

You should also test that `getNamedGroups` returns the same elements.

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

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

From sgehwolf at openjdk.org  Tue Dec  6 17:32:13 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 17:32:13 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v5]
In-Reply-To: <xxhBJTpxIqO2VQZBm0R0tsm7OOPT40tKqqPtrXZ4wyU=.0c38b40e-1dc2-4df5-aaa5-cafa7d2e6a5d@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <1IpLWJf06hru5H5Wpbqdb2P85NeSHU00Ag9_VY_jQq0=.897a03d0-0fc6-41da-b550-97c3901995ab@github.com>
 <xxhBJTpxIqO2VQZBm0R0tsm7OOPT40tKqqPtrXZ4wyU=.0c38b40e-1dc2-4df5-aaa5-cafa7d2e6a5d@github.com>
Message-ID: <vXUguUFNL5IC2eUFEN7qqPZC2XaHPpxSCWMlkdTpEiE=.d5085333-07d6-46fd-91f7-97cf532e9d48@github.com>

On Tue, 6 Dec 2022 15:09:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust test setup
>
> test/jdk/java/security/SignedJar/spi-calendar-provider/provider/baz/CalendarDataProviderImpl.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Did you copy this code from somewhere else? In any case, the impl seems trivial so I don't think it needs to have the Oracle copyright. Otherwise, you should probably use your own company here, and just put 2022 as the date.

OK.

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

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

From sgehwolf at openjdk.org  Tue Dec  6 17:48:21 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 17:48:21 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v6]
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11515/files
  - new: https://git.openjdk.org/jdk/pull/11515/files/052d6835..b3b4e220

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

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

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

From sgehwolf at openjdk.org  Tue Dec  6 17:48:25 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Dec 2022 17:48:25 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v5]
In-Reply-To: <vXUguUFNL5IC2eUFEN7qqPZC2XaHPpxSCWMlkdTpEiE=.d5085333-07d6-46fd-91f7-97cf532e9d48@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <1IpLWJf06hru5H5Wpbqdb2P85NeSHU00Ag9_VY_jQq0=.897a03d0-0fc6-41da-b550-97c3901995ab@github.com>
 <xxhBJTpxIqO2VQZBm0R0tsm7OOPT40tKqqPtrXZ4wyU=.0c38b40e-1dc2-4df5-aaa5-cafa7d2e6a5d@github.com>
 <vXUguUFNL5IC2eUFEN7qqPZC2XaHPpxSCWMlkdTpEiE=.d5085333-07d6-46fd-91f7-97cf532e9d48@github.com>
Message-ID: <bBmBjMjFN2TByUB8_BbaPZpvJu_VYlcnGIEmLjps75M=.8463a050-8946-44e8-b9d3-ec14de339137@github.com>

On Tue, 6 Dec 2022 17:29:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/java/security/SignedJar/spi-calendar-provider/provider/baz/CalendarDataProviderImpl.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Did you copy this code from somewhere else? In any case, the impl seems trivial so I don't think it needs to have the Oracle copyright. Otherwise, you should probably use your own company here, and just put 2022 as the date.
>
> OK.

Fixed now.

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

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

From naoto at openjdk.org  Tue Dec  6 18:01:27 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:01:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v8]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Hgi1xIbIUO4QdDPDs3iYPYBi5j6iXb5BGXa6sbuNm7w=.741f911f-e343-4a52-9e01-41549509fb9e@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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 22 additional commits since the last revision:

 - Addressing review comments
 - Merge branch 'master' into JDK-8295803-PluginConsole
 - Fixed the copyright year
 - oleole -> ole
 - Addressing review comments.
 - Changed the expected behavior when the SecurityManager is enabled
 - Added more tests, loading with doPrivileged()
 - Adds a test
 - Removed JavaIOAccess.charset() which is no longer needed
 - Minor fixup
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ce6f50f2...204690cf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/8b6859ed..204690cf

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

  Stats: 47908 lines in 1086 files changed: 19444 ins; 21552 del; 6912 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Tue Dec  6 18:13:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:21 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
Message-ID: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>

On Tue, 6 Dec 2022 06:19:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the copyright year
>
> src/java.base/share/classes/java/io/Console.java line 99:
> 
>> 97:  */
>> 98: 
>> 99: public class Console implements Flushable
> 
> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

Right. Will address it after this PR.

> src/java.base/share/classes/java/io/Console.java line 615:
> 
>> 613:                 var consModName = System.getProperty("jdk.console",
>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 
> Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?
> 
> I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?
> 
> 
> public class Hello {
> 	public static void main(final String[] args) {
> 	}
> }
> 
> 
> java -verbose:class Hello.java
> 
> 
> Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:
> 
> 
> final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
> // ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
> return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

Changed it to use the boot layer `ServiceLoader.load(ModuleLayer.boot(), JdkConsoleProvider.class)`

> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:
> 
>> 111:         public JdkConsoleImpl() {
>> 112:             try {
>> 113:                 terminal = TerminalBuilder.builder().build();
> 
> The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

Initially, I thought of having charset as an argument to the constructor but realized jline would delve into the platform and figure out the same encoding, so I omitted it. However now I realized that the user could specify the standard out encoding via the `stdout/err.encoding` system property. So I revived the charset argument, as in your suggestion.

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

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

From naoto at openjdk.org  Tue Dec  6 18:13:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:22 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
 <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
Message-ID: <2uHRKaMBaLaQmhYzbo1yOetB4DYyrbm7rxW-sFGg0n8=.4e8e537d-e6a3-4299-81a2-b93147359be0@github.com>

On Tue, 6 Dec 2022 07:34:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 616:
>> 
>>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
>>> 616:                         .map(ServiceLoader.Provider::get)
>> 
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
>
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
> 
> You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

`module-info.java` in the java.base only allows `jdk.internal.le` and `jdk.jshell` modules to access the `jdk.internal.io.JdkConsoleProvider` interface. So unless the user intentionally exports it, no other implementations are effectively instantiated.

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

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

From mullan at openjdk.org  Tue Dec  6 18:14:02 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 18:14:02 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
Message-ID: <daq0l0Z1ir3Mq-MtwIfmp4ulu23WgpPQyIoMHJfO0cM=.4c99601d-de92-41f4-8d86-a28552b83ecf@github.com>

On Tue, 6 Dec 2022 07:58:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - check duplicate
>  - Merge
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

test/jdk/javax/net/ssl/SSLParameters/NamedGroups.java line 122:

> 120:                 null,
> 121:                 false);
> 122:         runTest(new String[0],

I think this case will throw IAE when `SSLParameter.setNamedGroups()` is called right? If so, I think you can delete this test (and the one one on line 123) since it is already covered in the NamedGroupsSpec test. Also, this test is coded such that the expected exception is thrown when the TLS handshake is being made in `runClientApplication()`, which is not the case here.

Same comment for the DTLSNamedGroups test.

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

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

From prr at openjdk.org  Tue Dec  6 18:35:05 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 6 Dec 2022 18:35:05 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <P4RXObyKU5mTlOUCcSUCrvu4eDFBpoMIV6uJrwsQiwA=.715ee905-2079-446d-a4c6-e92af67f5bcf@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

I'm OK with the idea and the specific desktop change.
I'll leave the rest to the appropriate component teams.
Seems this needs > 1 reviewer tho' because of the different areas.

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

Marked as reviewed by prr (Reviewer).

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

From mullan at openjdk.org  Tue Dec  6 18:56:37 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 18:56:37 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
Message-ID: <E9rBvKTfQM0tXyCAO7iTflK6oq1T4OIqn_rpRCy38rc=.68331f8f-74ba-495f-980e-bd1d10e65279@github.com>

On Tue, 6 Dec 2022 07:58:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - check duplicate
>  - Merge
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 454:

> 452:     }
> 453: 
> 454:     static NamedGroup getPreferredGroup(

Add a comment describing what this method does. And the method on line 471.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 279:

> 277:         String[] ngs = params.getNamedGroups();
> 278:         if (ngs != null) {
> 279:             // Note if 'ss' is empty, then no signature schemes should be

The comment needs to be updated for named groups. It looks like it was copied from line 272.

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

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

From naoto at openjdk.org  Tue Dec  6 19:17:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:17:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Further addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/204690cf..6cd9843e

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

  Stats: 27 lines in 2 files changed: 20 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

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

From naoto at openjdk.org  Tue Dec  6 19:24:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:24:20 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
Message-ID: <IxAskDLUnZ5MlMZA2jJlX3U5oAFCOD6r1Fk1X5_LSG0=.aa91a045-dfee-4698-ab4b-d494893c426d@github.com>

On Tue, 6 Dec 2022 19:17:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further addressing review comments.

Provided separate independent locks in `ProxyingConsole` for now. Later it can be re-org'ed as Alan suggested for cleaner implementation/interface separation.

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

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

From ascarpino at openjdk.org  Tue Dec  6 20:01:07 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 6 Dec 2022 20:01:07 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v5]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <bxZ52S3GFW2h18h4iHovtbluM3SuU1iMFeopqNV1ER0=.3bd73c7a-fa81-47fe-beb2-fd19a309a774@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request incrementally with 434 additional commits since the last revision:

 - merge with direct change
 - 8298142: Update internal comment on language features in SourceVersion
   
   Reviewed-by: sundar, jlahoda
 - 8297379: Enable the ByteBuffer path of Poly1305 optimizations
   
   Reviewed-by: sviswanathan, ascarpino, jnimeh
 - 8297602: Compiler crash with type annotation and generic record during pattern matching
   
   Reviewed-by: jlahoda
 - 8297687: new URI(S,S,S,S) throws exception with incorrect index position reported in the error message
   
   Reviewed-by: jpai
 - 8298145: Remove ContiguousSpace::capacity
   
   Reviewed-by: tschatzl
 - merge with direct
 - 8297186: G1 triggers unnecessary full GCs when heap utilization is low
   
   Reviewed-by: kbarrett, sjohanss
 - 8297172: Fix some issues of auto-vectorization of `Long.bitCount/numberOfTrailingZeros/numberOfLeadingZeros()`
   
   Reviewed-by: kvn, thartmann
 - 8297689: Fix incorrect result of Short.reverseBytes() call in loops
   
   Reviewed-by: thartmann, jbhateja
 - ... and 424 more: https://git.openjdk.org/jdk/compare/99e350b2...07a73bd8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11121/files
  - new: https://git.openjdk.org/jdk/pull/11121/files/99e350b2..07a73bd8

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

  Stats: 133477 lines in 2253 files changed: 59858 ins; 52478 del; 21141 mod
  Patch: https://git.openjdk.org/jdk/pull/11121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11121/head:pull/11121

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

From ascarpino at openjdk.org  Tue Dec  6 20:05:48 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 6 Dec 2022 20:05:48 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v6]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <q1DGUQMycq4l_IW07i1_y-1yF99LBLdO0tH6qUEn-8M=.787fe510-f16f-4814-8016-aeb566eabf4d@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 443 commits:

 - Merge branch 'master' into gcm
 - merge with direct change
 - 8298142: Update internal comment on language features in SourceVersion
   
   Reviewed-by: sundar, jlahoda
 - 8297379: Enable the ByteBuffer path of Poly1305 optimizations
   
   Reviewed-by: sviswanathan, ascarpino, jnimeh
 - 8297602: Compiler crash with type annotation and generic record during pattern matching
   
   Reviewed-by: jlahoda
 - 8297687: new URI(S,S,S,S) throws exception with incorrect index position reported in the error message
   
   Reviewed-by: jpai
 - 8298145: Remove ContiguousSpace::capacity
   
   Reviewed-by: tschatzl
 - merge with direct
 - 8297186: G1 triggers unnecessary full GCs when heap utilization is low
   
   Reviewed-by: kbarrett, sjohanss
 - 8297172: Fix some issues of auto-vectorization of `Long.bitCount/numberOfTrailingZeros/numberOfLeadingZeros()`
   
   Reviewed-by: kvn, thartmann
 - ... and 433 more: https://git.openjdk.org/jdk/compare/ea83cb96...c3d94670

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

Changes: https://git.openjdk.org/jdk/pull/11121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11121&range=05
  Stats: 80 lines in 1 file changed: 46 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11121/head:pull/11121

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

From mullan at openjdk.org  Tue Dec  6 20:26:14 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 6 Dec 2022 20:26:14 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v6]
In-Reply-To: <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
Message-ID: <jz9WxDdoI44DC_ZFad8sOSBARNviFXkD9RvHVJQeqgs=.2ec74418-4483-49de-a643-f441cfc9d961@github.com>

On Tue, 6 Dec 2022 17:48:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright.

Marked as reviewed by mullan (Reviewer).

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

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

From ascarpino at openjdk.org  Tue Dec  6 20:29:56 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 6 Dec 2022 20:29:56 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v7]
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <H-MJAIiIpHn61RJYdbDv62AKdnDivsD2n6-QKWC2WVk=.f7e5a246-b3ca-400f-9320-9a110c1946d3@github.com>

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:

 - editor screwed up
 - why won't this merge hell stop 2
 - why won't this merge hell stop 3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11121/files
  - new: https://git.openjdk.org/jdk/pull/11121/files/c3d94670..a07c08ce

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

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

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

From rriggs at openjdk.org  Tue Dec  6 20:42:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Dec 2022 20:42:40 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

The existing (and new) macro naming doesn't make clear that it always returns from the function.  The presence of "RETURN" in the name only means there is a return value.
The existing code more obviously handles memory deallocation.

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

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

From mpowers at openjdk.org  Tue Dec  6 20:44:20 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 6 Dec 2022 20:44:20 GMT
Subject: Integrated: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <jW4LTAG-bSQYNyhEJQ8OMYWJY22HU99ujvBwATA6E7g=.88fed511-9bf1-40e8-b685-771911eb6c53@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

This pull request has now been integrated.

Changeset: 79d163d4
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79d163d4994d235266117b425498b0df3d16c3c4
Stats:     17 lines in 3 files changed: 2 ins; 12 del; 3 mod

8293412: Remove unnecessary java.security.egd overrides

Reviewed-by: xuelei, djelinski

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

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

From ascarpino at openjdk.org  Tue Dec  6 21:40:15 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 6 Dec 2022 21:40:15 GMT
Subject: Integrated: 8296507: GCM using more memory than necessary with
 in-place operations
In-Reply-To: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
Message-ID: <ZpyZlk20VlMQcnq40RGsTRDUoVUxhwj8-Rkytzfrcq0=.faf273a0-d631-4ff3-aec5-a7a7685dfb25@github.com>

On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
> 
> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
> 
> 
>     JDK 17:   122913.554 ops/sec
>     JDK 19:    94885.008 ops/sec
>     Post fix: 122735.804 ops/sec 
> 
> There is no regression test because this is a memory change and test coverage already existing.

This pull request has now been integrated.

Changeset: b4da0ee7
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4da0ee706b6a274e6ba4e5483ef972f45c9f81e
Stats:     81 lines in 1 file changed: 48 ins; 1 del; 32 mod

8296507: GCM using more memory than necessary with in-place operations

Reviewed-by: jnimeh

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

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

From naoto at openjdk.org  Tue Dec  6 21:48:36 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 21:48:36 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v10]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <lpDoiTBG0BCmcakQz2tdNL5nt_mAdbbJdhdzhsb5Vhc=.5b6e55fa-a606-464b-a623-bd5181dffa32@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Synchronize reader/writer by wrapping them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/6cd9843e..a54aed5f

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

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

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

From naoto at openjdk.org  Tue Dec  6 22:45:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 22:45:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Making the wrapper classes static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/a54aed5f..40de5d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=09-10

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

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

From xuelei at openjdk.org  Wed Dec  7 06:56:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 06:56:28 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v5]
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <BsjosBre2S8cBDfwmWz2AM7gydZfPecTfp7CQY711fI=.4793aaec-5dc7-43cd-ac70-e91867273084@github.com>

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  review feedback update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9776/files
  - new: https://git.openjdk.org/jdk/pull/9776/files/2039c113..21bf18be

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

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

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

From xuelei at openjdk.org  Wed Dec  7 06:56:38 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 06:56:38 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v4]
In-Reply-To: <E9rBvKTfQM0tXyCAO7iTflK6oq1T4OIqn_rpRCy38rc=.68331f8f-74ba-495f-980e-bd1d10e65279@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <GyUCcZ_aqPvyEo1rgZhoAR9Id-kP05FiOJZzLb8egZc=.643eb1cb-9025-4810-8ddd-20feb20fb837@github.com>
 <E9rBvKTfQM0tXyCAO7iTflK6oq1T4OIqn_rpRCy38rc=.68331f8f-74ba-495f-980e-bd1d10e65279@github.com>
Message-ID: <bV1691YOFI6Y_dTBBy5JwEduLJJfqGnL_mR6nAo1i84=.3d3fddbc-e1c3-43d4-b146-568263aace9c@github.com>

On Tue, 6 Dec 2022 18:45:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - check duplicate
>>  - Merge
>>  - Merge
>>  - Merge
>>  - add test cases
>>  - 8281236: (D)TLS key exchange algorithms
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 454:
> 
>> 452:     }
>> 453: 
>> 454:     static NamedGroup getPreferredGroup(
> 
> Add a comment describing what this method does. And the method on line 471.

Updated.

> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 279:
> 
>> 277:         String[] ngs = params.getNamedGroups();
>> 278:         if (ngs != null) {
>> 279:             // Note if 'ss' is empty, then no signature schemes should be
> 
> The comment needs to be updated for named groups. It looks like it was copied from line 272.

Thanks for the catch.  Updated.

> test/jdk/javax/net/ssl/SSLParameters/NamedGroups.java line 122:
> 
>> 120:                 null,
>> 121:                 false);
>> 122:         runTest(new String[0],
> 
> I think this case will throw IAE when `SSLParameter.setNamedGroups()` is called right? If so, I think you can delete this test (and the one one on line 123) since it is already covered in the NamedGroupsSpec test. Also, this test is coded such that the expected exception is thrown when the TLS handshake is being made in `runClientApplication()`, which is not the case here.
> 
> Same comment for the DTLSNamedGroups test.

It is allowed to set empty named groups with `SSLParameter.setNamedGroups()`, which means (see spec at `getNamedGroups`) that 


     * If the returned array is empty (zero-length), then the named group
     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
     * the connections may not be able to be established if the negotiation
     * mechanism is required by a certain SSL/TLS/DTLS protocol.


The TLS connection will fail, as expected, although for this case.

> test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8281236
>> 27:  * @summary (D)TLS key exchange named groups
> 
> Can you write a more specific summary of what this test is testing? The @summary doesn't have to match the bug title (and often should not IMO). 
> 
> Same comment for the other tests.

It makes senses to me.  Updated accordingly.

> test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 34:
> 
>> 32: public class NamedGroupsSpec {
>> 33:     public static void main(String[] args) throws Exception {
>> 34:         runTest(new String[] {
> 
> How about adding a test for a `null` array?

It is a good case that I missed.  Added.

> test/jdk/javax/net/ssl/SSLParameters/NamedGroupsSpec.java line 68:
> 
>> 66:         SSLParameters sslParams = new SSLParameters();
>> 67:         try {
>> 68:             sslParams.setNamedGroups(namedGroups);
> 
> You should also test that `getNamedGroups` returns the same elements.

Good point.  Added.  Thank you!

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

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

From alanb at openjdk.org  Wed Dec  7 07:09:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:09:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <3c0_fD_pzDxeZ6ikjh0LlCmtpI6JqY0OJyXeLvT694w=.bfe0d4ad-313c-4094-a526-d2d29902fa6b@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 153:

> 151: 
> 152:         WrappingReader(Reader r, Object lock) {
> 153:             this.r = r;

I think you need super(lock) here to ensure that the Reader uses the same lock.

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

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

From alanb at openjdk.org  Wed Dec  7 07:12:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:12:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <fQcZuAPbgcoiXN9XADjzVLxEaYP8u3TciMbkzsmH5xc=.c9c58b39-28d3-458a-b4f4-97065bcaef65@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 175:

> 173: 
> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
> 175:             super(pw);

PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

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

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

From mbaesken at openjdk.org  Wed Dec  7 08:45:01 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 08:45:01 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <by8PjHk056eNArwawtCAKY29CJNuEHDkGuDR3DeoeNE=.2c31ba49-5c88-477d-98a7-5b10dc51d702@github.com>
Message-ID: <kdOQP_mWI4xmIwFRQXP46G_ZZPUQLGVwFZQSmWL3T4k=.5c28947e-a124-4f62-a2db-87018f6a5830@github.com>

On Tue, 6 Dec 2022 20:40:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The existing code more obviously handles memory deallocation.

Thomas Stuefe suggested something like this


JNU_CHECK_EXCEPTION_DO(env, action)
JNU_CHECK_EXCEPTION_DO_AND_RETURN(env, action, retval)


usage example: 
`JNU_CHECK_EXCEPTION_DO(env, { free(tab); })`

This would make the free-ing more clear, and should also work for 2 free-calls, we a have places like this in the codebase. What do you think about this?

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

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

From sgehwolf at openjdk.org  Wed Dec  7 10:46:14 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Dec 2022 10:46:14 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v6]
In-Reply-To: <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
Message-ID: <ztebbLfX-2hyIPNtC8fIyyIboamoiJ2-YwEkGDEzzxU=.95c42c4e-0a6f-4209-9841-b13fa2ae05d8@github.com>

On Tue, 6 Dec 2022 17:48:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright.

Thanks for the review!

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

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

From sgehwolf at openjdk.org  Wed Dec  7 10:51:11 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Dec 2022 10:51:11 GMT
Subject: Integrated: 8298108: Add a regression test for JDK-8297684
In-Reply-To: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
Message-ID: <Q7zdT_Iek6543pQsL_05XmWIApB5BUUucC7Z6oI6dQQ=.0290b493-e2e8-4712-9c3c-c585f69abc9d@github.com>

On Mon, 5 Dec 2022 15:21:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
> 
> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.

This pull request has now been integrated.

Changeset: 4da84116
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4da8411674b7515310000bd8243860bc73f9a03d
Stats:     181 lines in 3 files changed: 181 ins; 0 del; 0 mod

8298108: Add a regression test for JDK-8297684

Reviewed-by: mullan

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

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

From alanb at openjdk.org  Wed Dec  7 11:58:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 11:58:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (Throwable ignore) {

I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

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

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

From duke at openjdk.org  Wed Dec  7 13:12:24 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 7 Dec 2022 13:12:24 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
Message-ID: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>

This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:

* refactors the class to only create one additional thread
* adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
* cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
* removes CipherSuite.java from ProblemList

Ran the following tests 200 times each with no failures.
* open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
* open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
* open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
* open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
* open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

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

Commit messages:
 - Merge branch 'master' into dtls
 - 8297798: Timeout with DTLSOverDatagram test template

Changes: https://git.openjdk.org/jdk/pull/11558/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297798
  Stats: 120 lines in 2 files changed: 38 ins; 47 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/11558.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11558/head:pull/11558

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

From mullan at openjdk.org  Wed Dec  7 14:12:26 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Dec 2022 14:12:26 GMT
Subject: RFR: 8298108: Add a regression test for JDK-8297684 [v6]
In-Reply-To: <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
References: <XekEeT3Umt1wDYmjjZ5Lt7L5tFseK8r58gRDe0HNH_4=.48b0863e-800c-4408-8b78-6cc1285af84b@github.com>
 <Th1_DpKnnMJBs15LxKv93oTZL_cJr3qupK1IPy8aeC8=.7765ce1b-3d16-45ef-a48d-2ebfc032dfc5@github.com>
Message-ID: <vDkXExOvz-0DT2aG-AvEel395ZHKhya7tkfLJ6scoK8=.49b56442-fbc8-4db1-814b-93fbd3af804f@github.com>

On Tue, 6 Dec 2022 17:48:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test addition as it would have helped discover a regression when https://bugs.openjdk.org/browse/JDK-8269039 got introduced and subsequently backported. What's more, it might help discover similar issues going forward. Thoughts?
>> 
>> Testing: Manually produced a build without [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039). Test fails without the fix, passes after.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright.

The fix has caused a regression on the Windows x64 platform and is affecting tier2 testing. I'll file a bug shortly. Here is a snippet from the log file:

 stderr: [Exception in thread "main" java.lang.RuntimeException: Test failed with signed jar and  argument java.locale.providers=SPI
	at TestSPISigned.doRunTest(TestSPISigned.java:115)
	at TestSPISigned.main(TestSPISigned.java:75)
Caused by: java.lang.RuntimeException: Expected calendar from SPI to be in effect: expected 4 to equal 1
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
	at TestSPISigned.check(TestSPISigned.java:121)
	at TestSPISigned.doRunTest(TestSPISigned.java:112)
	... 1 more

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

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

From sgehwolf at openjdk.org  Wed Dec  7 14:50:47 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Dec 2022 14:50:47 GMT
Subject: RFR: 8298274: Problem list TestSPISigned on Windows
Message-ID: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>

The test is failing on Windows. Problem list it until it can get properly analyzed and fixed.

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

Commit messages:
 - 8298274: Problem list TestSPISigned on Windows

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

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

From mullan at openjdk.org  Wed Dec  7 15:08:03 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Dec 2022 15:08:03 GMT
Subject: RFR: 8298274: Problem list TestSPISigned on Windows
In-Reply-To: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
References: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
Message-ID: <qRqlxkf8glYArj9MFlTowuoV9A_GzL0LHMf_8e7N8k8=.c9934ae8-1dd3-4aa3-a55c-b81b64e1ff27@github.com>

On Wed, 7 Dec 2022 14:41:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test is failing on Windows. Problem list it until it can get properly analyzed and fixed.

Marked as reviewed by mullan (Reviewer).

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

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

From mullan at openjdk.org  Wed Dec  7 15:26:08 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Dec 2022 15:26:08 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v5]
In-Reply-To: <BsjosBre2S8cBDfwmWz2AM7gydZfPecTfp7CQY711fI=.4793aaec-5dc7-43cd-ac70-e91867273084@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <BsjosBre2S8cBDfwmWz2AM7gydZfPecTfp7CQY711fI=.4793aaec-5dc7-43cd-ac70-e91867273084@github.com>
Message-ID: <uT4-kZBmSduHc-oMX8CgN4IOFINw-nq02vCHUKA8LxI=.af02bc9a-68ae-4e16-bc6e-ceb488fb4b56@github.com>

On Wed, 7 Dec 2022 06:56:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback update

I have fetched your branch and will run it thru the tier1 and tier2 tests before approving.

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

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

From dcubed at openjdk.org  Wed Dec  7 15:48:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Dec 2022 15:48:05 GMT
Subject: RFR: 8298274: Problem list TestSPISigned on Windows
In-Reply-To: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
References: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
Message-ID: <nhx4gmY-6JXnb_TcZhdLWKOZSwaoE-XCnLejBtUPjTk=.e7d40d46-b8ca-4779-880c-122497501b3a@github.com>

On Wed, 7 Dec 2022 14:41:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test is failing on Windows. Problem list it until it can get properly analyzed and fixed.

Thumbs up. This is a trivial fix.

Your ProblemList entry is properly formed. Please go ahead and integrate.

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

Marked as reviewed by dcubed (Reviewer).

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

From sgehwolf at openjdk.org  Wed Dec  7 15:48:05 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Dec 2022 15:48:05 GMT
Subject: RFR: 8298274: Problem list TestSPISigned on Windows
In-Reply-To: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
References: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
Message-ID: <Ejye4CZlPNGHHZi5_g_tjI8Ptm-DWbVS7hgr7qn2EIo=.298b51ee-3086-4fb8-8de4-6522faddb28a@github.com>

On Wed, 7 Dec 2022 14:41:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test is failing on Windows. Problem list it until it can get properly analyzed and fixed.

If somebody could test that the problem list entry works as expected on Windows, I'd appreciate it (I'm not touching those files much). Happy to integrate anytime, fwiw.

OK.

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

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

From sgehwolf at openjdk.org  Wed Dec  7 15:50:09 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 7 Dec 2022 15:50:09 GMT
Subject: Integrated: 8298274: Problem list TestSPISigned on Windows
In-Reply-To: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
References: <K9lNie7Hn4pgf4KvXNlM9EdUBe5vk1Ok4Tl8cqhlBtw=.77b235bd-7f64-42b4-b639-417bc955d275@github.com>
Message-ID: <ekaNE_N62FfmocX7wGCEbuZfKdjmtZNyk-zYPVnh0aM=.67e0a586-620e-4197-8a63-3745e3037aea@github.com>

On Wed, 7 Dec 2022 14:41:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test is failing on Windows. Problem list it until it can get properly analyzed and fixed.

This pull request has now been integrated.

Changeset: 29f1c3c6
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29f1c3c6e39170e0f36949dc209edf183c2eb36b
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8298274: Problem list TestSPISigned on Windows

Reviewed-by: mullan, dcubed

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

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

From rriggs at openjdk.org  Wed Dec  7 16:30:14 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Dec 2022 16:30:14 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg).  A single macro would suffice, instead of multiples.

Usage Example:

    JNU_CHECK_EXCEPTION_DO(env, { 
             free(tab); 
             return;
           })

Or put the invocation and return all on one line.

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

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

From stuefe at openjdk.org  Wed Dec  7 16:45:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 16:45:02 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <A1uT4hPZxgKW7wK02bmXt_NDnnUV-6coQ8Z1wtBKYjw=.10d27751-2aab-45c4-becf-974ed9f3e4fc@github.com>
Message-ID: <4zHedrkH9jgKyqCdI__dW2Ce31J6K28vyXSzv3LFONY=.397d9792-06b8-4642-a7cf-6a43c7609cc1@github.com>

On Wed, 7 Dec 2022 16:27:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> Good idea, though perhaps the return (and value if any) could be explicit in the macro invocation, instead of implicit (plus arg). A single macro would suffice, instead of multiples.
> 
> Usage Example:
> 
> ```
>     JNU_CHECK_EXCEPTION_DO(env, { 
>              free(tab); 
>              return;
>            })
> ```

Neat. I like that.

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

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

From naoto at openjdk.org  Wed Dec  7 17:09:53 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:53 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/40de5d0a..187f94fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=10-11

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

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

From naoto at openjdk.org  Wed Dec  7 17:09:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:56 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
 <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
Message-ID: <byXWsns6Ak-qqqiCaBka1snSKZd2Cov3tmuz3SBt1MA=.b6f6045a-eced-4a78-b279-fc3043082680@github.com>

On Wed, 7 Dec 2022 11:54:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Making the wrapper classes static
>
> src/java.base/share/classes/java/io/Console.java line 625:
> 
>> 623:             };
>> 624:             return AccessController.doPrivileged(pa);
>> 625:         } catch (Throwable ignore) {
> 
> I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

OK, reverted the catch clause.

> src/java.base/share/classes/java/io/ProxyingConsole.java line 175:
> 
>> 173: 
>> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
>> 175:             super(pw);
> 
> PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

Created a package private constructor just for `ProxyingConsole` to synchronize on the specified lock object.

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

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

From alanb at openjdk.org  Wed Dec  7 19:01:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 19:01:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
Message-ID: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>

On Wed, 7 Dec 2022 17:09:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/java/io/PrintWriter.java line 212:

> 210: 
> 211:     /* package private constructor specific to ProxyingConsole */
> 212:     PrintWriter(Writer out, Object lock) {

This constructor looks fine but maybe the comment should just say that it allows the lock object to be provided rather than mentioning ProxyingConsole here.

src/java.base/share/classes/java/io/ProxyingConsole.java line 167:

> 165:         @Override
> 166:         public void close() throws IOException {
> 167:             r.close();

Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

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

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

From mullan at openjdk.org  Wed Dec  7 19:05:25 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 Dec 2022 19:05:25 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v5]
In-Reply-To: <BsjosBre2S8cBDfwmWz2AM7gydZfPecTfp7CQY711fI=.4793aaec-5dc7-43cd-ac70-e91867273084@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <BsjosBre2S8cBDfwmWz2AM7gydZfPecTfp7CQY711fI=.4793aaec-5dc7-43cd-ac70-e91867273084@github.com>
Message-ID: <bTJ87Nef4co8dHXWfvBf65GjmEWzlQIBtCeURjDCrIU=.e2335533-bb70-4b4f-96e3-9e38e56e5a84@github.com>

On Wed, 7 Dec 2022 06:56:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback update

Test results are good.

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

Marked as reviewed by mullan (Reviewer).

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

From naoto at openjdk.org  Wed Dec  7 19:19:25 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:25 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Refined comments, no-op in WrappingReader/Writer::close()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/187f94fb..ef1a74f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=11-12

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

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

From naoto at openjdk.org  Wed Dec  7 19:19:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:28 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
 <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
Message-ID: <kelivy29sGYuTkG19cOovkBz3kai5Cn_lhOGyP86uIQ=.9cd94465-4eef-4bdf-b3dc-7992a5eceb59@github.com>

On Wed, 7 Dec 2022 18:57:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 167:
> 
>> 165:         @Override
>> 166:         public void close() throws IOException {
>> 167:             r.close();
> 
> Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

Right. Made them as no-op.

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

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

From xuelei at openjdk.org  Wed Dec  7 20:21:02 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 20:21:02 GMT
Subject: Integrated: 8281236: (D)TLS key exchange named groups
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <FflH131j9_tgo8DzO8DQWUwrQ7QFolBDqWwMK0xs_CU=.26ab85b0-0837-458b-b478-7122d96cff39@github.com>

On Fri, 5 Aug 2022 14:57:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

This pull request has now been integrated.

Changeset: 5d4c71c8
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d4c71c8bd361af78c90777f17b79e95d8eb5afe
Stats:     1001 lines in 17 files changed: 765 ins; 195 del; 41 mod

8281236: (D)TLS key exchange named groups

Reviewed-by: mullan

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

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

From alanb at openjdk.org  Wed Dec  7 20:32:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 20:32:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
Message-ID: <Eqp_Y4HRUt6x1S881hkgco_Fa-uu54vmlsFNjOQU8T4=.1af56400-2f72-49b6-9edd-b85b7371e2c0@github.com>

On Wed, 7 Dec 2022 19:19:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined comments, no-op in WrappingReader/Writer::close()

Marked as reviewed by alanb (Reviewer).

Thanks for the updates, I don't have any more comments. I think should create a follow-up issue to "hollow out" Console and have two separate implementations/subclasses. I think that would make it much cleaner rather than one implementation extending the other as we have now.

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

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

From rhalade at openjdk.org  Wed Dec  7 20:36:02 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 7 Dec 2022 20:36:02 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <UUDllSgIjWxF-dYqkhUOwQNI0RB5gYl2cdjy5bVM8Lk=.00a151aa-00a3-48b0-a320-b506b1333917@github.com>

On Wed, 7 Dec 2022 13:04:28 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

Since this fix will address intermittent failures from these 5 tests, can we close those 5 bugs as duplicate of this fix?

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

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

From naoto at openjdk.org  Wed Dec  7 20:52:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 20:52:14 GMT
Subject: Integrated: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <bOnY-BRcoxyu7BXfC2PxL1Jg_7Fr3LzHoDwobCMf73I=.c16e77bf-b085-4006-8e32-da26783ee5c4@github.com>

On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: 8a9911ef
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a9911ef1762ae837e427ec9d91b1399ba33b6e4
Stats:     684 lines in 17 files changed: 661 ins; 11 del; 12 mod

8295803: Console should be usable in jshell and other environments

Reviewed-by: jlaskey, alanb

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

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

From bylokhov at amazon.com  Wed Dec  7 21:00:55 2022
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Wed, 7 Dec 2022 13:00:55 -0800
Subject: The question about 8211018: Session Resumption without Server-Side
 State
Message-ID: <193aa4ad-4029-ec67-f10f-6d4499d9fc96@amazon.com>

Hello, Security team.

Right now I am working on some issues related to the sslContext and would like to clarify a few 
questions about how the feature implemented by the JDK-8211018 is intended to work.
That feature is mostly implemented by this class:
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java

Here is some questions about thread safeness of this code:

  - The SessionTicketExtension class uses the currentKeyID to track the currently used keyID.
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L77
    * Note that the field is static and could be shared across the threads. There is even a 
synchronization block in place where we increment the key:
 
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L175
    * It seems wrong that it is synchronized on the "hc.sslContext.keyHashMap" since the static key 
can be shared across the different sslcontext's?
    * In another place the synchronization is not used at all:
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L158
    * Probably the intention was to use one currentKeyID per sslcontext?


  - The hashmap to store the keys are located in the SSLContextImpl class:
https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L74
  * It seems that the usage of this map is not synchronized at all, does it mean that it cannot be 
used across the threads? -> And it is expected that one SSLContextImpl is created per thread?


  - If the hashmap above can be used across the threads, then the code for "clean" the expired keys 
is unclear: 
https://github.com/openjdk/jdk/commit/94e1d7530ff03978be305211f6a1e6d14acb6d1c#diff-8eeef23d966ed2ebe6ecf02d16e549b8cef94f54bb17f6c9ac8d8dc151eed8fcR197
============
     // Clean up any old keys, then return the current key
     cleanup(hc);
     return ssk;
============
   Note that it is executed outside of the synchronized block, is that right?

  - Another question is about using "SessionTicketExtension#getCurrentKey+cleanup" on a different 
threads. I think it is possible to get the next situation:
    1. Thread1 call getCurrentKey() and return the key which is mostly ready to expire, but valid 
for now, This key started to be used  by the SessionTicketSpec#encrypt
    2. Thread2 calls getCurrentKey() and creates a new key, then call "cleanup" and destroys the key 
used by Thread1, since it is expired now.
    3. Thread1 is in trouble.


Note that the specification does not have any hints about how the code in question should work 
concurrently.

-- 
Best regards, Sergey.

From pminborg at openjdk.org  Wed Dec  7 22:04:11 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Dec 2022 22:04:11 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
Message-ID: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>

This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434

The PRs contains changes for several sub-components.

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

Commit messages:
 - Rename session to scope

Changes: https://git.openjdk.org/jdk/pull/11573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298277
  Stats: 2783 lines in 98 files changed: 954 ins; 955 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/11573.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573

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

From jvernee at openjdk.org  Wed Dec  7 23:00:08 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Dec 2022 23:00:08 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <NVww6vH-lGykHhFN-FTkh9qJISEpm-_UZK0Khnyszuo=.b3b3f542-7851-4fae-a645-20851c129ad8@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

src/java.base/share/classes/jdk/internal/foreign/MemoryScopeImpl.java line 53:

> 51:  * access is possible when a scope is being closed (see {@link jdk.internal.misc.ScopedMemoryAccess}).
> 52:  */
> 53: public abstract sealed class MemoryScopeImpl

Since the interface is called `SegmentScope`, I think `SegmentScopeImpl` would be a better name here.

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

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

From mcimadamore at openjdk.org  Wed Dec  7 23:37:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Dec 2022 23:37:03 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <LQIRMsp-_xSIkyeIrGgVgumF0jv08Kloq_24W5l0PF4=.e6ccb023-35e0-4bc4-ac67-f2f42fb8b076@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

I think we should split this PR into multiple parts:
* there are some good javadoc changes in here to the Vector API docs
* there are some test changes, where some of the names are out of date
* the majority of changes, which is caused by MemorySessionImpl -> MemoryScopeImpl is the part I'm less sure about. I think leaving that as is might be fine for now.

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

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

From pminborg at openjdk.org  Thu Dec  8 08:17:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 08:17:44 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert renaming of MemorySessionImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11573/files
  - new: https://git.openjdk.org/jdk/pull/11573/files/71a5e29c..39f09aa0

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

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

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

From duke at openjdk.org  Thu Dec  8 12:57:01 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 8 Dec 2022 12:57:01 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <UUDllSgIjWxF-dYqkhUOwQNI0RB5gYl2cdjy5bVM8Lk=.00a151aa-00a3-48b0-a320-b506b1333917@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <UUDllSgIjWxF-dYqkhUOwQNI0RB5gYl2cdjy5bVM8Lk=.00a151aa-00a3-48b0-a320-b506b1333917@github.com>
Message-ID: <yV66liwzdox3iFNX27L7HZq70TcuYgXr0wIFrw7yVH8=.bb71a1be-b2c8-4341-a730-32079a055449@github.com>

On Wed, 7 Dec 2022 20:34:00 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Since this fix will address intermittent failures from these 5 tests, can we close those 5 bugs as duplicate of this fix?

I'm not completely comfortable marking them as duplicate because there are a few different errors going on and I wasn't able to reproduce them. Can we mark mark them as "cannot reproduce" and include a link to this fix?

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

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

From pminborg at openjdk.org  Thu Dec  8 13:05:00 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:00 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
 <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
Message-ID: <RlgO9nlJZIXTZ4fz3RsmY31lFV-y2rgtA32PCV-pg7E=.0ce4621b-b503-4c5a-bc4d-3e7faeacdf3d@github.com>

On Thu, 8 Dec 2022 08:17:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
>> 
>> The PRs contains changes for several sub-components.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert renaming of MemorySessionImpl

I am going to close this PR in favor of several other smaller ones.

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

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

From pminborg at openjdk.org  Thu Dec  8 13:05:03 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:03 GMT
Subject: Withdrawn: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <0LEwHE6mc-JRS1H07g0SE-jUVPFapFVFxJrreAT8EJI=.a3ed1f57-6126-4324-97c8-86d69f2b67d6@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

This pull request has been closed without being integrated.

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

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

From volker.simonis at gmail.com  Thu Dec  8 13:13:10 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 8 Dec 2022 14:13:10 +0100
Subject: The question about 8211018: Session Resumption without
 Server-Side State
In-Reply-To: <193aa4ad-4029-ec67-f10f-6d4499d9fc96@amazon.com>
References: <193aa4ad-4029-ec67-f10f-6d4499d9fc96@amazon.com>
Message-ID: <CA+3eh13wfm3FWHxsAkQpfT8-K4-o_nXPDbRJFnaDQUzC-oU1_Q@mail.gmail.com>

Hi Sergey,

Thanks for starting this discussion. I've opened "8298381: Improve
handling of session tickets for multiple SSLContexts" [1] to track
this issue and submitted a pull request with a potential fix [2].
Let's continue the discussion there if you don't mind :)

Best regards,
Volker

[1] https://bugs.openjdk.org/browse/JDK-8298381
[2] https://github.com/openjdk/jdk/pull/11590

On Wed, Dec 7, 2022 at 10:01 PM Sergey Bylokhov <bylokhov at amazon.com> wrote:
>
> Hello, Security team.
>
> Right now I am working on some issues related to the sslContext and would like to clarify a few
> questions about how the feature implemented by the JDK-8211018 is intended to work.
> That feature is mostly implemented by this class:
> https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java
>
> Here is some questions about thread safeness of this code:
>
>   - The SessionTicketExtension class uses the currentKeyID to track the currently used keyID.
> https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L77
>     * Note that the field is static and could be shared across the threads. There is even a
> synchronization block in place where we increment the key:
>
> https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L175
>     * It seems wrong that it is synchronized on the "hc.sslContext.keyHashMap" since the static key
> can be shared across the different sslcontext's?
>     * In another place the synchronization is not used at all:
> https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java#L158
>     * Probably the intention was to use one currentKeyID per sslcontext?
>
>
>   - The hashmap to store the keys are located in the SSLContextImpl class:
> https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L74
>   * It seems that the usage of this map is not synchronized at all, does it mean that it cannot be
> used across the threads? -> And it is expected that one SSLContextImpl is created per thread?
>
>
>   - If the hashmap above can be used across the threads, then the code for "clean" the expired keys
> is unclear:
> https://github.com/openjdk/jdk/commit/94e1d7530ff03978be305211f6a1e6d14acb6d1c#diff-8eeef23d966ed2ebe6ecf02d16e549b8cef94f54bb17f6c9ac8d8dc151eed8fcR197
> ============
>      // Clean up any old keys, then return the current key
>      cleanup(hc);
>      return ssk;
> ============
>    Note that it is executed outside of the synchronized block, is that right?
>
>   - Another question is about using "SessionTicketExtension#getCurrentKey+cleanup" on a different
> threads. I think it is possible to get the next situation:
>     1. Thread1 call getCurrentKey() and return the key which is mostly ready to expire, but valid
> for now, This key started to be used  by the SessionTicketSpec#encrypt
>     2. Thread2 calls getCurrentKey() and creates a new key, then call "cleanup" and destroys the key
> used by Thread1, since it is expired now.
>     3. Thread1 is in trouble.
>
>
> Note that the specification does not have any hints about how the code in question should work
> concurrently.
>
> --
> Best regards, Sergey.

From simonis at openjdk.org  Thu Dec  8 13:17:41 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 8 Dec 2022 13:17:41 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
Message-ID: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>

Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.

This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.

Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.

I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.

The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:

$ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)

The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:

java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
  11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)

With my proposed patch, the numbers goes back to two instances again:

java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
  11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)


I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

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

Commit messages:
 - 8298381: Improve handling of session tickets for multiple SSLContexts

Changes: https://git.openjdk.org/jdk/pull/11590/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298381
  Stats: 123 lines in 2 files changed: 54 ins; 58 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11590.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11590/head:pull/11590

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

From aph at openjdk.org  Thu Dec  8 18:27:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 Dec 2022 18:27:07 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v7]
In-Reply-To: <H-MJAIiIpHn61RJYdbDv62AKdnDivsD2n6-QKWC2WVk=.f7e5a246-b3ca-400f-9320-9a110c1946d3@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <H-MJAIiIpHn61RJYdbDv62AKdnDivsD2n6-QKWC2WVk=.f7e5a246-b3ca-400f-9320-9a110c1946d3@github.com>
Message-ID: <IBKgPxGQkWQebD28OBGrThDp5e7aPcBg16WqccjN9Fs=.e2e212dd-f1b1-4848-a535-0bc4b45824c0@github.com>

On Tue, 6 Dec 2022 20:29:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I would like a review of an update to the GCM code.  A recent report showed that GCM memory usage for TLS was very large.  This was a result of in-place buffers, which TLS uses, and how the code handled the combined intrinsic method during decryption.  A temporary buffer was used because the combined intrinsic does gctr before ghash which results in a bad tag.  The fix is to not use the combined intrinsic during in-place decryption and depend on the individual GHASH and CounterMode intrinsics.  Direct ByteBuffers are not affected as they are not used by the intrinsics directly.
>> 
>> The reduction in the memory usage boosted performance back to where it was before despite using slower intrinsics (gctr & ghash individually).  The extra memory allocation for the temporary buffer out-weighted the faster intrinsic.
>> 
>> 
>>     JDK 17:   122913.554 ops/sec
>>     JDK 19:    94885.008 ops/sec
>>     Post fix: 122735.804 ops/sec 
>> 
>> There is no regression test because this is a memory change and test coverage already existing.
>
> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - editor screwed up
>  - why won't this merge hell stop 2
>  - why won't this merge hell stop 3

What benchmark was this? How large were the buffers?

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

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

From duke at openjdk.org  Thu Dec  8 18:36:57 2022
From: duke at openjdk.org (Carter Kozak)
Date: Thu, 8 Dec 2022 18:36:57 GMT
Subject: RFR: 8296507: GCM using more memory than necessary with in-place
 operations [v7]
In-Reply-To: <IBKgPxGQkWQebD28OBGrThDp5e7aPcBg16WqccjN9Fs=.e2e212dd-f1b1-4848-a535-0bc4b45824c0@github.com>
References: <nlpbkFlgSEShntUnwuaFwd5YJl1xP3qDWnTmv_tlvYU=.771dc143-3936-4019-bb0c-270e2316e519@github.com>
 <H-MJAIiIpHn61RJYdbDv62AKdnDivsD2n6-QKWC2WVk=.f7e5a246-b3ca-400f-9320-9a110c1946d3@github.com>
 <IBKgPxGQkWQebD28OBGrThDp5e7aPcBg16WqccjN9Fs=.e2e212dd-f1b1-4848-a535-0bc4b45824c0@github.com>
Message-ID: <zOrnUijJQ4VcDs_JLV9B0MiprPN5YSVKcO8JHHtMgIk=.e750fa36-f98c-4c58-b037-fd0048adc93b@github.com>

On Thu, 8 Dec 2022 18:24:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - editor screwed up
>>  - why won't this merge hell stop 2
>>  - why won't this merge hell stop 3
>
> What benchmark was this? How large were the buffers?

@theRealAph I reported this oddity [to the mailing list](https://mail.openjdk.org/pipermail/security-dev/2022-October/032723.html) including [a benchmark](https://github.com/carterkozak/java-crypto-allocation-performance#java-cryptography-allocations) which I later updated to include additional coverage for [direct buffers](https://github.com/carterkozak/java-crypto-allocation-performance/blob/develop/java-crypto-allocation-performance/src/main/java/com/palantir/java/crypto/allocations/DirectBufferTransportLayerSecurityBenchmark.java)

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

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

From serb at openjdk.org  Thu Dec  8 18:54:44 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 18:54:44 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>

On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

I have asked some of the next questions already [here](https://mail.openjdk.org/pipermail/security-dev/2022-December/033797.html). Would like to mention some of them here;
 * The main question I have: is it safe to assume that the [SSLContextImpl](https://github.com/openjdk/jdk/pull/11590/files#diff-fc40f443cd9d2236d4279b83e6b6e662771d08faa571851f9de3de4925a2c36c) can be shared across the threads? If yes, it seems it lacks synchronization here and there. Like this patch added a synchronization around getNextKey/cleanup/destroy methods but it does not prevent usage of the key after creation and destroying it by different threads.
 * Is it safe to have duplicated currentKeyID per ssl context and use that during encryption/description as part of the "Additional Authentication Data"?

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

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

From rhalade at openjdk.org  Thu Dec  8 19:19:19 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Dec 2022 19:19:19 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <-4y7PE5DCR0p5d9-aW-9t4k6LE7rmUQuUArDZoioidI=.a08e1f68-6952-4659-b998-47b0396975d1@github.com>

On Wed, 7 Dec 2022 13:04:28 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 331:

> 329:     }
> 330: 
> 331:     /*

minor: fix comment formatting

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

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

From serb at openjdk.org  Thu Dec  8 19:21:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Dec 2022 19:21:49 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <c99qsxATv1AKtdaYSwMP-6P3eh7pd439_nnNB0ufRpI=.ef83da6a-e4dc-4045-9eb7-20e5dacf2da0@github.com>

On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 97:

> 95:         keyHashMap.put(Integer.valueOf(newID), key);
> 96:         currentKeyID = newID;
> 97:         cleanupSessionKeys();

Does synchronization on sslContext around cleanupSessionKeys is needed? It will block all threads which will try to get the new key, and it seems does not make it safe since the ConcurrentHashMap is used now.

src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 187:

> 185:                 } else {
> 186:                     newNum = currentKeyID + 1;
> 187:                 }

Any idea why the code used zero after MAX_VALUE before?

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

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

From rhalade at openjdk.org  Thu Dec  8 19:25:32 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Dec 2022 19:25:32 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <97H04LrIrFpldAzwKmGK0RkqOAG7XsjNG2-EQO9Up6g=.faffaebb-49b5-4b9f-acb7-4fcba58bf61d@github.com>

On Wed, 7 Dec 2022 13:04:28 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 560:

> 558:             } catch (Exception exc) {
> 559:                 System.out.println("Exception on client side: ");
> 560:                 exc.printStackTrace(System.out);

can we log these stack traces to System.err?

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 591:

> 589: 
> 590:             if (testCase.isGoodJob()) {
> 591:                 throw e;

Why is this flipped, earlier if isGoodJob() returns false then we throw exception.

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

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

From rhalade at openjdk.org  Thu Dec  8 19:35:55 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Dec 2022 19:35:55 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <C_noub5rpiVWk8rATnM4Y3DbEUkXqGd4dYBulJIJdkQ=.7054494c-e8c8-4fc5-bca2-a870066e6be6@github.com>

On Wed, 7 Dec 2022 13:04:28 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 617:

> 615:             clientException = e;
> 616: 
> 617:             if (testCase.isGoodJob()) {

Same here. Check if this is method is even used and what is the purpose of it. You may not need these checks and would prefer to have no try-catch in this method.

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

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

From naoto at openjdk.org  Thu Dec  8 19:41:18 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Dec 2022 19:41:18 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
 <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
Message-ID: <AoYsTXNvcGUUV_rDTPHUFJScUsjqqctuHp2Wa2l7770=.dcb7f0a9-1403-400f-a9a8-49c07cd129f8@github.com>

On Tue, 6 Dec 2022 18:10:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 99:
>> 
>>> 97:  */
>>> 98: 
>>> 99: public class Console implements Flushable
>> 
>> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?
>
> Right. Will address it after this PR.

Filed: https://bugs.openjdk.org/browse/JDK-8298416

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

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

From rhalade at openjdk.org  Thu Dec  8 19:42:22 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Dec 2022 19:42:22 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <C_noub5rpiVWk8rATnM4Y3DbEUkXqGd4dYBulJIJdkQ=.7054494c-e8c8-4fc5-bca2-a870066e6be6@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <C_noub5rpiVWk8rATnM4Y3DbEUkXqGd4dYBulJIJdkQ=.7054494c-e8c8-4fc5-bca2-a870066e6be6@github.com>
Message-ID: <XqyY1BvOLVTKnULb3m96SVhm5KJN33JmiMGwCbMfjhA=.18bee353-33f2-4906-ba87-3276845b5825@github.com>

On Thu, 8 Dec 2022 19:33:09 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
>> 
>> * refactors the class to only create one additional thread
>> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
>> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
>> * removes CipherSuite.java from ProblemList
>> 
>> Ran the following tests 200 times each with no failures.
>> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
>> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
>> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
>> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
>> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java
>
> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 617:
> 
>> 615:             clientException = e;
>> 616: 
>> 617:             if (testCase.isGoodJob()) {
> 
> Same here. Check if this is method is even used and what is the purpose of it. You may not need these checks and would prefer to have no try-catch in this method.

It is used by InvalidRecords.java test. It expects handshake to fail so overrides this method.

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

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

From rhalade at openjdk.org  Thu Dec  8 19:47:41 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 Dec 2022 19:47:41 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <yV66liwzdox3iFNX27L7HZq70TcuYgXr0wIFrw7yVH8=.bb71a1be-b2c8-4341-a730-32079a055449@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <UUDllSgIjWxF-dYqkhUOwQNI0RB5gYl2cdjy5bVM8Lk=.00a151aa-00a3-48b0-a320-b506b1333917@github.com>
 <yV66liwzdox3iFNX27L7HZq70TcuYgXr0wIFrw7yVH8=.bb71a1be-b2c8-4341-a730-32079a055449@github.com>
Message-ID: <tVq3n85ePVtQ9_5r6xuHO8Vf6vBoTd6l5lWFaQhi-u8=.25d56177-8f3a-4889-8579-d86cd37dc438@github.com>

On Thu, 8 Dec 2022 12:54:30 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> I'm not completely comfortable marking them as duplicate because there are a few different errors going on and I wasn't able to reproduce them. Can we mark mark them as "cannot reproduce" and include a link to this fix?

Since all of those related bugs were for timeout, I am fine to close them as duplicate. But no objection to "cannot reproduce" as well.

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

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

From djelinski at openjdk.org  Fri Dec  9 06:55:42 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 9 Dec 2022 06:55:42 GMT
Subject: RFR: 8298249: Excessive memory allocation in CipherInputStream AEAD
 decryption
Message-ID: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>

This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.

`Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.

This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.

As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.

There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.

The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.

Benchmark results before:

Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s


After:

Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

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

Commit messages:
 - Add benchmark
 - Speed up CipherInputStream on AEAD decryption

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

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

From sgehwolf at openjdk.org  Fri Dec  9 10:30:07 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 9 Dec 2022 10:30:07 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
Message-ID: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>

The test introduced with [JDK-8298108](https://bugs.openjdk.org/browse/JDK-8298108) failed on Windows apparently due to a non-portable use of `path.separator` in the test.

@seanjmullan was kind enough to test this change, which fixes the issue on Windows.

Thus, remove the test from the `ProblemList.txt` as the test now works on that platform as well. Thoughts?

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

Commit messages:
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows

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

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

From mbaesken at openjdk.org  Fri Dec  9 12:27:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Dec 2022 12:27:00 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

Hi Roger , the new proposed version  JNU_CHECK_EXCEPTION_DO  is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

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

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

From rriggs at openjdk.org  Fri Dec  9 14:43:49 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Dec 2022 14:43:49 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
 <_mmRgqh9oP4GNFQEsIHjRtYwzMekhI5GTq8b8URghEE=.540c993a-fa4e-4c8e-8f6c-5372e0c74d42@github.com>
Message-ID: <YPj1ap6tA4UlYcuTzF7tfm1pqNC-03nnqR3Jaj-kEVY=.d7e1798a-0c84-4d8e-acb5-dff6f4d070da@github.com>

On Fri, 9 Dec 2022 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Roger , the new proposed version JNU_CHECK_EXCEPTION_DO is now almost as lengthy as the original coding, Is it really worth it introducing a macro when it gets so lengthy ?

Its easier to understand the flow and cleanup being done if its visible in the source. 
I (or new readers) don't have to go unwrap the macro to know what's going to happen.

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

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

From mullan at openjdk.org  Fri Dec  9 15:24:57 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 Dec 2022 15:24:57 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
Message-ID: <sBoQYJj-vyBTW6Rd0c5fjeAcIYm1UYb0At_2ShUNQgw=.fb876aa7-995b-4f90-b72d-df6b50913dc3@github.com>

On Fri, 9 Dec 2022 10:18:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test introduced with [JDK-8298108](https://bugs.openjdk.org/browse/JDK-8298108) failed on Windows apparently due to a non-portable use of `path.separator` in the test.
> 
> @seanjmullan was kind enough to test this change, which fixes the issue on Windows.
> 
> Thus, remove the test from the `ProblemList.txt` as the test now works on that platform as well. Thoughts?

I tested the fix on all platforms and it passed. This is probably also worth fixing in JDK 20 to get it off the ProblemList.

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

Marked as reviewed by mullan (Reviewer).

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

From sgehwolf at openjdk.org  Fri Dec  9 16:17:52 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 9 Dec 2022 16:17:52 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <sBoQYJj-vyBTW6Rd0c5fjeAcIYm1UYb0At_2ShUNQgw=.fb876aa7-995b-4f90-b72d-df6b50913dc3@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
 <sBoQYJj-vyBTW6Rd0c5fjeAcIYm1UYb0At_2ShUNQgw=.fb876aa7-995b-4f90-b72d-df6b50913dc3@github.com>
Message-ID: <_BArh9AOlpz6RHTo4X9PeQU3qYIXrsyE55ErozzmFqg=.b372a0c8-7e6e-4f37-b84e-47be0a85172c@github.com>

On Fri, 9 Dec 2022 15:22:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I tested the fix on all platforms and it passed. This is probably also worth fixing in JDK 20 to get it off the ProblemList.

Thanks for the review! What does fixing in `JDK 20` mean at this stage? File a PR against https://github.com/openjdk/jdk20 instead?

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

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

From mullan at openjdk.org  Fri Dec  9 20:23:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 Dec 2022 20:23:47 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <_BArh9AOlpz6RHTo4X9PeQU3qYIXrsyE55ErozzmFqg=.b372a0c8-7e6e-4f37-b84e-47be0a85172c@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
 <sBoQYJj-vyBTW6Rd0c5fjeAcIYm1UYb0At_2ShUNQgw=.fb876aa7-995b-4f90-b72d-df6b50913dc3@github.com>
 <_BArh9AOlpz6RHTo4X9PeQU3qYIXrsyE55ErozzmFqg=.b372a0c8-7e6e-4f37-b84e-47be0a85172c@github.com>
Message-ID: <sG0UTKajvFye628E9s5xOHgDw4IOruUuD3Z1SyAUxik=.d86b134c-911d-4db8-aa66-4f02ebdae395@github.com>

On Fri, 9 Dec 2022 16:15:34 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > I tested the fix on all platforms and it passed. This is probably also worth fixing in JDK 20 to get it off the ProblemList.
> 
> Thanks for the review! What does fixing in `JDK 20` mean at this stage? File a PR against https://github.com/openjdk/jdk20 instead?

Yes, and you can use the skara backport command to make this easier. See https://openjdk.org/guide/#using-the-skara-tooling-to-help-with-backports

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

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

From simonis at openjdk.org  Sun Dec 11 16:33:27 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Sun, 11 Dec 2022 16:33:27 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>
Message-ID: <ztLjjE6Q6bifURYOxq0BweQF5KNjVWw3UsrhV5kKwJc=.3c52deb3-5331-4452-bee5-05ebab535500@github.com>

On Thu, 8 Dec 2022 18:52:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have asked some of the next questions already [here](https://mail.openjdk.org/pipermail/security-dev/2022-December/033797.html). Would like to mention some of them;
> 
>     * The main question I have: is it safe to assume that the [SSLContextImpl](https://github.com/openjdk/jdk/pull/11590/files#diff-fc40f443cd9d2236d4279b83e6b6e662771d08faa571851f9de3de4925a2c36c) can be shared across the threads? 

I can't answer this for sure but at least I haven't found any documentation which would prevent multi-threaded usage. On the other hand, `SSLContextImpl` contains the following implementation note:

 * Implementation note: Instances of this class and the child classes are
 * immutable, except that the context initialization (SSLContext.init()) may
 * reset the key, trust managers and source of secure random.

So this comment will probably have to be removed once we move the session ticket key (i.e. `currentKeyID`) into this class. But the session key hash map has already lived in `SSLContextImpl` before, so the claim has already been violated.

> *..If yes, it seems it lacks synchronization here and there. Like this patch added a synchronization around getNextKey/cleanup/destroy methods but it does not prevent usage of the key after creation and destroying it by different threads.

You're right, but that's actually an improvement compared to the initial implementation where cleanup/destroy wasn't synchronized at all :)

With regards to the missing synchronization of key usage and key destruction, I think this patch doesn't change the existing behavior because it wasn't synchronized before either. On the other hand, this patch fixes the implementation such that it only creates new tickets every hour (i.e. `jdk.tls.server.statelessKeyTimeout`) per context by default. This means that each `keyHashMap` should not contain more than 24 valid session keys by default (i.e. `jdk.tls.server.sessionTicketTimeout`/`jdk.tls.server.statelessKeyTimeout`) and cleanup should be called at most once per hour. Even if a session key which is in use will be destroyed, the worst case consequence would be that the verification of a corresponding session ticket could fail. But that is not critical because the SSL handshake would just fail and fall back to full session renegotiation in that case. 

>     * Is it safe to have duplicated currentKeyID per ssl context and use that during encryption/description as part of the "Additional Authentication Data"?

With this change there will be no duplicate key IDs per context, only different contexts might eventually use the same session key (i.e. `currentKeyID`). But that should still be quite rare, because they both start from a different random number. And even if it happens, I don't see a problem with it. According to [RFC 5077](https://www.rfc-editor.org/rfc/rfc5077), the key ID is an opaque data structure which is transmitted in plain text. It is only used by the server to identify the correct private key for decrypting the clients session ticket. It's up to the application to make sure that clients with session tickets will connect to the correct context which is capable of decrypting the ticket. Notice, that this was already the case in the original implementation where different contexts had different key IDs but still every context could only decrypt session tickets with keys it had issued before. I think "[JDK-8250965: Distributed TLS sessions implementation](https://bugs.openjdk.o
 rg/browse/JDK-8250965)" is an attempt to solve this problem more generally.

> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 187:
> 
>> 185:                 } else {
>> 186:                     newNum = currentKeyID + 1;
>> 187:                 }
> 
> Any idea why the code used zero after MAX_VALUE before?

I have no clue, but as the keys can be initially negative anyway (i.e. if `SecureRandom().nextInt()` returns a negative number), I don't see a reason to restrict them to positive values after they wrap around.

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

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

From xuelei at openjdk.org  Sun Dec 11 20:40:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sun, 11 Dec 2022 20:40:39 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>

On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

> The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:

That's obviously not the expected behaviors.  It is a good catch for the `static currentKeyID` issue.

What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`?  I would like to have SSLContextImpl focusing on configuration.

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

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

From serb at openjdk.org  Sun Dec 11 23:54:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 11 Dec 2022 23:54:52 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <ztLjjE6Q6bifURYOxq0BweQF5KNjVWw3UsrhV5kKwJc=.3c52deb3-5331-4452-bee5-05ebab535500@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>
 <ztLjjE6Q6bifURYOxq0BweQF5KNjVWw3UsrhV5kKwJc=.3c52deb3-5331-4452-bee5-05ebab535500@github.com>
Message-ID: <aoKrIJMhr4QWZDSmPxDCa_9-5aqvL0vFBsGvE6wCAuA=.03d45e7c-400b-4c2d-aaeb-7122c8939b70@github.com>

On Sun, 11 Dec 2022 16:28:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> You're right, but that's actually an improvement compared to the initial implementation where cleanup/destroy wasn't synchronized at all :)
> With regards to the missing synchronization of key usage and key destruction, I think this patch doesn't change the existing behavior because it wasn't synchronized before either.

I think behavior is changed, since the synchronization problem was hidden by generation of many keys. And if we start to use one key by many threads, we will need to carefully sync it, but if we just add synchronization per ssl contex we will make encode/decode methods single threaded per ssl context, which is unfortunate.

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

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

From sgehwolf at openjdk.org  Mon Dec 12 09:45:13 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 09:45:13 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <sG0UTKajvFye628E9s5xOHgDw4IOruUuD3Z1SyAUxik=.d86b134c-911d-4db8-aa66-4f02ebdae395@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
 <sBoQYJj-vyBTW6Rd0c5fjeAcIYm1UYb0At_2ShUNQgw=.fb876aa7-995b-4f90-b72d-df6b50913dc3@github.com>
 <_BArh9AOlpz6RHTo4X9PeQU3qYIXrsyE55ErozzmFqg=.b372a0c8-7e6e-4f37-b84e-47be0a85172c@github.com>
 <sG0UTKajvFye628E9s5xOHgDw4IOruUuD3Z1SyAUxik=.d86b134c-911d-4db8-aa66-4f02ebdae395@github.com>
Message-ID: <A8wGQ3TawzXo6pIOgx4nVj8LB9M7bG0P3axljDYSNoA=.9eb02871-30b7-4f40-984e-e4310d55288d@github.com>

On Fri, 9 Dec 2022 20:21:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > I tested the fix on all platforms and it passed. This is probably also worth fixing in JDK 20 to get it off the ProblemList.
> > 
> > 
> > Thanks for the review! What does fixing in `JDK 20` mean at this stage? File a PR against https://github.com/openjdk/jdk20 instead?
> 
> Yes, and you can use the skara backport command to make this easier. See https://openjdk.org/guide/#using-the-skara-tooling-to-help-with-backports

Now I'm confused. Aren't changes done to `jdk20` automatically merged to the JDK 21 (jdk head) tree? Why would I use backport tooling. Or are you suggesting to integrate this and then backport to the `jdk20` tree?

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

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

From simonis at openjdk.org  Mon Dec 12 09:59:32 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 12 Dec 2022 09:59:32 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
Message-ID: <wY_IzuqZgccW6c-zE8DCNK0xP2WlOtKWh5TM_o2Qy44=.f5526947-515f-4152-82d1-a1affde8de57@github.com>

On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:
> 
> That's obviously not the expected behaviors. It is a good catch for the `static currentKeyID` issue.
> 
> What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`? I would like to have SSLContextImpl focusing on configuration.

Do you propose to only move `SSLContextImpl.keyHashMap`, or both `SSLContextImpl.keyHashMap` and `SSLContextImpl.currentKeyID` or `SSLContextImpl.keyHashMap`, `SSLContextImpl.currentKeyID` and all the corresponding accessor methods (i.e. `addSessionKey()`, `cleanupSessionKeys()`, `getKey()` and `getID()`) into `SSLSessionContextImpl`?

Also, I assume you'd probably like to keep it in `SSLContextImpl.serverCache` rather then `SSLContextImpl.clinetCache`, right?

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

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

From simonis at openjdk.org  Mon Dec 12 10:08:56 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 12 Dec 2022 10:08:56 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <aoKrIJMhr4QWZDSmPxDCa_9-5aqvL0vFBsGvE6wCAuA=.03d45e7c-400b-4c2d-aaeb-7122c8939b70@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>
 <ztLjjE6Q6bifURYOxq0BweQF5KNjVWw3UsrhV5kKwJc=.3c52deb3-5331-4452-bee5-05ebab535500@github.com>
 <aoKrIJMhr4QWZDSmPxDCa_9-5aqvL0vFBsGvE6wCAuA=.03d45e7c-400b-4c2d-aaeb-7122c8939b70@github.com>
Message-ID: <m43XYvDFFJhwz7UlMSj4cPPdqLMYCiLiG3dsqak9dCg=.a73e7e1a-591f-4146-a42b-7548db725c61@github.com>

On Sun, 11 Dec 2022 23:52:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > You're right, but that's actually an improvement compared to the initial implementation where cleanup/destroy wasn't synchronized at all :)
> > With regards to the missing synchronization of key usage and key destruction, I think this patch doesn't change the existing behavior because it wasn't synchronized before either.
> 
> I think behavior is changed, since the synchronization problem was hidden by generation of many keys. And if we start to use one key by many threads, we will need to carefully sync it, but if we just add synchronization per ssl contex we will make encode/decode methods single threaded per ssl context, which is unfortunate.

Not sure what you mean? Do you refer to the `SessionTicketSpec`s `encrypt()`/`decrypt()` methods?What do you mean by "*we make them single threaded per ssl context*"?

`encrypt()` will call `getCurrentKey()` which isn't synchronized. Only once an hour or so, when the current key has expired, `getCurrentKey()` will call `getNextKey()` which is synchronized on the ssl context. `decrypt()` only calls `getKey()` which is never synchronized. I can't see a problem here.

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

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

From sgehwolf at openjdk.org  Mon Dec 12 10:42:00 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 10:42:00 GMT
Subject: RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
Message-ID: <rVC12vwXgwsfDK7soRVybzhirJuRlal3-LndBfX5b6c=.5c122169-bdcf-4aac-bb24-ec8a651c7b0c@github.com>

On Fri, 9 Dec 2022 10:18:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test introduced with [JDK-8298108](https://bugs.openjdk.org/browse/JDK-8298108) failed on Windows apparently due to a non-portable use of `path.separator` in the test.
> 
> @seanjmullan was kind enough to test this change, which fixes the issue on Windows.
> 
> Thus, remove the test from the `ProblemList.txt` as the test now works on that platform as well. Thoughts?

Withdrawing this PR in favour of https://github.com/openjdk/jdk20/pull/18 to get it into JDK 20 instead (during RDP1).

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

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

From sgehwolf at openjdk.org  Mon Dec 12 10:42:00 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 10:42:00 GMT
Subject: Withdrawn: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
References: <AUoGXaLPLIqKcW6iep9RG7FfmhAHGH6hMBT-kUq4cqk=.f02e7045-3533-408e-81c4-9ef2d3f9f64f@github.com>
Message-ID: <lqHXyDbKmAnXiulluL2_vH97nLaOOZWCJwg2LcgsPk8=.032da61d-62f8-4435-82fe-4bac6b4bfcdd@github.com>

On Fri, 9 Dec 2022 10:18:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The test introduced with [JDK-8298108](https://bugs.openjdk.org/browse/JDK-8298108) failed on Windows apparently due to a non-portable use of `path.separator` in the test.
> 
> @seanjmullan was kind enough to test this change, which fixes the issue on Windows.
> 
> Thus, remove the test from the `ProblemList.txt` as the test now works on that platform as well. Thoughts?

This pull request has been closed without being integrated.

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

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

From sgehwolf at openjdk.org  Mon Dec 12 10:47:14 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 10:47:14 GMT
Subject: [jdk20] RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
Message-ID: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>

Re-created the PR from https://git.openjdk.org/jdk/pull/11606 so as to get the test fixed in JDK 20. According to https://openjdk.org/jeps/3 test and documentation bugs are eligible during RDP 1 and RDP 2 provided they have a `noreg-self` label, which this bug has.

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

Commit messages:
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows

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

PR: https://git.openjdk.org/jdk20/pull/18

From serb at openjdk.org  Mon Dec 12 11:08:37 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 Dec 2022 11:08:37 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <m43XYvDFFJhwz7UlMSj4cPPdqLMYCiLiG3dsqak9dCg=.a73e7e1a-591f-4146-a42b-7548db725c61@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <CRM5Mj33LphkJwUid1m8LTSrcKahnrxEBfpW824ly2k=.bde4c7f1-7cc9-40ef-b452-6d39940a8a89@github.com>
 <ztLjjE6Q6bifURYOxq0BweQF5KNjVWw3UsrhV5kKwJc=.3c52deb3-5331-4452-bee5-05ebab535500@github.com>
 <aoKrIJMhr4QWZDSmPxDCa_9-5aqvL0vFBsGvE6wCAuA=.03d45e7c-400b-4c2d-aaeb-7122c8939b70@github.com>
 <m43XYvDFFJhwz7UlMSj4cPPdqLMYCiLiG3dsqak9dCg=.a73e7e1a-591f-4146-a42b-7548db725c61@github.com>
Message-ID: <sEp3HA6kCQ-1tH6u4anTcCnSPe9lWrZIgNXXlla9NT0=.c9a7e6b4-8735-45d8-994a-d301d3e57b4d@github.com>

On Mon, 12 Dec 2022 10:06:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> `encrypt()` will call `getCurrentKey()` which isn't synchronized.

If we think that all that try/catch blocks in the encode/cleanup will save us, then why we added the sync block around cleanup.  But If we try synchronize work with keys, and added the new block around cleanup then why the usage of the keys(who call getCurrentKey) are not synchronized by anything, am I not sure that it is safe to use the key after/during destruction, probably some write/read locks will [help](http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3#l12.15).

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

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

From mullan at openjdk.org  Mon Dec 12 14:51:04 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 Dec 2022 14:51:04 GMT
Subject: [jdk20] RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
References: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
Message-ID: <dUxclYaQig3IsQxx49dKsK8SE5vdT2mxoLT_sO9ElZA=.f3fcc72e-726a-4bf6-aac9-044e5841e549@github.com>

On Mon, 12 Dec 2022 10:37:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Re-created the PR from https://git.openjdk.org/jdk/pull/11606 so as to get the test fixed in JDK 20. According to https://openjdk.org/jeps/3 test and documentation bugs are eligible during RDP 1 and RDP 2 provided they have a `noreg-self` label, which this bug has.

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/18

From sgehwolf at openjdk.org  Mon Dec 12 15:51:05 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 15:51:05 GMT
Subject: [jdk20] RFR: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
References: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
Message-ID: <o4Sw1Jw2hxbornzj6kBf9L1oleKIYD12JaygZL9BfhI=.48ea23e2-1a43-46e5-930b-29e43fa1cdd3@github.com>

On Mon, 12 Dec 2022 10:37:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Re-created the PR from https://git.openjdk.org/jdk/pull/11606 so as to get the test fixed in JDK 20. According to https://openjdk.org/jeps/3 test and documentation bugs are eligible during RDP 1 and RDP 2 provided they have a `noreg-self` label, which this bug has.

Thanks for the review!

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

PR: https://git.openjdk.org/jdk20/pull/18

From sgehwolf at openjdk.org  Mon Dec 12 15:52:59 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Dec 2022 15:52:59 GMT
Subject: [jdk20] Integrated: 8298271:
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
 Windows
In-Reply-To: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
References: <BDk_Iy5h1H4pEozlWSaC0v1zZHqArn2Ma5Qyyz_0etk=.299d040a-40cc-437d-89e3-6a1930efe41b@github.com>
Message-ID: <EHsjhE8c3yE1vl7IHIgqFtXApC2mrXlG8OZScwZrtLU=.d366788d-0b8c-4cd2-8430-154e59b0640a@github.com>

On Mon, 12 Dec 2022 10:37:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Re-created the PR from https://git.openjdk.org/jdk/pull/11606 so as to get the test fixed in JDK 20. According to https://openjdk.org/jeps/3 test and documentation bugs are eligible during RDP 1 and RDP 2 provided they have a `noreg-self` label, which this bug has.

This pull request has now been integrated.

Changeset: cf93933e
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/cf93933e21d146fe296b1e4b8e2ef06b699175d6
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk20/pull/18

From jwilhelm at openjdk.org  Mon Dec 12 18:57:38 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 12 Dec 2022 18:57:38 GMT
Subject: RFR: Merge jdk20
Message-ID: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8297288: Example code in Scanner class
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows
 - 8298459: Fix msys2 linking and handling out of tree build directory for source zip creation

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

Changes: https://git.openjdk.org/jdk/pull/11637/files
  Stats: 47 lines in 5 files changed: 25 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/11637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11637/head:pull/11637

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

From pminborg at openjdk.org  Mon Dec 12 21:56:51 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Dec 2022 21:56:51 GMT
Subject: Integrated: 8297505: Declare fields in some sun.security.pkcs11
 classes as final
In-Reply-To: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
References: <IKwYlwSCdO1z4rj16DSI5H-sWPvv37CLVu3tYdPgAII=.a982c8e6-cffb-4b91-9385-ac2a9fd24181@github.com>
Message-ID: <UavRSIubkdwNp8kAzvPErVlosS1wRtVxF4JIcKqIrJw=.04a55414-3554-4dcb-b526-e60a254af0a5@github.com>

On Thu, 24 Nov 2022 08:13:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring some fields as `final` to potentially unlock performance optimisations and improve thread visibility (e.g. for GC threads). The PR also fixes a "synchronising on a non-final field" anti-pattern.

This pull request has now been integrated.

Changeset: c3bc4fcb
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3bc4fcb3d0a8bd2eb308fae90a4cb865b216cb8
Stats:     25 lines in 10 files changed: 0 ins; 0 del; 25 mod

8297505: Declare fields in some sun.security.pkcs11 classes as final

Reviewed-by: valeriep

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

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

From benjamin.marwell at f-i.de  Tue Dec 13 07:39:44 2022
From: benjamin.marwell at f-i.de (benjamin.marwell at f-i.de)
Date: Tue, 13 Dec 2022 07:39:44 +0000
Subject: Disabled brainpool curves
Message-ID: <2A619456-B53D-4B3D-AEBE-439DDA57DC07@f-i.de>

Hi everyone!

I just stumbled over ?Disable weak named curves?, e.g.

? https://bugs.openjdk.org/browse/JDK-8235540 
? http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html

Interestingly, brainpoolP512r1 is on that list.
Just a few weeks ago I cited someone from the German BSI who debunked the myth that brainpool ciphers are weak [1]].
They are only weak on TLSv1.3 if used not properly.

Please revert this change ASAP. It will break a lot of cryptography for no reason.
Additionally, JDK-8235540 doesn't even mention how this list was chosen.

Here's the quote again from Manfred Lochter, how works at the BSI:

> The unfortunate wording about the brainpool curves originated in TLS 1.3,
> however RFC 8734 makes the curves usable for TLS again.
> We will continue to recommend the Brainpool curves.
> It should also be noted that the arguments for the "modern formulas" have all been refuted by now.
> Especially the implementation of Curve 25519 requires more effort to protect against SCA;
> the deterministic signatures are vulnerable to fault injection.
> In the medium term, however, the switch to post-quantum cryptography is necessary;
> there are comprehensive recommendations on this at [2]

Please be aware that other users are already +1'd this [3].

- Ben

[1]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html 
[2]: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html
[3]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5591 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221213/8f08b0c1/smime-0001.p7s>

From duke at openjdk.org  Tue Dec 13 12:32:30 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 13 Dec 2022 12:32:30 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v2]
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <Wb26Zr2h45ICR62N-WchIQ-o2BFhCq7IL9XlirJ3UJI=.9d40ac38-bc21-46c7-b2a8-02e243a61605@github.com>

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  cleaned up exception handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11558/files
  - new: https://git.openjdk.org/jdk/pull/11558/files/fbe35671..85bc7c1d

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

  Stats: 111 lines in 2 files changed: 18 ins; 64 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11558.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11558/head:pull/11558

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

From duke at openjdk.org  Tue Dec 13 12:34:05 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 13 Dec 2022 12:34:05 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v2]
In-Reply-To: <XqyY1BvOLVTKnULb3m96SVhm5KJN33JmiMGwCbMfjhA=.18bee353-33f2-4906-ba87-3276845b5825@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <C_noub5rpiVWk8rATnM4Y3DbEUkXqGd4dYBulJIJdkQ=.7054494c-e8c8-4fc5-bca2-a870066e6be6@github.com>
 <XqyY1BvOLVTKnULb3m96SVhm5KJN33JmiMGwCbMfjhA=.18bee353-33f2-4906-ba87-3276845b5825@github.com>
Message-ID: <58-ypmmZdBIMm57EW68-45n24cxpbBddDWZVRYyXWEI=.c710abc2-b815-4afe-972c-ea5ac8a825b2@github.com>

On Thu, 8 Dec 2022 19:40:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 617:
>> 
>>> 615:             clientException = e;
>>> 616: 
>>> 617:             if (testCase.isGoodJob()) {
>> 
>> Same here. Check if this is method is even used and what is the purpose of it. You may not need these checks and would prefer to have no try-catch in this method.
>
> It is used by InvalidRecords.java test. It expects handshake to fail so overrides this method.

refactored the code to be a bit cleaner.

The InvalidRecords.java test explicitly threw an exception that is then treated as a successful test run. I refactored the test a little so it only throws an exception if the test fails.

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

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

From sean.mullan at oracle.com  Tue Dec 13 13:34:04 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 13 Dec 2022 08:34:04 -0500
Subject: Disabled brainpool curves
In-Reply-To: <2A619456-B53D-4B3D-AEBE-439DDA57DC07@f-i.de>
References: <2A619456-B53D-4B3D-AEBE-439DDA57DC07@f-i.de>
Message-ID: <94059cfd-4d54-b772-b6cf-f0b496c2ec72@oracle.com>



On 12/13/22 2:39 AM, benjamin.marwell at f-i.de wrote:
> Hi everyone!
> 
> I just stumbled over ?Disable weak named curves?, e.g.
> 
> ? https://bugs.openjdk.org/browse/JDK-8235540
> ? http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html
> 
> Interestingly, brainpoolP512r1 is on that list.
> Just a few weeks ago I cited someone from the German BSI who debunked the myth that brainpool ciphers are weak [1]].
> They are only weak on TLSv1.3 if used not properly.
> 
> Please revert this change ASAP. It will break a lot of cryptography for no reason.
> Additionally, JDK-8235540 doesn't even mention how this list was chosen.

The reason for removing the brainpool curves was previously explained in 
my post: 
https://mail.openjdk.org/pipermail/security-dev/2022-November/033171.html

As I also said in that post, we would be open to reviewing contributions 
from the community for reintroducing support for brainpool but they 
would need to be done using the current design structure and using 
complete formulas.

Thanks,
Sean

> 
> Here's the quote again from Manfred Lochter, how works at the BSI:
> 
>> The unfortunate wording about the brainpool curves originated in TLS 1.3,
>> however RFC 8734 makes the curves usable for TLS again.
>> We will continue to recommend the Brainpool curves.
>> It should also be noted that the arguments for the "modern formulas" have all been refuted by now.
>> Especially the implementation of Curve 25519 requires more effort to protect against SCA;
>> the deterministic signatures are vulnerable to fault injection.
>> In the medium term, however, the switch to post-quantum cryptography is necessary;
>> there are comprehensive recommendations on this at [2]
> 
> Please be aware that other users are already +1'd this [3].
> 
> - Ben
> 
> [1]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html
> [2]: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html
> [3]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html

From jwilhelm at openjdk.org  Tue Dec 13 13:41:06 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 13:41:06 GMT
Subject: Withdrawn: Merge jdk20
In-Reply-To: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>
References: <BxIryfRtcd7M9X0vYVs-m0ZBEpqyFwvoMcArBI_Up04=.86f53b97-d454-47a1-bf25-160472090a00@github.com>
Message-ID: <d0hE0JqHnWzwnepDeN29yqmt5RZn6M3d4f8-m6SkpjM=.dc7eec0f-fe88-4fb2-9308-c0d3c8a92b31@github.com>

On Mon, 12 Dec 2022 18:49:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has been closed without being integrated.

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

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

From jwilhelm at openjdk.org  Tue Dec 13 14:03:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 14:03:29 GMT
Subject: RFR: Merge jdk20
Message-ID: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298084: Memory leak in Method::build_profiling_method_data
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"
 - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
 - 8297288: Example code in Scanner class
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows
 - 8298459: Fix msys2 linking and handling out of tree build directory for source zip creation

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

Changes: https://git.openjdk.org/jdk/pull/11651/files
  Stats: 181 lines in 15 files changed: 60 ins; 57 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11651.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11651/head:pull/11651

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

From jwilhelm at openjdk.org  Tue Dec 13 16:46:07 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 16:46:07 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
References: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
Message-ID: <LENLR7kTbJlO0PXG0D_YRgHDc0zYyJrge12segDYdeY=.6cf72ca8-4535-4bf4-ade7-d901366dcde9@github.com>

On Tue, 13 Dec 2022 13:55:12 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 23e18275
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23e18275ac2a7297ba806a1835fabb7141949967
Stats:     181 lines in 15 files changed: 60 ins; 57 del; 64 mod

Merge

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

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

From anthony.scarpino at oracle.com  Tue Dec 13 17:58:21 2022
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 13 Dec 2022 09:58:21 -0800
Subject: Disabled brainpool curves
In-Reply-To: <94059cfd-4d54-b772-b6cf-f0b496c2ec72@oracle.com>
References: <2A619456-B53D-4B3D-AEBE-439DDA57DC07@f-i.de>
 <94059cfd-4d54-b772-b6cf-f0b496c2ec72@oracle.com>
Message-ID: <234c0e4a-7173-e8f6-843d-ce74e71ab955@oracle.com>


Additionally JDK-8235540, was a java.security configuration change for 
JDK7 and JDK8.  If you want to re-enable brainpool curves, change the 
java.disabled.namedCurves and/or 
jdk.[tls|certpath|jar].disabledAlgorithms properties in the java.security.

One policy won't fit everyone's needs, that's why this particular change 
was a configuration change only.

Tony


On 12/13/22 5:34 AM, Sean Mullan wrote:
> 
> 
> On 12/13/22 2:39 AM, benjamin.marwell at f-i.de wrote:
>> Hi everyone!
>>
>> I just stumbled over ?Disable weak named curves?, e.g.
>>
>> ? https://bugs.openjdk.org/browse/JDK-8235540
>> ? 
>> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html
>>
>> Interestingly, brainpoolP512r1 is on that list.
>> Just a few weeks ago I cited someone from the German BSI who debunked 
>> the myth that brainpool ciphers are weak [1]].
>> They are only weak on TLSv1.3 if used not properly.
>>
>> Please revert this change ASAP. It will break a lot of cryptography 
>> for no reason.
>> Additionally, JDK-8235540 doesn't even mention how this list was chosen.
> 
> The reason for removing the brainpool curves was previously explained in 
> my post: 
> https://mail.openjdk.org/pipermail/security-dev/2022-November/033171.html
> 
> As I also said in that post, we would be open to reviewing contributions 
> from the community for reintroducing support for brainpool but they 
> would need to be done using the current design structure and using 
> complete formulas.
> 
> Thanks,
> Sean
> 
>>
>> Here's the quote again from Manfred Lochter, how works at the BSI:
>>
>>> The unfortunate wording about the brainpool curves originated in TLS 
>>> 1.3,
>>> however RFC 8734 makes the curves usable for TLS again.
>>> We will continue to recommend the Brainpool curves.
>>> It should also be noted that the arguments for the "modern formulas" 
>>> have all been refuted by now.
>>> Especially the implementation of Curve 25519 requires more effort to 
>>> protect against SCA;
>>> the deterministic signatures are vulnerable to fault injection.
>>> In the medium term, however, the switch to post-quantum cryptography 
>>> is necessary;
>>> there are comprehensive recommendations on this at [2]
>>
>> Please be aware that other users are already +1'd this [3].
>>
>> - Ben
>>
>> [1]: 
>> https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html
>> [2]: 
>> https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html
>> [3]: 
>> https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html

From valeriep at openjdk.org  Tue Dec 13 19:11:56 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 13 Dec 2022 19:11:56 GMT
Subject: RFR: 8298249: Excessive memory allocation in CipherInputStream
 AEAD decryption
In-Reply-To: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
References: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
Message-ID: <ab0UjHw1U1mnn5WfigyhJ5GaFDy6LomhR6k2YWT-bzU=.593f29a1-c39f-48e0-ba0e-7484dfac4992@github.com>

On Thu, 8 Dec 2022 16:33:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.
> 
> `Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.
> 
> There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.
> 
> The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.
> 
> Benchmark results before:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s
> 
> 
> After:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

I will take a look. Thanks~

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

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

From valeriep at openjdk.org  Wed Dec 14 00:23:44 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Dec 2022 00:23:44 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
Message-ID: <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>

> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  address review feedbacks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11339/files
  - new: https://git.openjdk.org/jdk/pull/11339/files/2bf57b16..fa2b3dbc

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

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

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

From jpai at openjdk.org  Wed Dec 14 06:26:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 06:26:47 GMT
Subject: RFR: 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/
Message-ID: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>

Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?

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

Commit messages:
 - 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/

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

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

From jpai at openjdk.org  Wed Dec 14 06:35:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 06:35:11 GMT
Subject: RFR: 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/
 [v2]
In-Reply-To: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
References: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
Message-ID: <xPbuBa4PTOxT8aNaomQ2LjaFfsjgWTuuqMhIxoNTs9o=.2fd63c3f-6936-43b0-bdd7-c2d3b533a6ee@github.com>

> Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  typo in test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11662/files
  - new: https://git.openjdk.org/jdk/pull/11662/files/a077f0c1..2b83ff90

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

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

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

From jpai at openjdk.org  Wed Dec 14 06:35:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Dec 2022 06:35:11 GMT
Subject: RFR: 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/
In-Reply-To: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
References: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
Message-ID: <46dIgWuT1czBhptueB_dJKrn9kSuor6j-E_jdJodz6k=.c6c2cecd-818a-4720-8d4b-a7c1e29e7213@github.com>

On Wed, 14 Dec 2022 06:17:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?

There was another trivial typo fix from the original PR in test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java. I have now updated this PR to include that file too.

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

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

From benjamin.marwell at f-i.de  Wed Dec 14 09:23:22 2022
From: benjamin.marwell at f-i.de (benjamin.marwell at f-i.de)
Date: Wed, 14 Dec 2022 09:23:22 +0000
Subject: Disabled brainpool curves
In-Reply-To: <234c0e4a-7173-e8f6-843d-ce74e71ab955@oracle.com>
References: <2A619456-B53D-4B3D-AEBE-439DDA57DC07@f-i.de>
 <94059cfd-4d54-b772-b6cf-f0b496c2ec72@oracle.com>
 <234c0e4a-7173-e8f6-843d-ce74e71ab955@oracle.com>
Message-ID: <0E24B047-14B3-471A-B37B-1EE410A98ADE@f-i.de>

Yes, I know that.

For the reasons I have given, I would like to request to remove brainpool 512 from that list for all users.
There is no good reason to disable that cipher on JDK 8. It is not insecure, that has been debunked by the BSI.

Any chance for this to happen?

- Ben

?On 13.12.22, 18:58, "Anthony Scarpino" <anthony.scarpino at oracle.com <mailto:anthony.scarpino at oracle.com>> wrote:


# Externer Sender


Additionally JDK-8235540, was a java.security configuration change for 
JDK7 and JDK8. If you want to re-enable brainpool curves, change the 
java.disabled.namedCurves and/or 
jdk.[tls|certpath|jar].disabledAlgorithms properties in the java.security.


One policy won't fit everyone's needs, that's why this particular change 
was a configuration change only.


Tony




On 12/13/22 5:34 AM, Sean Mullan wrote:
> 
> 
> On 12/13/22 2:39 AM, benjamin.marwell at f-i.de <mailto:benjamin.marwell at f-i.de> wrote:
>> Hi everyone!
>>
>> I just stumbled over ?Disable weak named curves?, e.g.
>>
>> ? https://bugs.openjdk.org/browse/JDK-8235540 <https://bugs.openjdk.org/browse/JDK-8235540>
>> ? 
>> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html <http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html>
>>
>> Interestingly, brainpoolP512r1 is on that list.
>> Just a few weeks ago I cited someone from the German BSI who debunked 
>> the myth that brainpool ciphers are weak [1]].
>> They are only weak on TLSv1.3 if used not properly.
>>
>> Please revert this change ASAP. It will break a lot of cryptography 
>> for no reason.
>> Additionally, JDK-8235540 doesn't even mention how this list was chosen.
> 
> The reason for removing the brainpool curves was previously explained in 
> my post: 
> https://mail.openjdk.org/pipermail/security-dev/2022-November/033171.html <https://mail.openjdk.org/pipermail/security-dev/2022-November/033171.html>
> 
> As I also said in that post, we would be open to reviewing contributions 
> from the community for reintroducing support for brainpool but they 
> would need to be done using the current design structure and using 
> complete formulas.
> 
> Thanks,
> Sean
> 
>>
>> Here's the quote again from Manfred Lochter, how works at the BSI:
>>
>>> The unfortunate wording about the brainpool curves originated in TLS 
>>> 1.3,
>>> however RFC 8734 makes the curves usable for TLS again.
>>> We will continue to recommend the Brainpool curves.
>>> It should also be noted that the arguments for the "modern formulas" 
>>> have all been refuted by now.
>>> Especially the implementation of Curve 25519 requires more effort to 
>>> protect against SCA;
>>> the deterministic signatures are vulnerable to fault injection.
>>> In the medium term, however, the switch to post-quantum cryptography 
>>> is necessary;
>>> there are comprehensive recommendations on this at [2]
>>
>> Please be aware that other users are already +1'd this [3].
>>
>> - Ben
>>
>> [1]: 
>> https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html <https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html>
>> [2]: 
>> https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html <https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html>
>> [3]: 
>> https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html <https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5591 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221214/5075dc6c/smime.p7s>

From lancea at openjdk.org  Wed Dec 14 11:22:10 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Dec 2022 11:22:10 GMT
Subject: RFR: 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/
 [v2]
In-Reply-To: <xPbuBa4PTOxT8aNaomQ2LjaFfsjgWTuuqMhIxoNTs9o=.2fd63c3f-6936-43b0-bdd7-c2d3b533a6ee@github.com>
References: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
 <xPbuBa4PTOxT8aNaomQ2LjaFfsjgWTuuqMhIxoNTs9o=.2fd63c3f-6936-43b0-bdd7-c2d3b533a6ee@github.com>
Message-ID: <gbhyCNSCgX-29h2pKQsUDPwcpnLpoi9Vf5OhNvL0huQ=.b2dd42fe-dc0c-468a-9cf4-7d24b90a9262@github.com>

On Wed, 14 Dec 2022 06:35:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo in test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java

Marked as reviewed by lancea (Reviewer).

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

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

From weijun at openjdk.org  Wed Dec 14 14:28:00 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Dec 2022 14:28:00 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
Message-ID: <T6MmIkf3pokv8hkgsVeUWBOMEuiQYTbkhovN683REm8=.733900a8-de40-4b73-85b6-d06d9d436102@github.com>

On Wed, 14 Dec 2022 00:23:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedbacks

I've added myself as a reviewer to the CSR. You might want to create a release note and a subtask to update the provider doc. Thanks.

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

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

From ascarpino at openjdk.org  Wed Dec 14 18:23:24 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 14 Dec 2022 18:23:24 GMT
Subject: RFR: 8298249: Excessive memory allocation in CipherInputStream
 AEAD decryption
In-Reply-To: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
References: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
Message-ID: <amUqhNTCZZiCVsFb6z7nZrT5PjbF5bOp9TPlg5mXMG0=.92119980-7d78-4ace-9c6e-6d7f7fb059d5@github.com>

On Thu, 8 Dec 2022 16:33:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.
> 
> `Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.
> 
> There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.
> 
> The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.
> 
> Benchmark results before:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s
> 
> 
> After:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

Change looks good to me

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

Marked as reviewed by ascarpino (Reviewer).

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

From rhalade at openjdk.org  Wed Dec 14 18:23:32 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 14 Dec 2022 18:23:32 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v2]
In-Reply-To: <Wb26Zr2h45ICR62N-WchIQ-o2BFhCq7IL9XlirJ3UJI=.9d40ac38-bc21-46c7-b2a8-02e243a61605@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <Wb26Zr2h45ICR62N-WchIQ-o2BFhCq7IL9XlirJ3UJI=.9d40ac38-bc21-46c7-b2a8-02e243a61605@github.com>
Message-ID: <Zgc7Ha7_eLWme2FG9ToQVW312yhg3jZ9w1i73182o0U=.1463ff7e-7c77-40ae-85e4-8f0f08377003@github.com>

On Tue, 13 Dec 2022 12:32:30 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
>> 
>> * refactors the class to only create one additional thread
>> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
>> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
>> * removes CipherSuite.java from ProblemList
>> 
>> Ran the following tests 200 times each with no failures.
>> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
>> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
>> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
>> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
>> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up exception handling

thanks for the updates! LGTM other than few minor format changes.

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 333:

> 331:     Some tests failed with receive time-out errors when the client tried to read
> 332:     from the server. The server thread had exitted normally so the read _should_
> 333:     succeed. So let's try to read a couple times before giving up.

Suggestion:

    from the server. The server thread had exited normally so the read _should_
    succeed. So let's try to read a couple of times before giving up.

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 405:

> 403:     }
> 404: 
> 405:     DatagramPacket createHandshakePacket(byte[] ba, SocketAddress socketAddr){

Suggestion:

    DatagramPacket createHandshakePacket(byte[] ba, SocketAddress socketAddr) {

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 579:

> 577:         try {
> 578:             testCase.doClientSide(socket, serverSocketAddr);
> 579: 

Suggestion:

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

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

From duke at openjdk.org  Wed Dec 14 18:41:35 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 14 Dec 2022 18:41:35 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v3]
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <K_rAnEb23osbYafKQJsQ-yjf6arsDqKdrNWo2pTvDyg=.0d483383-f2c2-472a-a7ab-5d50db71cd5b@github.com>

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  formatting changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11558/files
  - new: https://git.openjdk.org/jdk/pull/11558/files/85bc7c1d..b4fc96ba

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

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

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

From valeriep at openjdk.org  Wed Dec 14 22:22:04 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Dec 2022 22:22:04 GMT
Subject: RFR: 8298249: Excessive memory allocation in CipherInputStream
 AEAD decryption
In-Reply-To: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
References: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
Message-ID: <HXnaWnM0kbV-pgIVug6qT2Wbg_Dyn7-e29eJW10fcmc=.c39bada6-01e3-4d8e-a443-dc805d703d19@github.com>

On Thu, 8 Dec 2022 16:33:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.
> 
> `Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.
> 
> There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.
> 
> The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.
> 
> Benchmark results before:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s
> 
> 
> After:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

Looks good. Thanks for the patch~

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

Marked as reviewed by valeriep (Reviewer).

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

From dnguyen at openjdk.org  Wed Dec 14 23:47:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 14 Dec 2022 23:47:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop
 10
Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>

Open l10n drop
All tests passed

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

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk20/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298133
  Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From achung at openjdk.org  Thu Dec 15 00:07:04 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 15 Dec 2022 00:07:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <Sfe4uUeYHsI1HUSpkDyn-dbJiiReR3yQCyzrBo1H_7k=.52ee8dbe-28b5-4b59-a4d9-3b2dda6ac0b8@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

looks good

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

Marked as reviewed by achung (Committer).

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:01:05 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:01:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:

> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 187: 
> 188: main.plugin.category=\u7C7B\u522B 

As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:07:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:07:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:

> 24: #
> 25: 
> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten

`jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Thu Dec 15 01:16:13 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 15 Dec 2022 01:16:13 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
Message-ID: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>

On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B 
> 
> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.

Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

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

PR: https://git.openjdk.org/jdk20/pull/35

From valeriep at openjdk.org  Thu Dec 15 01:28:07 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 Dec 2022 01:28:07 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <T6MmIkf3pokv8hkgsVeUWBOMEuiQYTbkhovN683REm8=.733900a8-de40-4b73-85b6-d06d9d436102@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
 <T6MmIkf3pokv8hkgsVeUWBOMEuiQYTbkhovN683REm8=.733900a8-de40-4b73-85b6-d06d9d436102@github.com>
Message-ID: <eWt53el2svZviMTjnSkOwya0ktVTznyagV1UYni3wY8=.ea7ed429-0ab2-461e-b80b-47dc8136d554@github.com>

On Wed, 14 Dec 2022 14:25:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I've added myself as a reviewer to the CSR. You might want to create a release note and a subtask to update the provider doc. Thanks.

Sure will, thanks for the reminder~

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

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

From dnguyen at openjdk.org  Thu Dec 15 02:26:12 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:26:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
Message-ID: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>

On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
> 
>> 24: #
>> 25: 
>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
> 
> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?

I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.

I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.

And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 02:45:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 02:45:48 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From djelinski at openjdk.org  Thu Dec 15 06:55:03 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Dec 2022 06:55:03 GMT
Subject: RFR: 8298249: Excessive memory allocation in CipherInputStream
 AEAD decryption
In-Reply-To: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
References: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
Message-ID: <XtTQ8yv9yr-CErbBMPqlI0HehhrbVIs53lhAbarpUO8=.abec5b3d-5e99-4187-81ba-7ac645e9f509@github.com>

On Thu, 8 Dec 2022 16:33:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.
> 
> `Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.
> 
> There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.
> 
> The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.
> 
> Benchmark results before:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s
> 
> 
> After:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

Thanks for reviewing!

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

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

From djelinski at openjdk.org  Thu Dec 15 06:58:14 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Dec 2022 06:58:14 GMT
Subject: Integrated: 8298249: Excessive memory allocation in CipherInputStream
 AEAD decryption
In-Reply-To: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
References: <gcIILG_u5OgYLGuyoK6knDx4XyW-40fLgLo5ORxFCVs=.d86b8eae-6b2b-402d-8167-2b19d229c14b@github.com>
Message-ID: <A2ISO_7WgIFbRMLK1wduKM8MxzkYn-bUrzwP7ZL8k9c=.fe798814-abba-4ae2-ad44-5b1609f29665@github.com>

On Thu, 8 Dec 2022 16:33:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherInputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers.
> 
> `Cipher.update` on AEAD decryption does not output any data; instead, all data is buffered and returned in one shot from `doFinal` call. On the other hand, the value returned by `getOutputSize` increases after every `update` call, which triggers multiple allocations in the existing implementation.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the `update` calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> As long as `doUpdate` returns no data, the new implementation doesn't allocate any memory. As a result, for AEAD ciphers it will only allocate once in the `doFinal` invocation.
> 
> There's a similar issue in CipherOutputStream that manifests when doing many small writes; I'll file a separate bug for that.
> 
> The PR adds a new benchmark for AES/GCM encryption and decryption using CipherInputStream. That benchmark shows a nice improvement on decryption and comparable results on encryption.
> 
> Benchmark results before:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   24590,604 ? 1169,075  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40      19,159 ?    0,219  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  127135,615 ? 2322,957  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2138,727 ?   16,400  ops/s
> 
> 
> After:
> 
> Benchmark                        (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherInputStream.decrypt       16384          128              thrpt   40   43419,355 ? 3265,238  ops/s
> AESGCMCipherInputStream.decrypt     1048576          128              thrpt   40     789,463 ?   89,384  ops/s
> AESGCMCipherInputStream.encrypt       16384          128              thrpt   40  123014,294 ? 3302,102  ops/s
> AESGCMCipherInputStream.encrypt     1048576          128              thrpt   40    2007,224 ?   88,347  ops/s

This pull request has now been integrated.

Changeset: b9074fa1
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9074fa1ed489993d60ce873fd8105a95d30782a
Stats:     146 lines in 2 files changed: 142 ins; 0 del; 4 mod

8298249: Excessive memory allocation in CipherInputStream AEAD decryption

Reviewed-by: ascarpino, valeriep

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

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

From dnguyen at openjdk.org  Thu Dec 15 12:06:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 12:06:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <k7G3LUpn1hYfFwASwRuATz0OVhWJEBaqAFSo-7zK4rI=.c4a1b71d-93a7-4d08-b379-baf63a09ed31@github.com>
 <gt3H8LBSGCmyftDD3Oyzx_BXZgZzvQtJq4pDIWFQnQY=.fbc90067-e182-490f-85e4-f302ae7cfd64@github.com>
Message-ID: <iBTNjKoPxhwIA8LhLguE4u7j67wbLJolkZ4jx-1uz5g=.be6291cd-2fd4-403a-bb37-1f88479f967e@github.com>

On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
>> 
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187: 
>>> 188: main.plugin.category=\u7C7B\u522B 
>> 
>> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes.
>
> Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop

In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace.

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

PR: https://git.openjdk.org/jdk20/pull/35

From djelinski at openjdk.org  Thu Dec 15 14:24:59 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Dec 2022 14:24:59 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream AEAD
 decryption
Message-ID: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>

This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.

`Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.

This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.

This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.

Benchmark results before:

Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s


after:

Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s

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

Commit messages:
 - Reduce allocation
 - CipherOutputStream benchmark

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

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

From jnimeh at openjdk.org  Thu Dec 15 15:15:10 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 15 Dec 2022 15:15:10 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v3]
In-Reply-To: <K_rAnEb23osbYafKQJsQ-yjf6arsDqKdrNWo2pTvDyg=.0d483383-f2c2-472a-a7ab-5d50db71cd5b@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <K_rAnEb23osbYafKQJsQ-yjf6arsDqKdrNWo2pTvDyg=.0d483383-f2c2-472a-a7ab-5d50db71cd5b@github.com>
Message-ID: <aybyU74oAramYog5CnIZojRM7uROLKZPAWX3meJPhsE=.e56db03a-c417-4e3b-9891-404e487ef0e3@github.com>

On Wed, 14 Dec 2022 18:41:35 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
>> 
>> * refactors the class to only create one additional thread
>> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
>> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
>> * removes CipherSuite.java from ProblemList
>> 
>> Ran the following tests 200 times each with no failures.
>> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
>> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
>> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
>> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
>> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting changes

Overall it looks good to me.

test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 42:

> 40: 
> 41: /**
> 42:  * Test that if handshake messages are crasged, the handshake would fail

crasged?  Was that supposed to be "changed?"

test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 66:

> 64:         if (needInvalidRecords.get() && (ba.length >= 60) &&
> 65:                 (ba[0x00] == (byte)0x16) && (ba[0x0D] == (byte)0x01) &&
> 66:                 (ba[0x3B] == (byte)0x00) && (ba[0x3C] > 0)) {

I just want to make sure - this test is only designed to be run for initial handshakes with cookies, not resumed handshakes, correct?  I assume that is the intent since this test dates back to the initial DTLS release where resumptions didn't use cookies (that was a recent change to include support for resumption cookies).

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

Marked as reviewed by jnimeh (Reviewer).

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

From duke at openjdk.org  Thu Dec 15 16:04:32 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 16:04:32 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v4]
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <VWFJpTicZSmb6e_gbybhG6_fPkY87NzIHBN4B_BLv64=.f1f0fb43-ee39-4140-bfaf-48fcd30e5033@github.com>

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11558/files
  - new: https://git.openjdk.org/jdk/pull/11558/files/b4fc96ba..4bab7dcb

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

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

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

From duke at openjdk.org  Thu Dec 15 16:04:33 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 16:04:33 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v3]
In-Reply-To: <aybyU74oAramYog5CnIZojRM7uROLKZPAWX3meJPhsE=.e56db03a-c417-4e3b-9891-404e487ef0e3@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <K_rAnEb23osbYafKQJsQ-yjf6arsDqKdrNWo2pTvDyg=.0d483383-f2c2-472a-a7ab-5d50db71cd5b@github.com>
 <aybyU74oAramYog5CnIZojRM7uROLKZPAWX3meJPhsE=.e56db03a-c417-4e3b-9891-404e487ef0e3@github.com>
Message-ID: <RMgdzUXFMPNVtSsl2OEyfbLgjrrwaOC5nCZ7pr4MjLI=.08ee0080-f172-4861-80f4-bf1a2e882974@github.com>

On Thu, 15 Dec 2022 15:09:12 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting changes
>
> test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 42:
> 
>> 40: 
>> 41: /**
>> 42:  * Test that if handshake messages are crasged, the handshake would fail
> 
> crasged?  Was that supposed to be "changed?"

I fixed the typo.

> test/jdk/javax/net/ssl/DTLS/InvalidRecords.java line 66:
> 
>> 64:         if (needInvalidRecords.get() && (ba.length >= 60) &&
>> 65:                 (ba[0x00] == (byte)0x16) && (ba[0x0D] == (byte)0x01) &&
>> 66:                 (ba[0x3B] == (byte)0x00) && (ba[0x3C] > 0)) {
> 
> I just want to make sure - this test is only designed to be run for initial handshakes with cookies, not resumed handshakes, correct?  I assume that is the intent since this test dates back to the initial DTLS release where resumptions didn't use cookies (that was a recent change to include support for resumption cookies).

That's correct. The test driver (DTLSOverDataGram) doesn't do session resumption.

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

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

From duke at openjdk.org  Thu Dec 15 16:18:45 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 16:18:45 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id
Message-ID: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>

- Reviewed the tests and created individual bugs for each.
- Updated @ignore tags with appropriate bug #.
- Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.

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

Commit messages:
 - 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id

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

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

From duke at openjdk.org  Thu Dec 15 17:19:06 2022
From: duke at openjdk.org (Bernd)
Date: Thu, 15 Dec 2022 17:19:06 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
Message-ID: <VFBoSznE433XhqEEJa1-OCOLOtWyQXEvVUf61RWGWKA=.0a5fa31f-b758-4fa8-b3cc-d3821b350dbd@github.com>

On Wed, 14 Dec 2022 00:23:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedbacks

BTW while you touch the algorithm documentation, it Liste pkcs#5 which does work with octet strings, but the java api works with char passwords. It should describe that it uses the ucs2 char->bytes method not utf8 (pkcs8 vs pkcs12 if I recommend correctly). 

(Or even better allow both as currently i would still need to use BC for a byte representation in better defined utf8)

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

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

From xuelei at openjdk.org  Thu Dec 15 17:59:03 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 15 Dec 2022 17:59:03 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id
In-Reply-To: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
Message-ID: <svQ2d7cC51n4H9v2oR6IR6euc6F3ZJiXVX1y1OIP0nQ=.253c7ec3-a3c7-41f2-9365-878b1fa1fde5@github.com>

On Thu, 15 Dec 2022 16:11:02 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> - Reviewed the tests and created individual bugs for each.
> - Updated @ignore tags with appropriate bug #.
> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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

From djelinski at openjdk.org  Thu Dec 15 18:06:38 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Dec 2022 18:06:38 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
Message-ID: <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>

> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
> 
> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
> 
> Benchmark results before:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
> 
> 
> after:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Fix test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11693/files
  - new: https://git.openjdk.org/jdk/pull/11693/files/fee95a52..7b295132

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

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

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

From dnguyen at openjdk.org  Thu Dec 15 18:54:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 18:54:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <d95C1dlJ8bWMdxqTxzNFfJ8wIfXUWprXL1Mj8EhLiaM=.2215541c-f86e-4a46-9e49-9a2a1f2f1e63@github.com>
 <QB_rvT43I38Ksdn8YuHCvzPrTNTua2287iebkdsNakM=.0656bf7b-2eed-4858-ad71-a5ffecdad65b@github.com>
Message-ID: <YYf976GjBqhqZZlsCUy6oz6Tx_KLFXz7iCsU86GAKSM=.5bd572ce-1523-4b69-a17a-1a2b70c896f0@github.com>

On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten
>> 
>> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now?
>
> I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19.
> 
> I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated.
> 
> And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated.

I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation.  

For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip.

Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear.

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

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 18:58:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 18:58:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
Message-ID: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>

On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed trailing whitespace

Changes requested by naoto (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217:

> 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden.
> 216: 
> 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank.

How come `https` turned into `http`? I see these happening all over the places other than this location as well.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:

> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
> 133: artifact.not.found=nicht gefunden
> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

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

PR: https://git.openjdk.org/jdk20/pull/35

From rhalade at openjdk.org  Thu Dec 15 19:06:08 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 15 Dec 2022 19:06:08 GMT
Subject: RFR: 8297798: Timeout with DTLSOverDatagram test template [v4]
In-Reply-To: <VWFJpTicZSmb6e_gbybhG6_fPkY87NzIHBN4B_BLv64=.f1f0fb43-ee39-4140-bfaf-48fcd30e5033@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
 <VWFJpTicZSmb6e_gbybhG6_fPkY87NzIHBN4B_BLv64=.f1f0fb43-ee39-4140-bfaf-48fcd30e5033@github.com>
Message-ID: <_0Wjs1ZIlOTW3Gvq54J9-slDvZLv6EK6SRCwk94Qyoo=.c5a43dba-def8-44f0-8e50-a296746c614a@github.com>

On Thu, 15 Dec 2022 16:04:32 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
>> 
>> * refactors the class to only create one additional thread
>> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
>> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
>> * removes CipherSuite.java from ProblemList
>> 
>> Ran the following tests 200 times each with no failures.
>> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
>> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
>> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
>> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
>> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Marked as reviewed by rhalade (Reviewer).

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

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

From rhalade at openjdk.org  Thu Dec 15 19:20:05 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 15 Dec 2022 19:20:05 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id
In-Reply-To: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
Message-ID: <zfTdQiflt_3lfUT2cOiVaQQR7rpt_qjmv03dZ-aZ8ik=.23c75c64-f18c-4567-b36f-030d1f8aea9f@github.com>

On Thu, 15 Dec 2022 16:11:02 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> - Reviewed the tests and created individual bugs for each.
> - Updated @ignore tags with appropriate bug #.
> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 29:

> 27:  * @summary Add non-blocking SSL/TLS functionality, usable with any
> 28:  *      I/O abstraction
> 29:  * @ignore 8298867

Instead of using ignore tag, I would prefer to put these tests in ProblemList with these bug numbers.

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

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

From duke at openjdk.org  Thu Dec 15 19:52:10 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 19:52:10 GMT
Subject: Integrated: 8297798: Timeout with DTLSOverDatagram test template
In-Reply-To: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
References: <tg6zQm3wsUP754WM9D9jKC7UauuOjJlxAq9vZFxNS40=.c54aa016-dd28-4732-bfd0-c700082eeb20@github.com>
Message-ID: <b4mR2DSrnjl1KehF0x7c4Sp4HUQ043x8IJQDuyQUOEw=.05fce978-9c16-4a6a-8c73-5073acf3792b@github.com>

On Wed, 7 Dec 2022 13:04:28 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> This fix is intended to address various time-out errors in tests that use DTLSOverDatagram as a test template. Based on test output from those bugs (JDK-8202059, JDK-8249562, JDK-8280185, JDK-8280186, JDK-8269887, JDK-8268899), this fix:
> 
> * refactors the class to only create one additional thread
> * adds a CountdownLatch so if the server thread doesn't start for some reason, it is reported quickly
> * cleans up code to remove a loop condition that never fired: tests always time-out before too many loop iterations
> * removes CipherSuite.java from ProblemList
> 
> Ran the following tests 200 times each with no failures.
> * open/test/jdk/javax/net/ssl/DTLS/ClientAuth.java
> * open/test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
> * open/test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
> * open/test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
> * open/test/jdk/javax/net/ssl/DTLS/CipherSuite.java

This pull request has now been integrated.

Changeset: 4b313b51
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b313b51b1787113961c289a41708e31fa19cacc
Stats:     170 lines in 3 files changed: 35 ins; 91 del; 44 mod

8297798: Timeout with DTLSOverDatagram test template

Reviewed-by: jnimeh, rhalade

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

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

From duke at openjdk.org  Thu Dec 15 20:07:34 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 20:07:34 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id [v2]
In-Reply-To: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
Message-ID: <eEFwn1jmhImAwzofB0bd9h9cgLboN3LGEkR5n7lTjoA=.485cbc6f-ba3f-4c17-8671-20f2ff1bf7c9@github.com>

> - Reviewed the tests and created individual bugs for each.
> - Updated @ignore tags with appropriate bug #.
> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.

Matthew Donovan 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-8249826
 - Moved bug numbers to ProblemList and removed @ignore
 - 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11698/files
  - new: https://git.openjdk.org/jdk/pull/11698/files/e120d6fa..b9b9a42e

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

  Stats: 3074 lines in 146 files changed: 1313 ins; 968 del; 793 mod
  Patch: https://git.openjdk.org/jdk/pull/11698.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11698/head:pull/11698

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

From duke at openjdk.org  Thu Dec 15 20:07:34 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 15 Dec 2022 20:07:34 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id [v2]
In-Reply-To: <zfTdQiflt_3lfUT2cOiVaQQR7rpt_qjmv03dZ-aZ8ik=.23c75c64-f18c-4567-b36f-030d1f8aea9f@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
 <zfTdQiflt_3lfUT2cOiVaQQR7rpt_qjmv03dZ-aZ8ik=.23c75c64-f18c-4567-b36f-030d1f8aea9f@github.com>
Message-ID: <0qEoPiIw-AuMHWVYGJ0rAvD6EJdjXeoh0sM7LcwnH9I=.3dd316ae-84eb-43c4-8a81-529c023ea2ec@github.com>

On Thu, 15 Dec 2022 19:17:22 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Matthew Donovan 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-8249826
>>  - Moved bug numbers to ProblemList and removed @ignore
>>  - 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id
>
> test/jdk/javax/net/ssl/SSLEngine/Basics.java line 29:
> 
>> 27:  * @summary Add non-blocking SSL/TLS functionality, usable with any
>> 28:  *      I/O abstraction
>> 29:  * @ignore 8298867
> 
> Instead of using ignore tag, I would prefer to put these tests in ProblemList with these bug numbers.

Moved bugs to ProblemList and removed ignore tags

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

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

From mpowers at openjdk.org  Thu Dec 15 20:25:03 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 15 Dec 2022 20:25:03 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
Message-ID: <gLKSsKAslTuisGmHDVpEiCzKkjsfuWSSDwrZd-BnX1s=.a527ddc6-4e06-43a3-a48a-3eca3c91d889@github.com>

On Thu, 15 Dec 2022 18:06:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
>> 
>> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
>> 
>> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
>> 
>> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
>> 
>> Benchmark results before:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
>> 
>> 
>> after:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test failure

LGTM

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

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

From dnguyen at openjdk.org  Thu Dec 15 20:43:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:43:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix https and changed URL back

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05

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

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Thu Dec 15 20:55:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 20:55:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <td2m9lDu24tKE3INK9xXuzPGPPNVoHfQYwzgCBkTF2Y=.3f4f2fd3-276e-4f27-a9fb-6bb7bea1a608@github.com>
 <bxawN0XrRjf_HwocX3SD03ihnIENaEb6eqpuOx5KjwY=.265f097f-de75-474e-b835-ef067cb7afde@github.com>
Message-ID: <Wq-WW8kfFkrS08vlPmgmD_ApiBVdboI6hEoARHr72zk=.7d3ca55c-db6e-4734-8724-75cb5d0a2f82@github.com>

On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134:
> 
>> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung
>> 133: artifact.not.found=nicht gefunden
>> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> 
> This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales.

This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction.

I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue.

As discussed with Naoto, these are small edits, and they have been addressed in the latest PR.

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

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 21:16:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 21:16:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <pE7z2olK_Ec3qJO1w1KbXo55BIsYVK7Cu1_MPUMUmkg=.48f8c2f4-0b68-47ba-a46f-d8cb8d17d481@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

Thanks for the update, Damon. Looks good for this drop.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From rhalade at openjdk.org  Thu Dec 15 21:38:05 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 15 Dec 2022 21:38:05 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id [v2]
In-Reply-To: <eEFwn1jmhImAwzofB0bd9h9cgLboN3LGEkR5n7lTjoA=.485cbc6f-ba3f-4c17-8671-20f2ff1bf7c9@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
 <eEFwn1jmhImAwzofB0bd9h9cgLboN3LGEkR5n7lTjoA=.485cbc6f-ba3f-4c17-8671-20f2ff1bf7c9@github.com>
Message-ID: <W62-eTY4ntWKNB0_Ijh8ogNLTKkTxB78gaNvQ9iBrLg=.7da5f3ef-a1c9-45ca-be29-ce7b4cb85507@github.com>

On Thu, 15 Dec 2022 20:07:34 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> - Reviewed the tests and created individual bugs for each.
>> - Updated @ignore tags with appropriate bug #.
>> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.
>
> Matthew Donovan 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-8249826
>  - Moved bug numbers to ProblemList and removed @ignore
>  - 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id

Marked as reviewed by rhalade (Reviewer).

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

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

From valeriep at openjdk.org  Thu Dec 15 22:49:06 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 Dec 2022 22:49:06 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
Message-ID: <ZoB0AjtuowVty0ytL2-qZ1ByVQFUeyzO5OTNdv0gr-I=.eaf4fe16-a219-4024-949c-ea95047cc2a5@github.com>

On Thu, 15 Dec 2022 18:06:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
>> 
>> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
>> 
>> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
>> 
>> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
>> 
>> Benchmark results before:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
>> 
>> 
>> after:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test failure

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 95:

> 93:      *
> 94:      * If obuffer is null/zero-sized, do not allocate a new buffer.
> 95:      * This reduces allocation for AEAD ciphers that never return data from update

AEAD ciphers do return data for update() calls for encryption. Perhaps we should add "when used for decryption" or some other similar wordings to the above sentence? Same goes for the comment in CipherInputStream class.

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

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

From dnguyen at openjdk.org  Thu Dec 15 23:01:35 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 15 Dec 2022 23:01:35 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert double quote as well

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03

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

PR: https://git.openjdk.org/jdk20/pull/35

From naoto at openjdk.org  Thu Dec 15 23:12:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Dec 2022 23:12:06 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <orIjM2vHBgrTyKBL5fjG9TX1ZI8AuJ48PGF2nqlSip0=.7f9e9cb5-0cfa-4985-8bff-aa5ead6f1c6d@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

Marked as reviewed by naoto (Reviewer).

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Good catch!

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:12 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:12 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
Message-ID: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>

On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix https and changed URL back

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:

> 80: 
> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt

error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093
> 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F

Same as "de" translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82:

> 80: 
> 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6
> 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0})

Same as "de" translation.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Why "de-de" was changed to "de"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Why "ja-jp" to "ja"?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37:

> 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages
> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:

> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Why this was changed?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37:

> 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C
> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Same as above.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Thu Dec 15 23:17:15 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 15 Dec 2022 23:17:15 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15:

> 13:   <String Id="ShortcutPromptDlgStartMenuShortcutControlLabel">????????????????????</String>
> 14:   <String Id="InstallDirNotEmptyDlg_Title">[ProductName]??????</String>
> 15:   <String Id="ContextMenuCommandLabel">Open with [ProductName]</String>

Why it was removed in all translations, except English?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:

> 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
> 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 51: error.icon-swap=Failed to update icon for {0}

Why this was removed?

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

PR: https://git.openjdk.org/jdk20/pull/35

From valeriep at openjdk.org  Thu Dec 15 23:21:05 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 Dec 2022 23:21:05 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
Message-ID: <VpSpSYpLPzWjmQMMnkjrFDJJV9mQiYsBA0p9KEGRkTQ=.7d94bb95-f278-4939-8620-c1752bce1100@github.com>

On Thu, 15 Dec 2022 18:06:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
>> 
>> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
>> 
>> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
>> 
>> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
>> 
>> Benchmark results before:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
>> 
>> 
>> after:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test failure

Marked as reviewed by valeriep (Reviewer).

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

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

From ascarpino at openjdk.org  Thu Dec 15 23:30:08 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 15 Dec 2022 23:30:08 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
Message-ID: <FCIDpfI4jJJZ0VUSTRGZ_eqnbO3mY67aIMO3av4K_No=.3d476dae-38dc-4cb6-853f-2b3149b5aa14@github.com>

On Thu, 15 Dec 2022 18:06:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
>> 
>> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
>> 
>> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
>> 
>> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
>> 
>> Benchmark results before:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
>> 
>> 
>> after:
>> 
>> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
>> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
>> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
>> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
>> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test failure

Marked as reviewed by ascarpino (Reviewer).

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

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

From weijun at openjdk.org  Thu Dec 15 23:34:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 Dec 2022 23:34:10 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:

> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},

The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

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

PR: https://git.openjdk.org/jdk20/pull/35

From ascarpino at openjdk.org  Thu Dec 15 23:36:07 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 15 Dec 2022 23:36:07 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <ZoB0AjtuowVty0ytL2-qZ1ByVQFUeyzO5OTNdv0gr-I=.eaf4fe16-a219-4024-949c-ea95047cc2a5@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
 <ZoB0AjtuowVty0ytL2-qZ1ByVQFUeyzO5OTNdv0gr-I=.eaf4fe16-a219-4024-949c-ea95047cc2a5@github.com>
Message-ID: <rKzDGegIbZ5qI1ENr9t6aC8CFSSczwIwob8WK0MzEKY=.c4acc115-c317-4077-a683-09c81adb89cc@github.com>

On Thu, 15 Dec 2022 22:46:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test failure
>
> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 95:
> 
>> 93:      *
>> 94:      * If obuffer is null/zero-sized, do not allocate a new buffer.
>> 95:      * This reduces allocation for AEAD ciphers that never return data from update
> 
> nit: AEAD ciphers do return data for update() calls for encryption. Perhaps we should add "when used for decryption" or some other similar wordings to the above sentence? Same goes for the comment in CipherInputStream class.
> Rest looks fine.

Perhaps it's the way you read the sentence, when I read it bit before your comment, I interpreted the change as an open-ended comment where AEAD may or may not return without being specific.  I'm neutral to changing it to specify encryption vs decryption.

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

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

From valeriep at openjdk.org  Fri Dec 16 00:20:07 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 16 Dec 2022 00:20:07 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <VFBoSznE433XhqEEJa1-OCOLOtWyQXEvVUf61RWGWKA=.0a5fa31f-b758-4fa8-b3cc-d3821b350dbd@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
 <VFBoSznE433XhqEEJa1-OCOLOtWyQXEvVUf61RWGWKA=.0a5fa31f-b758-4fa8-b3cc-d3821b350dbd@github.com>
Message-ID: <2XQdXS5BY0qd4-i8-oXQ5TAnlE9SOSpG6XX4kqDfNLc=.0994b4ca-f9a8-4c21-95ed-6e929c6a5779@github.com>

On Thu, 15 Dec 2022 17:16:35 GMT, Bernd <duke at openjdk.org> wrote:

> BTW while you touch the algorithm documentation, it Liste pkcs#5 which does work with octet strings, but the java api works with char passwords. It should describe that it uses the ucs2 char->bytes method not utf8 (pkcs8 vs pkcs12 if I recommend correctly).
> 
> (Or even better allow both as currently i would still need to use BC for a byte representation in better defined utf8)

Allow both would need a separate RFE. I will ask the doc team to document that only ASCII is supported for SunJCE provider for now. Thanks for the comment~

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

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

From dnguyen at openjdk.org  Fri Dec 16 00:20:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:20:09 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>

On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
> 
>> 80: 
>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
> 
> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?

I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Why "de-de" was changed to "de"?

Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 00:28:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 00:28:14 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
Message-ID: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>

On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix https and changed URL back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
> 
>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Why this was changed?

Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 00:55:07 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:55:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>

On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82:
>> 
>>> 80: 
>>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0})
>>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt
>> 
>> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""?
>
> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?

Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

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

PR: https://git.openjdk.org/jdk20/pull/35

From almatvee at openjdk.org  Fri Dec 16 00:59:08 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 00:59:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <OBPofdj-HAyS2LOEYb9Di6foNnPm0PQYQoQ1AsyGD6o=.daf96361-fae0-488c-b400-6edea72cf6f9@github.com>
Message-ID: <ybG8PSIdt0XyYOo4JF4ozp2yRpZDnPQUpDxoDeFTiCo=.fbe7a6d5-9bc3-4097-bd02-164f015bcaf6@github.com>

On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37:
>> 
>>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl
>> 
>> Why this was changed?
>
> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.

Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 01:05:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 01:05:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
Message-ID: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>

On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted?
>
> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.

I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

>> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file.
>
> Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code.

This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then.

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

PR: https://git.openjdk.org/jdk20/pull/35

From joehw at openjdk.org  Fri Dec 16 01:25:18 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 Dec 2022 01:25:18 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
Message-ID: <ienEQpq9KGQ0-B04HBvRrPpNQDISigGzx4lTtzjuDVY=.7bcc0fd3-51c9-4e51-9684-266a98e521ec@github.com>

On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert double quote as well

The changes in the java.xml area look good to me.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:54 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:54 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert old translation. Fix lang codes

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9

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

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:56 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
 <Bdj4sr53WcCg6vWDmTIfcvVoCxGjbLiCL4Hc-Ydgrvk=.ca1b89df-5ec8-447e-9f0e-7d5f3eb8fa92@github.com>
 <iqZK2YXVbWKWqoQkJhlwxX1sNPCdcJkRKjgWh51KiWg=.9bb3af83-561d-4711-8ec9-585adf10f676@github.com>
Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com>

On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old.
>
> I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then.

The translated text here has been reverted to its original English. The same has been done for its locales.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:38:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:38:58 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <iq23Spi_W4BliCGfF2bJjw1BLca8QcA9EkEvFfPWDwU=.8fe5375d-cd68-46b5-9830-1629ec72ffb5@github.com>
 <x52tNSOxdcs3fdxY8Wusrck38ek1IsYsdrtnRZMnC-M=.c7fde585-c9e8-464b-8d89-1eb81701a465@github.com>
 <NwruB7W8obX6XLW0oYPNwk_hsyRRDQfnjcSQ2IcG0BM=.0bda120a-ca70-470f-9ed9-bdb3f43e958a@github.com>
Message-ID: <AkPK7pgS3BMYAhNKSN0Xz0Jr0ey_vcQHGP8UmdXy1II=.9691952b-cf52-4724-8c48-3496dfa671c8@github.com>

On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
>> 
>>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
>> 
>> Why "de-de" was changed to "de"?
>
> Also not sure why this was changed in the translation. I'm reverting all instances of these language codes.

This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:39:01 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:39:01 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <yAXqJCyxsT6KgDaEqjCnsudaB4zIy8gvPnrQkUkNPCw=.d87796f7-1c29-41b4-9b16-86920924ebed@github.com>
Message-ID: <bbvTT7_7dNA1j9sUSiPADGEnuneemJPFgiiIAI8SsxU=.7e1290eb-107a-458e-a4ee-2cab3b9e7fbf@github.com>

On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed trailing whitespace
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51:
> 
>> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen
>> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen
>> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden
> 
> Why this was removed?

This line was added back to all locales as it was a regression from the translation process.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:45:07 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:45:07 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
Message-ID: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>

On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert double quote as well
>
> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
> 
>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
> 
> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.

I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 03:58:08 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 03:58:08 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

@dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

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

PR: https://git.openjdk.org/jdk20/pull/35

From cjplummer at openjdk.org  Fri Dec 16 04:12:17 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Dec 2022 04:12:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <XK9d6e9V7rnGtOvMP2mHVDwxsaO_cQCWhnehjTarZ_w=.01c61275-fd0e-4532-8a17-a13c16734bb8@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

`src/jdk.jdi/share/classes/com/sun/tools` changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From ssahoo at openjdk.org  Fri Dec 16 05:14:06 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 16 Dec 2022 05:14:06 GMT
Subject: RFR: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id [v2]
In-Reply-To: <eEFwn1jmhImAwzofB0bd9h9cgLboN3LGEkR5n7lTjoA=.485cbc6f-ba3f-4c17-8671-20f2ff1bf7c9@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
 <eEFwn1jmhImAwzofB0bd9h9cgLboN3LGEkR5n7lTjoA=.485cbc6f-ba3f-4c17-8671-20f2ff1bf7c9@github.com>
Message-ID: <Kreq1exuaNSNPNzmDu226Qlb6mRQSreYtm4tQ480f8g=.f39afad4-cfd6-4efe-b2c2-a18006a5738a@github.com>

On Thu, 15 Dec 2022 20:07:34 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> - Reviewed the tests and created individual bugs for each.
>> - Updated @ignore tags with appropriate bug #.
>> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.
>
> Matthew Donovan 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-8249826
>  - Moved bug numbers to ProblemList and removed @ignore
>  - 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id

Marked as reviewed by ssahoo (Committer).

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

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

From almatvee at openjdk.org  Fri Dec 16 05:17:11 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Dec 2022 05:17:11 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <J3GyIIuioqw6EvIvhMXFm2MByz1cylrmF-jSJcyg3RM=.cd6f3f83-a261-4fa1-ab46-c7d017709595@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

jpackage changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/35

From jpai at openjdk.org  Fri Dec 16 05:20:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Dec 2022 05:20:10 GMT
Subject: RFR: 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/
 [v2]
In-Reply-To: <xPbuBa4PTOxT8aNaomQ2LjaFfsjgWTuuqMhIxoNTs9o=.2fd63c3f-6936-43b0-bdd7-c2d3b533a6ee@github.com>
References: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
 <xPbuBa4PTOxT8aNaomQ2LjaFfsjgWTuuqMhIxoNTs9o=.2fd63c3f-6936-43b0-bdd7-c2d3b533a6ee@github.com>
Message-ID: <E4nznSCdzNLYsl8JZQ9ucDuJSsoOxNZ8uNG2vd2emJk=.1c73942a-7cab-4c9d-8bf4-d2fb6c03f050@github.com>

On Wed, 14 Dec 2022 06:35:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo in test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java

Thank you Lance for the review.

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

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

From jpai at openjdk.org  Fri Dec 16 05:20:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Dec 2022 05:20:11 GMT
Subject: Integrated: 8298710: Fix typos in
 test/jdk/sun/security/tools/jarsigner/
In-Reply-To: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
References: <EoFlKmEFdNaNFXl0i5-ysW01AEorA_y5khnl4PJ0c2Y=.9369c802-81ea-48eb-876e-39113b6c2513@github.com>
Message-ID: <yFLKP61uI16lTL7HdpI4cNRmJljQW4na94v8xIxpKMU=.7cbeff4c-1b4b-4a75-9a9b-fc36c41466e3@github.com>

On Wed, 14 Dec 2022 06:17:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes some typos in the files under test/jdk/sun/security/tools/jarsigner/?

This pull request has now been integrated.

Changeset: e41686b4
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e41686b4050d6b32fb451de8af39a78ec8bed0fd
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: lancea

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

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

From djelinski at openjdk.org  Fri Dec 16 08:03:35 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 16 Dec 2022 08:03:35 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v3]
In-Reply-To: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
Message-ID: <4F0JvBsI6dqTO6NwykclFF54NBILh1BzaQvE2jMTWIA=.f7ec7ca2-d047-4258-97c2-5d95711c6bd0@github.com>

> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
> 
> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
> 
> Benchmark results before:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
> 
> 
> after:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  improve wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11693/files
  - new: https://git.openjdk.org/jdk/pull/11693/files/7b295132..1b7a16b1

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

  Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11693.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11693/head:pull/11693

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

From djelinski at openjdk.org  Fri Dec 16 08:03:36 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 16 Dec 2022 08:03:36 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <rKzDGegIbZ5qI1ENr9t6aC8CFSSczwIwob8WK0MzEKY=.c4acc115-c317-4077-a683-09c81adb89cc@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
 <ZoB0AjtuowVty0ytL2-qZ1ByVQFUeyzO5OTNdv0gr-I=.eaf4fe16-a219-4024-949c-ea95047cc2a5@github.com>
 <rKzDGegIbZ5qI1ENr9t6aC8CFSSczwIwob8WK0MzEKY=.c4acc115-c317-4077-a683-09c81adb89cc@github.com>
Message-ID: <dTFiYHZo9wTDP-8HIy9ACKy1tYwmw0T4abvmzBYBsCY=.07122393-a727-4583-be9f-ad376ddb626a@github.com>

On Thu, 15 Dec 2022 23:33:21 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 95:
>> 
>>> 93:      *
>>> 94:      * If obuffer is null/zero-sized, do not allocate a new buffer.
>>> 95:      * This reduces allocation for AEAD ciphers that never return data from update
>> 
>> nit: AEAD ciphers do return data for update() calls for encryption. Perhaps we should add "when used for decryption" or some other similar wordings to the above sentence? Same goes for the comment in CipherInputStream class.
>> Rest looks fine.
>
> Perhaps it's the way you read the sentence, when I read it bit before your comment, I interpreted the change as an open-ended comment where AEAD may or may not return without being specific.  I'm neutral to changing it to specify encryption vs decryption.

That's a good suggestion; I changed the wording now. What do you think?

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

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

From dfuchs at openjdk.org  Fri Dec 16 09:22:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:22:29 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:

> 32: # Translators please note do not translate the options themselves
> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4n
 glichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--vali
 date-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilfe
  zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\n
                   \
> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f
 \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n

This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files`

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

PR: https://git.openjdk.org/jdk20/pull/35

From dfuchs at openjdk.org  Fri Dec 16 09:48:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Dec 2022 09:48:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>

On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
> 
>> 32: # Translators please note do not translate the options themselves
>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E4
 nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--val
 idate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hilf
 e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]\
 n                  \
>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument 
 f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
> 
> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`

I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
Find-in-files revealed that the source is still using --disable- at files. See:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

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

PR: https://git.openjdk.org/jdk20/pull/35

From alanb at openjdk.org  Fri Dec 16 10:13:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Dec 2022 10:13:04 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <uCw2LCc01qL0w9UYrWT7tMoQOhNIB_VaKm4kGc_Z9Vw=.e52a56bf-c4dc-454c-b2a2-e8796c284d66@github.com>
Message-ID: <s7AGBhlHie3pq-e0NT_2pQ3hWQ15Oyt1dR_t2D9YM3g=.01648378-0fb2-4f51-a9bf-1f5066e40158@github.com>

On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team.

@DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages.

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

PR: https://git.openjdk.org/jdk20/pull/35

From ssahoo at openjdk.org  Fri Dec 16 12:38:05 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 16 Dec 2022 12:38:05 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
Message-ID: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>

On Mon, 5 Dec 2022 19:52:18 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8295087
>  - Added an extra line to the end of the policy file.
>  - AssertThrows an exception in InconsistentEntries test.
>  - Refactored to use testng framework for test enviroment setup.
>  - Converted security manual tests to automated tests.

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:

> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
> 51:     private static final String TEST_SRC = System.getProperty("test.src");
> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",

This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.

test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 37:

> 35:  * @summary standard extensions path is hard-coded in default
> 36:  *      system policy file
> 37:  * @run main/othervm/policy=ExtDirs.policy/secure=default ExtDirs

May be "/secure=default" is optional here.

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

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

From naoto at openjdk.org  Fri Dec 16 13:46:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 13:46:02 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <FkE6xWy1f_931bWkjLEGooZJgRw31mF1UNMMMjICFUQ=.90de6a4a-57c3-41c4-8c9c-2c582f4696c0@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop.

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

PR: https://git.openjdk.org/jdk20/pull/35

From weijun at openjdk.org  Fri Dec 16 15:05:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 15:05:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>

On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75:
>> 
>>> 73:                 "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey
>>> 74:         {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>>> 75:         {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"},
>> 
>> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file.
>
> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?

Yes, you can replace all "??????" (that is not after ""???") to "?????????".

There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 16:53:59 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 16:53:59 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
Message-ID: <eKoHNhbn6nSejGumOAm87rtEJh5ZyQVEaFblB2t7jOA=.3366bc22-6709-479c-a23a-d41f1aa49b33@github.com>

On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert old translation. Fix lang codes

Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:02:42 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:42 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing dash

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83

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

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:02:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:02:44 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <f_RwCzQ-V2DGkXrUYI6GjNRyZHAvzbzz3Yx1iZV-VjU=.acf752dc-d1cf-407d-a58e-a5da733bd76e@github.com>
 <MC7rYWqlI84Gv7KqwscR0nXPVEKfDfNjIheXZsUkQZM=.65548e00-c87b-49da-bf02-d03f6365dbcf@github.com>
 <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com>
Message-ID: <uipT8s-ZFfoJgsIH3b7vP8Pgu15BiK3gx4EmIZ09pyQ=.c1ead06a-8b31-41d3-8601-52c4ed8d854e@github.com>

On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34:
>> 
>>> 32: # Translators please note do not translate the options themselves
>>> 33: java.launcher.opt.footer = \    -cp <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    -classpath <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n    --class-path <Klassensuchpfad mit Verzeichnissen und ZIP-/JAR-Dateien>\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n                  und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n    -p <Modulpfad>\n    --module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist.\n    --upgrade-module-path <Modulpfad>...\n                  Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n                  ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n                  Module im Laufzeitimage ersetzen\n    --add-modules <Modulname>[,<Modulname>...]\n                  Root-Module, die zus\u00E4tzlich zum anf\u00E
 4nglichen Modul aufgel\u00F6st werden sollen.\n                  <Modulname> kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n                  ALL-MODULE-PATH.\n    --enable-native-access <Modulname>[,<Modulname>...]\n                  Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n                  <Modulname> kann auch ALL-UNNAMED lauten.\n    --list-modules\n                  Listet beobachtbare Module auf und beendet den Vorgang\n    -d <Modulname>\n    --describe-module <Modulname>\n                  Beschreibt ein Modul und beendet den Vorgang\n    --dry-run     Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n                  Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n                  Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n    --validate-modules\n                  Validiert alle Module und beendet den Vorgang\n                  Die Option "--va
 lidate-modules" kann n\u00FCtzlich sein, um\n                  Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n    -D<Name>=<Wert>\n                  Legt eine Systemeigenschaft fest\n    -verbose:[class|module|gc|jni]\n                  Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n    -version      Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n    --version      Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n    -showversion  Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n    --show-version\n                  Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n    --show-module-resolution\n                  Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n    -? -h -help\n                  Gibt diese Hilfemeldung an den Fehlerstream aus\n    --help        Gibt diese Hilfemeldung an den Outputstream aus\n    -X            Gibt Hil
 fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n    --help-extra  Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n    -ea[:<packagename>...|:<classname>]\n    -enableassertions[:<packagename>...|:<classname>]\n                  Aktiviert Assertions mit angegebener Granularit\u00E4t\n    -da[:<packagename>...|:<classname>]\n    -disableassertions[:<packagename>...|:<classname>]\n                  Deaktiviert Assertions mit angegebener Granularit\u00E4t\n    -esa | -enablesystemassertions\n                  Aktiviert System-Assertions\n    -dsa | -disablesystemassertions\n                  Deaktiviert System-Assertions\n    -agentlib:<libname>[=<options>]\n                  L\u00E4dt die native Agent Library <libname>. Beispiel: -agentlib:jdwp\n                  siehe auch -agentlib:jdwp=help\n    -agentpath:<pathname>[=<options>]\n                  L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n    -javaagent:<jarpath>[=<options>]
 \n                  \
>>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n    -splash:<imagepath>\n                  Zeigt den Startbildschirm mit einem angegebenen Bild an\n                  Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n                  falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n                  muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n                  Das am besten geeignete angegebene skalierte Bild wird\n                  automatisch ausgew\u00E4hlt.\n                  Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n    @argument files\n                  Eine oder mehrere Argumentdateien mit Optionen\n    -disable- at files\n                  Verhindert die weitere Erweiterung von Argumentdateien\n    --enable-preview\n                  L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument
  f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --<Name>=<Wert> oder\n--<Name> <Wert> verwenden.\n
>> 
>> This change seems wrong, unless I'm mistaken the option name is still  `--disable- at files`, not `-disable- at files`
>
> I'm unfortunately not familiar with any of these resources files,  and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation.
> Find-in-files revealed that the source is still using --disable- at files. See:
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121

Thanks for taking a look. I fixed this removed dash from the translation in the latest PR.

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

PR: https://git.openjdk.org/jdk20/pull/35

From prr at openjdk.org  Fri Dec 16 17:28:56 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Dec 2022 17:28:56 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v6]
In-Reply-To: <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
Message-ID: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>

On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing dash

src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:

> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
> 429: 
> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6

I was asked to review SwingSet2 changes but this isn't code.
But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:42:17 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:42:17 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v7]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <joe6G_LIkLeUlpKw1IqhH00g23fEFnyi4ItJUUbQDxk=.89bfe214-866a-4e27-98eb-ba925b45dd05@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert swingset. Consistency in CN

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea

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

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:45:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:45:05 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
Message-ID: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>

On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK?
>
> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
> 
> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.

Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 

Could you re-review the current changes for this drop?

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:19 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:19 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v8]
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <HHXCd5IsWRZEjWoBRIxu95AEttEQXvgPx-uzGBjHn8I=.34a5040a-1cf9-4ac2-b664-b710cab2e7cf@github.com>

> Open l10n drop
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Swingset newline

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/35/files
  - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 17:51:20 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 17:51:20 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v5]
In-Reply-To: <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <scvd5xE_Bjf0z8Q_DD1Ri4KSI64RhpsxuqIxdiTIbmw=.b58bccb0-64b3-4239-8f38-7a4c1804b14d@github.com>
 <FmlUsetmec4ajWf41qIKWiV_d6svun82djbObUKfyao=.bb2b49e5-3426-4d2d-9f8c-1167d867889d@github.com>
Message-ID: <Z2W3BZQLpjHfGyASnkwSyvXnU9U0eou4iovSpNWPrX8=.896c41fd-df2d-4cac-be80-7cb28c32959c@github.com>

On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert old translation. Fix lang codes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430:
> 
>> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A
>> 429: 
>> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6
> 
> I was asked to review SwingSet2 changes but this isn't code.
> But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble.

Thanks. I removed the changes to swingset's translation to avoid causing any issues.

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Fri Dec 16 17:54:56 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 16 Dec 2022 17:54:56 GMT
Subject: Integrated: 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o
 bug-id
In-Reply-To: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
References: <0oGZxDc-gKJNge9TOpyA8somOg0xAqpH0m3UaglF5x4=.538d3387-bbce-4c01-a9d2-dc4b88ffca8f@github.com>
Message-ID: <3IkHl7eDS4o6n2tLynxiHocMrv_MVOPDqlFPmV-iQwE=.ee0e6307-b29f-4f16-b017-a886330c8c0b@github.com>

On Thu, 15 Dec 2022 16:11:02 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> - Reviewed the tests and created individual bugs for each.
> - Updated @ignore tags with appropriate bug #.
> - Removed @ignore for IllegalHandshakeMessage.java; the test passes with the expected result.

This pull request has now been integrated.

Changeset: bf9a8ce0
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf9a8ce0bb975a3d50e92148f92850ef930d64b0
Stats:     16 lines in 8 files changed: 7 ins; 5 del; 4 mod

8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id

Reviewed-by: xuelei, rhalade, ssahoo

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

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

From weijun at openjdk.org  Fri Dec 16 18:02:55 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Dec 2022 18:02:55 GMT
Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
 <HaHsLn9djrTcOHaSSn__LO9-D3qItYeGu62lYjuu-mA=.417e40f5-f02c-4019-9a3f-25fecb1d938b@github.com>
 <apmyl72NuiCfwAbiJ757W8j59iQar67gH1cIVV757n8=.eeda79d2-99d1-4380-ae15-6d69e8446743@github.com>
 <ZcKFnXSYxP1CuvlfZvENNb3orDWrb4a1Jy8Zkh0KFqI=.ce653817-d7bf-4c64-b505-72a8a06ce590@github.com>
 <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com>
 <ImfItIZ3kWNbX8DHMnA4-zo1_fkH8J_A6-1ZiRzRNR8=.fed31abb-ab70-440f-90ad-902588875929@github.com>
Message-ID: <szezmXXF_0qzSfcp7mcIRk885jnyJf63o7prZfi2VJ8=.e6528252-60de-45c9-9bbd-0157164d890f@github.com>

On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Yes, you can replace all "??????" (that is not after ""???") to "?????????".
>> 
>> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.
>
> Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. 
> 
> Could you re-review the current changes for this drop?

The updated file looks fine to me. Thanks.

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

PR: https://git.openjdk.org/jdk20/pull/35

From dnguyen at openjdk.org  Fri Dec 16 21:18:58 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 16 Dec 2022 21:18:58 GMT
Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update -
 msgdrop 10
In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com>
Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com>

On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop
> All tests passed

This pull request has now been integrated.

Changeset: c997b5bf
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1
Stats:     1128 lines in 99 files changed: 783 ins; 198 del; 147 mod

8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10

Reviewed-by: achung, naoto, joehw, cjplummer, almatvee

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

PR: https://git.openjdk.org/jdk20/pull/35

From duke at openjdk.org  Sat Dec 17 01:45:48 2022
From: duke at openjdk.org (Bernd)
Date: Sat, 17 Dec 2022 01:45:48 GMT
Subject: RFR: 8288050: Add support of SHA-512/224 and SHA-512/256 to the
 PBKDF2 and PBES2 impls in SunJCE provider [v4]
In-Reply-To: <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
References: <BIqMpeHhMJczYmGl-hCv2aPigEb7Xop0BaVNMRSLiw8=.dbff3948-5ad5-4044-abaa-c573c4c0f276@github.com>
 <VBOAB47_RSsyvuN9KClJHzjoj3tmSXI80J1dk_T7bk8=.8d2e7311-512a-4dd9-906e-d025cdb35a43@github.com>
Message-ID: <TSRAAqsI6EXuJq7yEWN3ZdU5TwGLWLSsf7mZNlY-Olg=.87e47673-51f9-4b02-a1a6-2fd1a75b5e4d@github.com>

On Wed, 14 Dec 2022 00:23:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This RFE enhances existing PBE algorithms with the "SHA512/224" and "SHA512/256" support. 
>> Current transformation parsing in javax.crypto.Cipher class is re-written to handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names. Existing tests are updated with the additional new algorithms.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedbacks

I checked again, it is in the Javadoc, but a bit hidden since it?s not listed near the algorithm name (in the JCE algorithm names doc).

the PBEKey limits it to single byte ASCII only: https://github.com/openjdk/jdk/blob/6dc4d891c3ad043405c65e0e0eeef28e9e5a2156/src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java#L69 (which would be compat with utf8), that is indeed a good info to document that restriction as the Javadoc only says ?takes low byte?.

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/spec/PBEKeySpec.html

it also mentions that the pkcs12 factory uses ucs2 (well ?2 bytes?). But still would be nice to have that info in the algorithm spec doc as well.

Regarding a pkcs8 mode with utf8, what?s the easiest to propose a rfe for a non-commited?

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

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

From hannesw at openjdk.org  Mon Dec 19 16:35:32 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Dec 2022 16:35:32 GMT
Subject: [jdk20] RFR: JDK-8277074: Qualified exported types show up in JavaDoc
Message-ID: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>

This `noreg-doc` PR has been moved over from the mainline repository, the original PR is openjdk/jdk#11163. 

The purpose is to hide internal classes in generated documentation by adding doc comments containing a @hidden tag. I verified the fix by making sure the internal vector and event classes no longer show up in the generated documentation tree.

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

Commit messages:
 - JDK-8277074: Qualified exported types show up in JavaDoc

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

PR: https://git.openjdk.org/jdk20/pull/56

From psandoz at openjdk.org  Mon Dec 19 18:08:50 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 19 Dec 2022 18:08:50 GMT
Subject: [jdk20] RFR: JDK-8277074: Qualified exported types show up in
 JavaDoc
In-Reply-To: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
References: <6mDlss6DZr5nYR9EgFeDBkVZ4ky3IGvePyNNRy49prM=.eff849fc-b9e9-4d04-8217-4bdda3c14cd1@github.com>
Message-ID: <2XGIFQRDGs9sinEkshXPKrbqnUcvMoubo9hu1WRKazs=.4670995a-76fe-4d51-ad4d-029986107d2d@github.com>

On Mon, 19 Dec 2022 16:28:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This `noreg-doc` PR has been moved over from the mainline repository, the original PR is openjdk/jdk#11163. 
> 
> The purpose is to hide internal classes in generated documentation by adding doc comments containing a @hidden tag. I verified the fix by making sure the internal vector and event classes no longer show up in the generated documentation tree.

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/56

From valeriep at openjdk.org  Mon Dec 19 20:11:49 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 19 Dec 2022 20:11:49 GMT
Subject: RFR: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption [v2]
In-Reply-To: <dTFiYHZo9wTDP-8HIy9ACKy1tYwmw0T4abvmzBYBsCY=.07122393-a727-4583-be9f-ad376ddb626a@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
 <MAn5z4pHywMN4YoYz-xWX0ADZMeI2egAs-4B3Pk1GvU=.72c9a009-8f30-46d8-bc69-75880fb73b95@github.com>
 <ZoB0AjtuowVty0ytL2-qZ1ByVQFUeyzO5OTNdv0gr-I=.eaf4fe16-a219-4024-949c-ea95047cc2a5@github.com>
 <rKzDGegIbZ5qI1ENr9t6aC8CFSSczwIwob8WK0MzEKY=.c4acc115-c317-4077-a683-09c81adb89cc@github.com>
 <dTFiYHZo9wTDP-8HIy9ACKy1tYwmw0T4abvmzBYBsCY=.07122393-a727-4583-be9f-ad376ddb626a@github.com>
Message-ID: <drg01rb8B9pO3hYX6Fp_uo-LE7BBIuWc5kqeTzETNaw=.f74cc8a4-ffe3-4bbd-81c9-8ff8156843a7@github.com>

On Fri, 16 Dec 2022 07:58:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Perhaps it's the way you read the sentence, when I read it bit before your comment, I interpreted the change as an open-ended comment where AEAD may or may not return without being specific.  I'm neutral to changing it to specify encryption vs decryption.
>
> That's a good suggestion; I changed the wording now. What do you think?

Look good, thanks!

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

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

From djelinski at openjdk.org  Tue Dec 20 10:31:03 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 20 Dec 2022 10:31:03 GMT
Subject: Integrated: 8298865: Excessive memory allocation in CipherOutputStream
 AEAD decryption
In-Reply-To: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
References: <A_VuZUJj6tbxG02QgL3ar_1u4Ezls_4QKpcFOm6MpvU=.a4995ce3-9c41-4304-be12-204f17ba3cd8@github.com>
Message-ID: <jtwJ7ezdGbpqYjsAa1rWznnuROIJoIADdz0aVCL83qE=.6bbea0df-a669-44e9-924f-1fdaac8394d2@github.com>

On Thu, 15 Dec 2022 14:05:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies `CipherOutputStream` to avoid pointless memory allocations when decrypting data using AEAD ciphers. This is related to #11597, which fixed a similar issue in `CipherInputStream`.
> 
> `Cipher.update` does not output any data when doing AEAD decryption; all data is buffered, and is later returned in one shot from `doFinal`. `Cipher.getOutputSize` returns the buffer size required by `doFinal`, which increases after every `update`, triggering new allocation in `ensureCapacity`.
> 
> This patch addresses the issue by calling the `update` overload that returns the output buffer until one of the update calls returns some data. When that happens, we know that the cipher does not buffer everything until `doFinal`, and revert to original behavior.
> 
> This PR adds a new benchmark for AES/GCM encryption and decryption using `CipherOutputStream`.
> 
> Benchmark results before:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   27949,624 ?  301,408  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40      20,730 ?    0,875  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  175358,641 ? 4235,808  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2588,111 ?   35,469  ops/s
> 
> 
> after:
> 
> Benchmark                         (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score      Error  Units
> AESGCMCipherOutputStream.decrypt       16384          128              thrpt   40   69644,217 ? 1081,032  ops/s
> AESGCMCipherOutputStream.decrypt     1048576          128              thrpt   40     949,667 ?    9,431  ops/s
> AESGCMCipherOutputStream.encrypt       16384          128              thrpt   40  173144,038 ? 3279,149  ops/s
> AESGCMCipherOutputStream.encrypt     1048576          128              thrpt   40    2514,840 ?   87,935  ops/s

This pull request has now been integrated.

Changeset: 36de61c4
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36de61c460d7038019294293143e420dfcce2936
Stats:     159 lines in 3 files changed: 152 ins; 0 del; 7 mod

8298865: Excessive memory allocation in CipherOutputStream AEAD decryption

Reviewed-by: valeriep, ascarpino

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

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

From jwilhelm at openjdk.org  Tue Dec 20 11:13:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:13:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298784: JFR: Test chunk integrity
 - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false"
 - 4958969: ObjectOutputStream example leads to non-working code
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
 - 8277074: Qualified exported types show up in JavaDoc
 - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831

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

Changes: https://git.openjdk.org/jdk/pull/11739/files
  Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

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

From jwilhelm at openjdk.org  Tue Dec 20 11:47:31 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:31 GMT
Subject: RFR: Merge jdk20 [v2]
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <FnOGkSoOkKJfJ5JjgZo7uwEF2JILRWkjhHgWx1sprIc=.38ff283a-01ab-401c-9411-f0d8c86702b6@github.com>

> Forwardport JDK 20 -> JDK 21

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

 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption
   
   Reviewed-by: valeriep, ascarpino
 - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException
   
   Reviewed-by: serb
 - 8298974: Add ftcolor.c to imported freetype sources
   
   Reviewed-by: serb
 - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
   
   Reviewed-by: serb, honkar
 - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943
   
   Reviewed-by: vromero
 - 8298943: Missing escapes for single quote marks in compiler.properties
   
   Reviewed-by: jjg
 - 8298701: Cleanup SA entries in ProblemList-zgc.txt.
   
   Reviewed-by: sspitsyn, amenkov
 - 8298470: Short cut java.lang.Object super class loading
   
   Reviewed-by: dholmes, iklam
 - 8299022: Linux ppc64le and s390x build issues after JDK-8160404
   
   Reviewed-by: mdoerr, lucy
 - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831

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

Changes: https://git.openjdk.org/jdk/pull/11739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01
  Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

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

From jwilhelm at openjdk.org  Tue Dec 20 11:47:33 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <pk7xFH2bCEPTLw_KlI3RkDUTMMlze8j0j2fNKoqnm5Q=.49972633-6c2a-41af-be30-114c9f119772@github.com>

On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: c5a4a7a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0
Stats:     2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod

Merge

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

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

From bhuang at openjdk.org  Tue Dec 20 19:07:58 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:07:58 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
Message-ID: <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>

On Fri, 16 Dec 2022 11:48:54 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Bill Huang 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8295087
>>  - Added an extra line to the end of the policy file.
>>  - AssertThrows an exception in InconsistentEntries test.
>>  - Refactored to use testng framework for test enviroment setup.
>>  - Converted security manual tests to automated tests.
>
> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:
> 
>> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
>> 51:     private static final String TEST_SRC = System.getProperty("test.src");
>> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",
> 
> This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.

Good points. I searched the entire repo and this is the only instance that uses the "testlimited" with default_local.policy. Looking over the logic, the test sets the crypto.policy property to "testlimited". So I am wondering if the "testlimited" is created for test purposes. If so, are we allowed to rename "testlimited" to be more specific, eg. "testcryptoperms"? 
`Security.setProperty("crypto.policy", "testlimited");`

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

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

From bhuang at openjdk.org  Tue Dec 20 19:13:12 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:13:12 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
Message-ID: <wilOMw5G9maJsZQIghLzPG0VBC42NEwCzkk23WHD5Fg=.ddcd0d7c-2513-41f9-9106-90334a553c96@github.com>

On Fri, 16 Dec 2022 12:06:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Bill Huang 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8295087
>>  - Added an extra line to the end of the policy file.
>>  - AssertThrows an exception in InconsistentEntries test.
>>  - Refactored to use testng framework for test enviroment setup.
>>  - Converted security manual tests to automated tests.
>
> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 37:
> 
>> 35:  * @summary standard extensions path is hard-coded in default
>> 36:  *      system policy file
>> 37:  * @run main/othervm/policy=ExtDirs.policy/secure=default ExtDirs
> 
> May be "/secure=default" is optional here.

Yes, you are right and we can remove the /secure. According to the JTReg spec.
`If the /secure option is not used then the default security manager will be installed.`

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

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

From bhuang at openjdk.org  Tue Dec 20 19:23:10 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 20 Dec 2022 19:23:10 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/32b656ca..c6521f21

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

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

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

From simonis at openjdk.org  Tue Dec 20 23:50:15 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 20 Dec 2022 23:50:15 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v2]
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <rNZg6RYRu03yw6dMjorAokiPb_VyFyzIQWXIaN5N0Qc=.f4faaea9-c6c7-497b-a81e-e95b2f09226a@github.com>

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:

 - Some refactoring and simplification. Moved most of the implementation from SessionTicketExtension to SSLSessionContextImpl
 - Moving currentKeyID/keyHashMap to SSLSessionContextImpl as requested by @XueleiFan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11590/files
  - new: https://git.openjdk.org/jdk/pull/11590/files/13e32894..5e862c49

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

  Stats: 124 lines in 3 files changed: 62 ins; 54 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11590.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11590/head:pull/11590

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

From simonis at openjdk.org  Tue Dec 20 23:50:15 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 20 Dec 2022 23:50:15 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
Message-ID: <jf7NeVIfDrFDwxdX5vkdgkTaGdSXG205LyDzBlNlSeU=.d8b7f1f8-2568-4b24-9c35-9d6f3cf4cbdc@github.com>

On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
>> The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:
> 
> That's obviously not the expected behaviors.  It is a good catch for the `static currentKeyID` issue.
> 
> What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`?  I would like to have SSLContextImpl focusing on configuration.

Hi @XueleiFan,

I've moved `keyHashMap` and `currentKeyID` into `SSLSessionContextImpl` as you've requested and also did some refactoring and simplification (i.e. moved most of the implementation from `SessionTicketExtension` to `SSLSessionContextImpl`).

Can you please have a look at the new version?

Thanks,
Volker

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

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

From duke at openjdk.org  Wed Dec 21 00:25:55 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 21 Dec 2022 00:25:55 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v2]
In-Reply-To: <rNZg6RYRu03yw6dMjorAokiPb_VyFyzIQWXIaN5N0Qc=.f4faaea9-c6c7-497b-a81e-e95b2f09226a@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <rNZg6RYRu03yw6dMjorAokiPb_VyFyzIQWXIaN5N0Qc=.f4faaea9-c6c7-497b-a81e-e95b2f09226a@github.com>
Message-ID: <29ydypeGRfZ14CuXOAqWrR7snWYs9cD0vFPP01wVXRw=.59315ba0-6123-423c-909f-372f48135dd5@github.com>

On Tue, 20 Dec 2022 23:50:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some refactoring and simplification. Moved most of the implementation from SessionTicketExtension to SSLSessionContextImpl
>  - Moving currentKeyID/keyHashMap to SSLSessionContextImpl as requested by @XueleiFan

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 75:

> 73:     private int timeout;                // timeout in seconds
> 74: 
> 75:     private int currentKeyID = new SecureRandom().nextInt();

Could this instantiation of new SecureRandom become a concurrency bottleneck on entropy? Should the SecureRandom from SSLContext be injected to constructor?

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 195:

> 193:                     // Suppress
> 194:                 }
> 195:                 keyHashMap.remove(entry.getKey());

Would it be worth using the entrySet iterator to remove the entry as opposed to looking it up? Should the key be removed from entries before destroying so that another thread doesn't read a destroyed key?

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

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

From ssahoo at openjdk.org  Wed Dec 21 05:32:52 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 21 Dec 2022 05:32:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <9qHBH4y4aFfz5kjAB-2E_qeDbR_hHZu37eAFSznLm_k=.833859a4-01bf-4244-abb0-79e22901fb44@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Marked as reviewed by ssahoo (Committer).

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

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

From ssahoo at openjdk.org  Wed Dec 21 05:32:54 2022
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 21 Dec 2022 05:32:54 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]
In-Reply-To: <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <uw2kQJPBcg5iPyVZGL-BiSMkIK7S2htYcOyOTSi_1-w=.2b19fdf9-5978-4ded-b2e9-3d228c586fd6@github.com>
 <uDwwI-PKA1x-jZ1noAhf3jmID9VyD2fBeBGYfs__wpg=.05c55abe-673f-4aac-86d3-35c9c51ad3cf@github.com>
 <XyDXua4yOaC8Jul8EY-7-KETHCJeCUqdkPtvOoO4ib0=.c488518f-35b2-46a6-92f7-b86d8da84943@github.com>
Message-ID: <EYdknAXN1rmWTizxAkSFplPjCuDlpurVCyOfQI02YLo=.4d5933d2-d3d1-47dc-9338-846355f41163@github.com>

On Tue, 20 Dec 2022 19:05:13 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 52:
>> 
>>> 50:     private static final String JDK_HOME = System.getProperty("test.jdk");
>>> 51:     private static final String TEST_SRC = System.getProperty("test.src");
>>> 52:     private static final Path POLICY_DIR = Paths.get(JDK_HOME, "conf", "security",
>> 
>> This doesn't looks like a safe Test to be automated. Can it create conflict with any other existing Test requiring "testlimited" with  default_local.policy? This need to be verified. Also changing anything inside an installed JDK probably not a good choice. It's just a thought from my side and it could be different for others.
>
> Good points. I searched the entire repo and this is the only instance that uses the "testlimited" with default_local.policy. Looking over the logic, the test sets the crypto.policy property to "testlimited". So I am wondering if the "testlimited" is created for test purposes. If so, are we allowed to rename "testlimited" to be more specific, eg. "testcryptoperms"? 
> `Security.setProperty("crypto.policy", "testlimited");`

As long as it create no conflict with other Tests at runtime.. i am fine to keep it same.

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

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

From simonis at openjdk.org  Wed Dec 21 13:26:51 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 21 Dec 2022 13:26:51 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v2]
In-Reply-To: <29ydypeGRfZ14CuXOAqWrR7snWYs9cD0vFPP01wVXRw=.59315ba0-6123-423c-909f-372f48135dd5@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <rNZg6RYRu03yw6dMjorAokiPb_VyFyzIQWXIaN5N0Qc=.f4faaea9-c6c7-497b-a81e-e95b2f09226a@github.com>
 <29ydypeGRfZ14CuXOAqWrR7snWYs9cD0vFPP01wVXRw=.59315ba0-6123-423c-909f-372f48135dd5@github.com>
Message-ID: <CPw_otHC6q0SDWnifjjMy0cPk7B8F8TtWlm3WWOjQas=.5a02361e-78a0-4bc1-8244-e76d93bf7823@github.com>

On Wed, 21 Dec 2022 00:22:37 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some refactoring and simplification. Moved most of the implementation from SessionTicketExtension to SSLSessionContextImpl
>>  - Moving currentKeyID/keyHashMap to SSLSessionContextImpl as requested by @XueleiFan
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 75:
> 
>> 73:     private int timeout;                // timeout in seconds
>> 74: 
>> 75:     private int currentKeyID = new SecureRandom().nextInt();
> 
> Could this instantiation of new `SecureRandom` become a concurrency bottleneck on entropy? Should the `SecureRandom` from `SSLContext` be injected to constructor (though there's currently a slightly inverted dependency as `SSLContextImpl` creates client & server `SSLSessionContextImpl`s in its constructor, but the `SecureRandom` is set on `SSLContextImpl::engineInit`)?
> 
> Also note the comment in `SSLContextImpl::engineInit`:
> 
> https://github.com/openjdk/jdk/blob/5e862c49ea74a408d32812d96ee15324a342a585/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L122-L133

Hm, I'm not sure if this results in a real problem but I agree that it is better to be on the safe side :)

>From my understanding (and please correct me if I'm wrong) `SSLContextImpl::engineInit()` has to be called before we can start to negotiate a connection and create a session key (i.e. before `SSLContextImpl::getKey()` and subsequently `SSLSessionContextImpl::getCurrentKeyID()` will be called for the first time on a context).

This means that we can use the random "*priming date*" which is created in `SSLContextImpl::engineInit()` anyway (thanks for that link :) to initialize `SSLSessionContextImpl::currentKeyID` and don't need any additional call to `SecureRandom` at all.

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

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

From simonis at openjdk.org  Wed Dec 21 14:50:05 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 21 Dec 2022 14:50:05 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v2]
In-Reply-To: <29ydypeGRfZ14CuXOAqWrR7snWYs9cD0vFPP01wVXRw=.59315ba0-6123-423c-909f-372f48135dd5@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <rNZg6RYRu03yw6dMjorAokiPb_VyFyzIQWXIaN5N0Qc=.f4faaea9-c6c7-497b-a81e-e95b2f09226a@github.com>
 <29ydypeGRfZ14CuXOAqWrR7snWYs9cD0vFPP01wVXRw=.59315ba0-6123-423c-909f-372f48135dd5@github.com>
Message-ID: <IiUIiJRKdNPS02rqONqWzAekJNrD_L16jQt9y20FyqI=.1dd60bd8-fcb1-47e0-9343-a873a0f319f6@github.com>

On Wed, 21 Dec 2022 00:10:08 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some refactoring and simplification. Moved most of the implementation from SessionTicketExtension to SSLSessionContextImpl
>>  - Moving currentKeyID/keyHashMap to SSLSessionContextImpl as requested by @XueleiFan
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 195:
> 
>> 193:                     // Suppress
>> 194:                 }
>> 195:                 keyHashMap.remove(entry.getKey());
> 
> Would it be worth using the entrySet iterator to remove the entry as opposed to looking it up? Should the key be removed from entries before destroying so that another thread doesn't read a destroyed key?

I've did the changes you've proposed. But notice that already the initial implementation had a race between key usage and destruction (because there hasn't been and still is no synchronization between getting and deleting a session key) and even with your proposed change the race still exists. I.e. a thread A can get a key which was is about to expire. Then, just before A uses the key for decrypting a session ticket, another thread B destroys the key just after it expired but before it is used by A. However, as I've already explained before, that's not fatal. It will just lead to the rejection of the session and re-negotiation of the connection. With the default settings where keys IDs are changed (and expired session keys are deleted) every 60 minutes and session keys remain valid for 24 hours, this will also be a very unlikely event, so I suppose it is acceptable.

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

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

From simonis at openjdk.org  Wed Dec 21 15:05:13 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 21 Dec 2022 15:05:13 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11590/files
  - new: https://git.openjdk.org/jdk/pull/11590/files/5e862c49..64905b3d

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

  Stats: 22 lines in 2 files changed: 13 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11590.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11590/head:pull/11590

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

From rhalade at openjdk.org  Wed Dec 21 18:57:55 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 18:57:55 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:

> 31: 
> 32: /*
> 33:  * @test

Why are these tags duplicated here?

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

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

From rhalade at openjdk.org  Wed Dec 21 18:57:57 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 18:57:57 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
 <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
 <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>
Message-ID: <ZZzxDukj_fA9LOPrVNIe6oeOmsuTrbFFEt_TpLuNAqk=.e7a6236b-cd17-407e-8679-81249907d385@github.com>

On Wed, 19 Oct 2022 16:49:33 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?
>
> Its fine, ignore my previous comment.

you can add multiple run tags under same test tag, no need to repeat tag, bug, and summary tags.

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

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

From bhuang at openjdk.org  Wed Dec 21 20:00:51 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 21 Dec 2022 20:00:51 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
Message-ID: <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>

On Wed, 21 Dec 2022 18:51:32 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>
> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:
> 
>> 31: 
>> 32: /*
>> 33:  * @test
> 
> Why are these tags duplicated here?

Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.

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

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

From xuelei at openjdk.org  Wed Dec 21 20:33:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 21 Dec 2022 20:33:58 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
Message-ID: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>

On Wed, 21 Dec 2022 15:05:13 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 80:

> 78: 
> 79:     protected SessionTicketExtension.StatelessKey getKey() {
> 80:         SessionTicketExtension.StatelessKey ssk = serverCache.getKey();

I may change the serverCache from private to package private, and move the getKey() methods into SSLSessionContextImpl:

-    private final SSLSessionContextImpl serverCache;
+    final SSLSessionContextImpl serverCache;


Then the caller could use sslContext.serverCache.getKey() directly.  BTW, I may change the name from getKey to getStatelessKey() for readability.

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 28:

> 26: package sun.security.ssl;
> 27: 
> 28: import java.security.SecureRandom;

This import is not used.

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 77:

> 75: 
> 76:     private int currentKeyID;           // RFC 5077 session ticket key name
> 77:     private final Map<Integer,          // Maps session keys to session state

What do you think if adjusting the comment a little bit?

    // The current session ticket encryption key ID
    private int currentKeyID;

    // Session ticket encryption keys and IDs map
    private final Map<Integer,

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 79:

> 77:     private final Map<Integer,          // Maps session keys to session state
> 78:             SessionTicketExtension.StatelessKey> keyHashMap = new ConcurrentHashMap<>();
> 79: 

It may be not necessary to allocate the map for client session context.  It may be fine to me the map allocation to constructor.


private final Map<Integer, SessionTicketExtension.StatelessKey> keyHashMap;
SSLSessionContextImpl(boolean server) {
    ....
    if (server) {
        keyHashMap = ...
        currentKeyID = ...
    } else {
        keyHashMap = empty map
    }
}

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 182:

> 180: 
> 181:     // Package-private, used only from SSLContextImpl::engineInit() to initialie currentKeyID.
> 182:     void initCurrentKeyID(int keyID) {

The ID will work as if it is unique in the context, granted with synchronization.  It may be not necessary to use secure number for it.   The ID could be assigned at constructor (see comment above, use number zero or the current time, etc.), and thus this method and the caller code could be removed, I think.

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 187:

> 185: 
> 186:     // Package-private, used only from SSLContextImpl::getKey() to create a new session key.
> 187:     int getCurrentKeyID() {

This method could be removed if you want to move SSLContextImpl.getKey() into this class.

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 191:

> 189:     }
> 190: 
> 191:     private void cleanupSessionKeys() {

What do you think if using CleanupStatelessKeys as the method name?

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 226:

> 224:         return keyHashMap.get(id);
> 225:     }
> 226: 

It may need to reconsider these 3 methods you want to move SSLContextImpl.getKey() into this class.

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

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

From rhalade at openjdk.org  Wed Dec 21 20:41:53 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 20:41:53 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
Message-ID: <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>

On Wed, 21 Dec 2022 19:58:18 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/sun/security/provider/PolicyParser/ExtDirs.java line 33:
>> 
>>> 31: 
>>> 32: /*
>>> 33:  * @test
>> 
>> Why are these tags duplicated here?
>
> Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.

I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?

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

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

From bhuang at openjdk.org  Wed Dec 21 21:39:52 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 21 Dec 2022 21:39:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
 <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
Message-ID: <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>

On Wed, 21 Dec 2022 20:39:03 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Multiple "run" in a single test fails the whole test when one test run fails and all subsequent test run get terminated. Multiple tests with only one "run" each allows all test run to be excused, and they can be run in parallel.
>
> I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?

I didn't know that until Leonid posted this [comment](https://github.com/openjdk/jdk/pull/9813#discussion_r942908285) in one of my PRs. We do have a lot of tests written in this way and each test run will be given a unique id after the file name. For example, ExtDirs.java has two test run, and they will be named as ExtDirs.java#id0 and ExtDirs.java#id1. We can search "name:*.java#id*" in a Core Lib Mach5 run, it will show thousands of results.

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

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

From mpowers at openjdk.org  Wed Dec 21 21:45:56 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 21 Dec 2022 21:45:56 GMT
Subject: [jdk20] RFR: JDK-8299230 Use https: in links
Message-ID: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>

https://bugs.openjdk.org/browse/JDK-8299230

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

Commit messages:
 - first iteration

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

PR: https://git.openjdk.org/jdk20/pull/69

From rhalade at openjdk.org  Wed Dec 21 21:50:52 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 21:50:52 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
 <bPVh_aHz398yv1Q5Qk48H_8ddTTkOxC3AkVOR-gDEkA=.666bc926-d579-4d75-a2bb-ccc9e6f032a4@github.com>
 <biX2juSzVryWWGuHnrLeyzOHVH4zzUQhLGHwBgIlyKE=.0dd655b0-7f5c-4e61-bd17-8daba35fc110@github.com>
 <QIxuMKJKXqHo4DKYh9tFn7v2LsUY9KMpOM98m43JYBw=.e70b1f67-6854-47e8-82f9-83fb707d056a@github.com>
 <Ns6FEjEH1NScO2Trgvcu2Ph1e1NgRImJZ6GByQmi-4k=.7018d4f4-00a5-4290-9c4a-f725bcdbc29a@github.com>
Message-ID: <XJtlqDZURgbgOvtqN5f4zfoTgYYzzHaJPHFuYW77s6I=.55d267ab-fab5-4885-83c0-73814896e4c4@github.com>

On Wed, 21 Dec 2022 21:37:27 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> I have not seen this used in any other tests. It is a good learning, I didn't knew that multiple tests in single file are run in parallel. It seems like good option. Do you know of any other regression test written this way?
>
> I didn't know that until Leonid posted this [comment](https://github.com/openjdk/jdk/pull/9813#discussion_r942908285) in one of my PRs. We do have a lot of tests written in this way and each test run will be given a unique id after the file name. For example, ExtDirs.java has two test run, and they will be named as ExtDirs.java#id0 and ExtDirs.java#id1. We can search "name:*.java#id*" in a Core Lib Mach5 run, it will show thousands of results.

Thanks for this. Fix looks good to me.

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

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

From rhalade at openjdk.org  Wed Dec 21 21:53:50 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 21 Dec 2022 21:53:50 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v6]
In-Reply-To: <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <J2eQc_SMfteNYRozU44midnVyt2Kdqmic39U4QFoGd0=.3c9049d3-7624-4a80-8d9b-002072c73cd5@github.com>
Message-ID: <u3UT5U3eN6WEmtAddULuMBHnLzJK_bty4YYZNnvo47A=.29b83826-3226-47e2-ad27-e8859163d191@github.com>

On Tue, 20 Dec 2022 19:23:10 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Marked as reviewed by rhalade (Reviewer).

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

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

From jjg at openjdk.org  Wed Dec 21 22:20:48 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 21 Dec 2022 22:20:48 GMT
Subject: [jdk20] RFR: JDK-8299230 Use https: in links
In-Reply-To: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
References: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
Message-ID: <MQkGogFk5yYdv2iQ8kvBiyEAmauSXoS8vOMV7RDhgr8=.2d0b4bca-ba1e-4984-8719-4dd98cd63624@github.com>

On Wed, 21 Dec 2022 21:38:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8299230

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/69

From mullan at openjdk.org  Wed Dec 21 22:55:58 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 21 Dec 2022 22:55:58 GMT
Subject: [jdk20] RFR: JDK-8299230 Use https: in links
In-Reply-To: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
References: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
Message-ID: <Sx9--DP5b8gekrgnJf0_rwtX5DmXYPv9FlWjfc8-lAQ=.41e6bbf8-d394-4426-bab7-6b45813c25db@github.com>

On Wed, 21 Dec 2022 21:38:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8299230

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/69

From duke at openjdk.org  Wed Dec 21 23:50:46 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 21 Dec 2022 23:50:46 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception
Message-ID: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>

Updated to use specific ciphersuite and TLS protocol.
Updated tests based on changes to SSLEngine implementation

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

Commit messages:
 - 8298867: Basics.java fails with SSL handshake exception

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

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

From xuelei at openjdk.org  Thu Dec 22 01:06:55 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 01:06:55 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception
In-Reply-To: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
Message-ID: <diGV1Q9EAJWbGXBQcASfjkt-fRtGgP_wILfEoeIglms=.4a0d065f-6d1b-4415-9f05-0f7afb601265@github.com>

On Wed, 21 Dec 2022 23:42:48 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Updated to use specific ciphersuite and TLS protocol.
> Updated tests based on changes to SSLEngine implementation

Looks good to me, although it would be nice to check more protocols.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.org  Thu Dec 22 01:07:51 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 01:07:51 GMT
Subject: [jdk20] RFR: JDK-8299230 Use https: in links
In-Reply-To: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
References: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
Message-ID: <9K0V_cs2d8t6-JQxSZLWCAXKA7AVtIUtZGvQBSkYw2g=.91da5891-f5e7-475a-b0ee-2883dfcb4b84@github.com>

On Wed, 21 Dec 2022 21:38:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8299230

Marked as reviewed by xuelei (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/69

From ascarpino at openjdk.org  Thu Dec 22 04:18:51 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Dec 2022 04:18:51 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <sckttgJlINDlSY3sd-9PR_5w70aJO9BM3m15zHqur3A=.86e38924-a81a-475c-bca2-6d8f893309af@github.com>

On Wed, 21 Dec 2022 20:15:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 80:
> 
>> 78: 
>> 79:     protected SessionTicketExtension.StatelessKey getKey() {
>> 80:         SessionTicketExtension.StatelessKey ssk = serverCache.getKey();
> 
> I may change the serverCache from private to package private, and move the getKey() methods into SSLSessionContextImpl:
> 
> -    private final SSLSessionContextImpl serverCache;
> +    final SSLSessionContextImpl serverCache;
> 
> 
> Then the caller could use sslContext.serverCache.getKey() directly.  BTW, I may change the name from getKey to getStatelessKey() for readability.

I agree this should be in SSLSessionContextImpl

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

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

From ascarpino at openjdk.org  Thu Dec 22 04:18:53 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Dec 2022 04:18:53 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
Message-ID: <j3SoczwibghSHefg9bQ42R9h23kDJtxv5ir98LdoulU=.479e902f-26ef-443c-8eeb-e0b48ea816d9@github.com>

On Wed, 21 Dec 2022 15:05:13 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 211:

> 209:     // Package-private, used only from SSLContextImpl::getKey() to create a new session key.
> 210:     void insertNewSessionKey(int newID, SessionTicketExtension.StatelessKey ssk) {
> 211:         assert newID != currentKeyID : "Must use a new ID for a new session key!";

This method contents should be merged back into getKey() when it is in this source file, and then you don't need to check the new vs currentKey IDs.  Also assert is a bad idea as it does not throw a subclass of Exception and the may bring down the entire program.

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

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

From mbaesken at openjdk.org  Thu Dec 22 11:52:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Dec 2022 11:52:30 GMT
Subject: RFR: JDK-8235297:
 sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails
 intermittent
Message-ID: <JH9tFs6bUyXRVMWpIV8mYDjrFVcpcOY4COdwsB3TQW8=.50f21e20-ac3f-47c9-b2b3-6cf8d0b09bdd@github.com>

The test  sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent with timeouts ,  this info should be added to the test.

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

Commit messages:
 - JDK-8235297

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

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

From simonis at openjdk.org  Thu Dec 22 12:47:52 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 12:47:52 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <kMKrCEh5i8ihdXee87aUPTmeVsZhfVXKVTX-mMMydQI=.ead2bf3d-802f-4e54-98db-4ec44f05b524@github.com>

On Wed, 21 Dec 2022 19:34:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 28:
> 
>> 26: package sun.security.ssl;
>> 27: 
>> 28: import java.security.SecureRandom;
> 
> This import is not used.

Fixed.

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

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

From simonis at openjdk.org  Thu Dec 22 12:51:52 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 12:51:52 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <HXBu6IkwnTUPb2CPe2AHol5UbaiKQqO-gMvMWKCCf7g=.a6041b85-4cba-47a3-af85-1b734ebea157@github.com>

On Wed, 21 Dec 2022 19:46:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 77:
> 
>> 75: 
>> 76:     private int currentKeyID;           // RFC 5077 session ticket key name
>> 77:     private final Map<Integer,          // Maps session keys to session state
> 
> What do you think if adjusting the comment a little bit?
> 
>     // The current session ticket encryption key ID
>     private int currentKeyID;
> 
>     // Session ticket encryption keys and IDs map
>     private final Map<Integer,

Changed.

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

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

From simonis at openjdk.org  Thu Dec 22 12:55:00 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 12:55:00 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <cvnpKmKBolji6_4otY4ga_TI9F1z438Bd83K_xp9dEg=.528464b7-f91d-4a8d-856b-dcd6a9f1e707@github.com>

On Wed, 21 Dec 2022 20:07:40 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 79:
> 
>> 77:     private final Map<Integer,          // Maps session keys to session state
>> 78:             SessionTicketExtension.StatelessKey> keyHashMap = new ConcurrentHashMap<>();
>> 79: 
> 
> It may be not necessary to allocate the map for client session context.  It may be fine to me the map allocation to constructor.
> 
> 
> private final Map<Integer, SessionTicketExtension.StatelessKey> keyHashMap;
> SSLSessionContextImpl(boolean server) {
>     ....
>     if (server) {
>         keyHashMap = ...
>         currentKeyID = ...
>     } else {
>         keyHashMap = empty map
>     }
> }

Changed.

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

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

From simonis at openjdk.org  Thu Dec 22 13:15:53 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 13:15:53 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <p87WMbPH0w9MzouXW4cUgd2XdGnVAuwjEll10zA4CRM=.be68e6b8-0729-4207-9a32-f9c2505ac60f@github.com>

On Wed, 21 Dec 2022 20:11:44 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 182:
> 
>> 180: 
>> 181:     // Package-private, used only from SSLContextImpl::engineInit() to initialie currentKeyID.
>> 182:     void initCurrentKeyID(int keyID) {
> 
> The ID will work as if it is unique in the context, granted with synchronization.  It may be not necessary to use secure number for it.   The ID could be assigned at constructor (see comment above, use number zero or the current time, etc.), and thus this method and the caller code could be removed, I think.

I'm not an expert in this area, but [RFC 5077 reccomends](https://www.rfc-editor.org/rfc/rfc5077#page-10) that the ID "*should be randomly generated to avoid collisions between servers*". What about initializing it to the `hashCode()` of the `SSLSessionContextImpl` object?

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

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

From simonis at openjdk.org  Thu Dec 22 13:41:56 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 13:41:56 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
Message-ID: <9T9Je_F4h4hqc_GHHhsUt9JaOiMRsCEPTfwEEJ1DLac=.f16ac0af-a93a-4b19-9f44-99298e08730d@github.com>

On Wed, 21 Dec 2022 20:23:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 187:
> 
>> 185: 
>> 186:     // Package-private, used only from SSLContextImpl::getKey() to create a new session key.
>> 187:     int getCurrentKeyID() {
> 
> This method could be removed if you want to move SSLContextImpl.getKey() into this class.

Done.

> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 191:
> 
>> 189:     }
>> 190: 
>> 191:     private void cleanupSessionKeys() {
> 
> What do you think if using CleanupStatelessKeys as the method name?

Fine for me.

> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 226:
> 
>> 224:         return keyHashMap.get(id);
>> 225:     }
>> 226: 
> 
> It may need to reconsider these 3 methods you want to move SSLContextImpl.getKey() into this class.

Refactored as proposed.

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

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

From simonis at openjdk.org  Thu Dec 22 13:41:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 13:41:58 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <j3SoczwibghSHefg9bQ42R9h23kDJtxv5ir98LdoulU=.479e902f-26ef-443c-8eeb-e0b48ea816d9@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <j3SoczwibghSHefg9bQ42R9h23kDJtxv5ir98LdoulU=.479e902f-26ef-443c-8eeb-e0b48ea816d9@github.com>
Message-ID: <eszoFTKhxeW4pBESZ89Bf5K_0GE4jN6exh9fL6cZkMo=.ed012d65-bc79-492e-869b-811e0e7c5905@github.com>

On Wed, 21 Dec 2022 22:53:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimized initialisation of currentKeyID and deletion of expired session keys as proposed by @schlosna
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 211:
> 
>> 209:     // Package-private, used only from SSLContextImpl::getKey() to create a new session key.
>> 210:     void insertNewSessionKey(int newID, SessionTicketExtension.StatelessKey ssk) {
>> 211:         assert newID != currentKeyID : "Must use a new ID for a new session key!";
> 
> This method contents should be merged back into getKey() when it is in this source file, and then you don't need to check the new vs currentKey IDs.  Also assert is a bad idea as it does not throw a subclass of Exception and the may bring down the entire program.

Refactored as proposed.

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

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

From simonis at openjdk.org  Thu Dec 22 14:15:52 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 14:15:52 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v3]
In-Reply-To: <sckttgJlINDlSY3sd-9PR_5w70aJO9BM3m15zHqur3A=.86e38924-a81a-475c-bca2-6d8f893309af@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <I0QWxbB_ZoucEQxcf6AvOGSrXdlum3PjW0EncxWbh7c=.79b1a0b0-f07e-4200-bc49-f34595f7719a@github.com>
 <4fA_IH2B4B7Y_onObPs7sjWGdFTHLeMMtRBgyTswg-U=.c7787740-e817-4466-81ee-aa88cbd91d6d@github.com>
 <sckttgJlINDlSY3sd-9PR_5w70aJO9BM3m15zHqur3A=.86e38924-a81a-475c-bca2-6d8f893309af@github.com>
Message-ID: <r1tFo7jJidwDWLrmmLgdEjdXD_1OjNxFJJayBBkApYw=.9dfccf5d-a0a8-47a9-81ca-6f71aaa5827f@github.com>

On Wed, 21 Dec 2022 22:53:44 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 80:
>> 
>>> 78: 
>>> 79:     protected SessionTicketExtension.StatelessKey getKey() {
>>> 80:         SessionTicketExtension.StatelessKey ssk = serverCache.getKey();
>> 
>> I may change the serverCache from private to package private, and move the getKey() methods into SSLSessionContextImpl:
>> 
>> -    private final SSLSessionContextImpl serverCache;
>> +    final SSLSessionContextImpl serverCache;
>> 
>> 
>> Then the caller could use sslContext.serverCache.getKey() directly.  BTW, I may change the name from getKey to getStatelessKey() for readability.
>
> I agree this should be in SSLSessionContextImpl

I did the refactoring as requested, but I don't like (and I don't think it is "good practice") to expose fields to other classes. And there's already a getter for `serverCache` in `SSLContextImpl` anyway (i.e. `SSLContextImpl::engineGetServerSessionContext`) so I decided to use that one instead and leave the field as private.

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

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

From simonis at openjdk.org  Thu Dec 22 15:00:18 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 15:00:18 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11590/files
  - new: https://git.openjdk.org/jdk/pull/11590/files/64905b3d..ece9c733

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

  Stats: 89 lines in 3 files changed: 31 ins; 45 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11590.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11590/head:pull/11590

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

From simonis at openjdk.org  Thu Dec 22 15:00:18 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 22 Dec 2022 15:00:18 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
Message-ID: <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>

On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
>> The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:
> 
> That's obviously not the expected behaviors.  It is a good catch for the `static currentKeyID` issue.
> 
> What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`?  I would like to have SSLContextImpl focusing on configuration.

Hi @XueleiFan, @ascarpino,

Thank you for your reviews and comments. I think I've addressed all of your suggestions in the latest version of the PR.

There's just one more thing I had to change. Now that I've moved all the logic to `SSLSessionContextImpl` I can't get a reference to `SSLContextImpl`s secure random instance any more when creating a new `StatelessKey`. For simplicity I've therefor decided to use the `KeyGenerator.init()` method which doesn't require an extra secure random instance. 

If you think that it is important that the `KeyGenerator` uses the same secure random instance like the corresponding `SSLContextImpl`, I can easily change `SSLSessionContextImpl::getKey()` to take a `SecureRandom` argument and pass `SSLContextImpl`s secure random instance down to  `SSLSessionContextImpl::getKey()` (and up to `StatelessKey::<init>`) when calling `getKey()` from `KeyState::getCurrentKey()`.

What do you think?

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

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

From mpowers at openjdk.org  Thu Dec 22 15:32:49 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 22 Dec 2022 15:32:49 GMT
Subject: [jdk20] Integrated: JDK-8299230 Use https: in links
In-Reply-To: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
References: <YWFClKBQsdN6dHd5rDee9QLtV7vftDBX9tPGEV97-OY=.6237bc4f-f1c2-4ba5-92cb-597492d67ead@github.com>
Message-ID: <Jv6d-EFoVdvoXSnX-MfYVKcCvtsYes7_yA_M-XJToDo=.7fc9e7fd-4a3b-42bf-bf94-cbe79e834ab4@github.com>

On Wed, 21 Dec 2022 21:38:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8299230

This pull request has now been integrated.

Changeset: a80c91d0
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/a80c91d0360864e34569b684cf159e2dcdebeaaf
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8299230: Use https: in links

Reviewed-by: jjg, mullan, xuelei

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

PR: https://git.openjdk.org/jdk20/pull/69

From bhuang at openjdk.org  Thu Dec 22 16:53:58 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 22 Dec 2022 16:53:58 GMT
Subject: Integrated: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <U3Nb7ZbLHzomaBBfehqIMIAm3bjbpHX6iLxj4o178PE=.c9bab129-ba1a-4873-8236-4affcbcb91ad@github.com>

On Mon, 10 Oct 2022 21:39:05 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

This pull request has now been integrated.

Changeset: a3693ccc
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3693ccc617d06137a61050b34646e8a90ed3d7e
Stats:     173 lines in 13 files changed: 71 ins; 32 del; 70 mod

8295087: Manual Test to Automated Test Conversion

Reviewed-by: ssahoo, rhalade

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

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

From duke at openjdk.org  Thu Dec 22 18:00:11 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 22 Dec 2022 18:00:11 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
Message-ID: <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>

> Updated to use specific ciphersuite and TLS protocol.
> Updated tests based on changes to SSLEngine implementation

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added additional protocols

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11760/files
  - new: https://git.openjdk.org/jdk/pull/11760/files/ae09ca96..2d2745f4

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

  Stats: 24 lines in 1 file changed: 15 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11760.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11760/head:pull/11760

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

From duke at openjdk.org  Thu Dec 22 18:00:11 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 22 Dec 2022 18:00:11 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <diGV1Q9EAJWbGXBQcASfjkt-fRtGgP_wILfEoeIglms=.4a0d065f-6d1b-4415-9f05-0f7afb601265@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <diGV1Q9EAJWbGXBQcASfjkt-fRtGgP_wILfEoeIglms=.4a0d065f-6d1b-4415-9f05-0f7afb601265@github.com>
Message-ID: <ojexwe2LHiw31mQpSazTkqHhmTsYcR7-2oZosMt2SPI=.4a48be70-d19f-442b-81b2-bb824d182007@github.com>

On Thu, 22 Dec 2022 01:03:53 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Looks good to me, although it would be nice to check more protocols.

I extended the tests to include TLS 1.2 and 1.1

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

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

From ascarpino at openjdk.org  Thu Dec 22 18:23:53 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Dec 2022 18:23:53 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
Message-ID: <NX37SPn7fLzE3FUyUuMfz3IFrF60hne_s8ycWvVMfGY=.ffce0c43-5be8-4ba0-9301-bfa64690fde4@github.com>

On Thu, 22 Dec 2022 15:00:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino

src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 122:

> 120:             try {
> 121:                 KeyGenerator kg = KeyGenerator.getInstance("AES");
> 122:                 kg.init(KEYLEN, hc.sslContext.getSecureRandom());

I think it's important to us random from hc. Configurations with specific providers would not want to use a different provider.

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

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

From ascarpino at openjdk.org  Thu Dec 22 18:28:52 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Dec 2022 18:28:52 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
 <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
Message-ID: <73jcpakztxwTXJuOw4mLRe6tijX4wNIX6Nc-b-zYpiM=.b824198d-46b0-43c7-b641-b694a2b0c444@github.com>

On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> For simplicity I've therefor decided to use the `KeyGenerator.init()` method which
> doesn't require an extra secure random instance.

I understand the logic, but some users like to use a particular provider, keygen should use the random specified in the HandshakeContext.

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

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

From xuelei at openjdk.org  Thu Dec 22 18:42:48 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 18:42:48 GMT
Subject: RFR: JDK-8235297:
 sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails
 intermittent
In-Reply-To: <JH9tFs6bUyXRVMWpIV8mYDjrFVcpcOY4COdwsB3TQW8=.50f21e20-ac3f-47c9-b2b3-6cf8d0b09bdd@github.com>
References: <JH9tFs6bUyXRVMWpIV8mYDjrFVcpcOY4COdwsB3TQW8=.50f21e20-ac3f-47c9-b2b3-6cf8d0b09bdd@github.com>
Message-ID: <-ZuYTsGW7FiHQcTpBiLEPpx8ZLtqS3E9mc3X6UUBYoA=.fb925daa-c7cc-4632-a015-d7c694cdd982@github.com>

On Thu, 22 Dec 2022 11:44:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test  sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent with timeouts ,  this info should be added to the test.

Looks good to me.   I guess the intermittent failure issue could be addressed by using  the new template, but it may be not worthy of the effort.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.org  Thu Dec 22 18:46:49 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 18:46:49 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <ojexwe2LHiw31mQpSazTkqHhmTsYcR7-2oZosMt2SPI=.4a48be70-d19f-442b-81b2-bb824d182007@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <diGV1Q9EAJWbGXBQcASfjkt-fRtGgP_wILfEoeIglms=.4a0d065f-6d1b-4415-9f05-0f7afb601265@github.com>
 <ojexwe2LHiw31mQpSazTkqHhmTsYcR7-2oZosMt2SPI=.4a48be70-d19f-442b-81b2-bb824d182007@github.com>
Message-ID: <Dnt0dYOyCbakh7oQAE3Yw0wH7kEeAWMp9pAgv-aX3kM=.ffdf2c50-13d2-4d7a-a268-1009924f4ed7@github.com>

On Thu, 22 Dec 2022 17:54:53 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> > Looks good to me, although it would be nice to check more protocols.
> 
> I extended the tests to include TLS 1.2 and 1.1

Thank you!

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

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

From xuelei at openjdk.org  Thu Dec 22 18:46:52 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 18:46:52 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
Message-ID: <Vh1-1tQPRUtmfDLYSU7WfPw38tQ7DzgWeRWatdPKU6I=.00fb1727-c594-4ad3-9829-3ae0a1902fc1@github.com>

On Thu, 22 Dec 2022 18:00:11 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated to use specific ciphersuite and TLS protocol.
>> Updated tests based on changes to SSLEngine implementation
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added additional protocols

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 63:

> 61:     private static final String TLS13_PROTOCOL = "TLSv1.3";
> 62: 
> 63:     private static final String TLS12_PROTOCOL = "TLSv1.2";

It looks like that the three constants are not used any longer?

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

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

From rhalade at openjdk.org  Thu Dec 22 19:01:49 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 22 Dec 2022 19:01:49 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
Message-ID: <SjBQM5ZjkFaD1QCo8tk4e9UG-CcyTWfsowZsnjNo21M=.9fc764c7-3374-4373-8056-22025760c57c@github.com>

On Thu, 22 Dec 2022 18:00:11 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated to use specific ciphersuite and TLS protocol.
>> Updated tests based on changes to SSLEngine implementation
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added additional protocols

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 34:

> 32:  * @library /test/lib
> 33:  * @author Brad Wetmore
> 34:  * @run main Basics

Please use othervm to run this test as security properties are altered.

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 103:

> 101:                 .findFirst()
> 102:                 .orElseThrow((() ->
> 103:                         new RuntimeException(cipherSuite +

Test throws the Exception, not RuntimeException in other failure cases in this test. Can you please update those to RuntimeException as well?

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

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

From rhalade at openjdk.org  Thu Dec 22 19:01:52 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 22 Dec 2022 19:01:52 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <Vh1-1tQPRUtmfDLYSU7WfPw38tQ7DzgWeRWatdPKU6I=.00fb1727-c594-4ad3-9829-3ae0a1902fc1@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
 <Vh1-1tQPRUtmfDLYSU7WfPw38tQ7DzgWeRWatdPKU6I=.00fb1727-c594-4ad3-9829-3ae0a1902fc1@github.com>
Message-ID: <zeh0rPuqr3nRuLuvMPxotODTDAz5NEsKFcUDfoiJUcA=.d02d45d2-44fa-422c-9858-48a045178fc3@github.com>

On Thu, 22 Dec 2022 18:42:34 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added additional protocols
>
> test/jdk/javax/net/ssl/SSLEngine/Basics.java line 63:
> 
>> 61:     private static final String TLS13_PROTOCOL = "TLSv1.3";
>> 62: 
>> 63:     private static final String TLS12_PROTOCOL = "TLSv1.2";
> 
> It looks like that the three constants are not used any longer?

+1. These are to be passed as parameter to runTest. Either define and use all as constant or remove these.

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

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

From rhalade at openjdk.org  Thu Dec 22 19:04:52 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 22 Dec 2022 19:04:52 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v2]
In-Reply-To: <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <H5hGHjJjsZZYPZpd8h58bGTg0jmp608Q3G6yC8qdmHQ=.9e6256f0-83f2-4ecd-b806-b02378e2b74b@github.com>
Message-ID: <7z779DEUGtF5hs4BsCnLXCWJVT1yWs2TZ27ktZPmZjs=.a2573839-1883-4cf7-a31a-ef0742f336d9@github.com>

On Thu, 22 Dec 2022 18:00:11 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated to use specific ciphersuite and TLS protocol.
>> Updated tests based on changes to SSLEngine implementation
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added additional protocols

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 48:

> 46: public class Basics {
> 47: 
> 48:     private static String pathToStores = "../etc";

optional - this is an old code but since you are refactoring this test, can you please declare these as constants as well.

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

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

From xuelei at openjdk.org  Thu Dec 22 19:17:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 22 Dec 2022 19:17:54 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
Message-ID: <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>

On Thu, 22 Dec 2022 15:00:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
>> 
>> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
>> 
>> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
>> 
>> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
>> 
>> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
>> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> With my proposed patch, the numbers goes back to two instances again:
>> 
>> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
>> 
>> 
>> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 95:

> 93:             // Should be "randomly generated" according to RFC 5077,
> 94:             // but doesn't necessarily has to be a true random number.
> 95:             currentKeyID = this.hashCode();

As the hashCode() is called in the constructor, I'm not very sure if it works as expected.   Maybe, the system nano time could be used instead.

src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 97:

> 95:             currentKeyID = this.hashCode();
> 96:         } else {
> 97:             keyHashMap = null;

I may use an unmodifiable empty map so that we don't have to worry about null pointer exception.

`keyHashMap = Map.of();`

src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 163:

> 161:             SSLSessionContextImpl serverCache =
> 162:                 (SSLSessionContextImpl)hc.sslContext.engineGetServerSessionContext();
> 163:             return serverCache.getKey();

I think the `HandshakeContext hc` could be passed as a parameter for the getKey() method, and thus you have a way to get the secure random for StatelessKey().

      return serverCache.getKey(hc);
->     SessionTicketExtension.StatelessKey getKey(HandshakeContext hc) {
->     ssk = new SessionTicketExtension.StatelessKey(hc, newID);
->     StatelessKey(HandshakeContext hc, int newNum) {
->     kg.init(KEYLEN, hc.sslContext.getSecureRandom());

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

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

From duke at openjdk.org  Thu Dec 22 19:29:18 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 22 Dec 2022 19:29:18 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v3]
In-Reply-To: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
Message-ID: <ofZCAN34rGZLQnU86BNyGj7snf1yBNUX0MNk43b-2a4=.213bc2ad-da55-40b9-9287-73680098c4b8@github.com>

> Updated to use specific ciphersuite and TLS protocol.
> Updated tests based on changes to SSLEngine implementation

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  removed unused variables, made fields final, changed to RuntimeException everywhere

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11760/files
  - new: https://git.openjdk.org/jdk/pull/11760/files/2d2745f4..b307e21e

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

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

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

From rhalade at openjdk.org  Thu Dec 22 19:30:50 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 22 Dec 2022 19:30:50 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v3]
In-Reply-To: <ofZCAN34rGZLQnU86BNyGj7snf1yBNUX0MNk43b-2a4=.213bc2ad-da55-40b9-9287-73680098c4b8@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <ofZCAN34rGZLQnU86BNyGj7snf1yBNUX0MNk43b-2a4=.213bc2ad-da55-40b9-9287-73680098c4b8@github.com>
Message-ID: <dRhSK1DslaVERDEIiyPjyi36Ab1kJpeQ4sGfdR4avEU=.3fa41ec7-7378-4efe-9ef1-205683a82541@github.com>

On Thu, 22 Dec 2022 19:29:18 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated to use specific ciphersuite and TLS protocol.
>> Updated tests based on changes to SSLEngine implementation
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused variables, made fields final, changed to RuntimeException everywhere

test/jdk/javax/net/ssl/SSLEngine/Basics.java line 51:

> 49:     private static final String keyStoreFile = "keystore";
> 50:     private static final String trustStoreFile = "truststore";
> 51:     private static final String passwd = "passphrase";

passwd variable defined here is unused. Also can you please capitalize all the constants.

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

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

From duke at openjdk.org  Thu Dec 22 19:51:13 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 22 Dec 2022 19:51:13 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v4]
In-Reply-To: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
Message-ID: <gl4ghiu0M34VQsWMqPbdxeRP7-ZdgJNjLARJIt3c_a0=.eefa9986-c005-4f06-b80a-fb8a7a89d0f3@github.com>

> Updated to use specific ciphersuite and TLS protocol.
> Updated tests based on changes to SSLEngine implementation

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  additional cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11760/files
  - new: https://git.openjdk.org/jdk/pull/11760/files/b307e21e..fe5dd19b

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

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

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

From rhalade at openjdk.org  Thu Dec 22 22:40:51 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 22 Dec 2022 22:40:51 GMT
Subject: RFR: 8298867: Basics.java fails with SSL handshake exception [v4]
In-Reply-To: <gl4ghiu0M34VQsWMqPbdxeRP7-ZdgJNjLARJIt3c_a0=.eefa9986-c005-4f06-b80a-fb8a7a89d0f3@github.com>
References: <iilf9g2RDQHqcqXmPjmSO_nEcJN0rPJxNiiVU8Ekq1s=.002f56ef-cf01-465c-8e88-4cda4e95b023@github.com>
 <gl4ghiu0M34VQsWMqPbdxeRP7-ZdgJNjLARJIt3c_a0=.eefa9986-c005-4f06-b80a-fb8a7a89d0f3@github.com>
Message-ID: <yzPxKeJWRLhLjnZyUNUqsSudf5o5SCbCF7-ODAMcaNs=.8c1b14aa-ba5d-4a05-8bc1-6da831cf4de5@github.com>

On Thu, 22 Dec 2022 19:51:13 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Updated to use specific ciphersuite and TLS protocol.
>> Updated tests based on changes to SSLEngine implementation
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional cleanup

Marked as reviewed by rhalade (Reviewer).

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

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

From ascarpino at openjdk.org  Thu Dec 22 22:48:53 2022
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Dec 2022 22:48:53 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
 <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
Message-ID: <07tmdCoG6pplRtwf3r7ZMO1XX8akL8rU_RnoR2BGqN4=.483bb3b2-3a29-47e7-9410-37fcd545ba28@github.com>

On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>>> The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> That's obviously not the expected behaviors.  It is a good catch for the `static currentKeyID` issue.
>> 
>> What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`?  I would like to have SSLContextImpl focusing on configuration.
>
> Hi @XueleiFan, @ascarpino,
> 
> Thank you for your reviews and comments. I think I've addressed all of your suggestions in the latest version of the PR.
> 
> There's just one more thing I had to change. Now that I've moved all the logic to `SSLSessionContextImpl` I can't get a reference to `SSLContextImpl`s secure random instance any more when creating a new `StatelessKey`. For simplicity I've therefor decided to use the `KeyGenerator.init()` method which doesn't require an extra secure random instance. 
> 
> If you think that it is important that the `KeyGenerator` uses the same secure random instance like the corresponding `SSLContextImpl`, I can easily change `SSLSessionContextImpl::getKey()` to take a `SecureRandom` argument and pass `SSLContextImpl`s secure random instance down to  `SSLSessionContextImpl::getKey()` (and up to `StatelessKey::<init>`) when calling `getKey()` from `KeyState::getCurrentKey()`.
> 
> What do you think?

@simonis, I don't think @XueleiFan and I are going to finish reviews by Friday.  As Oracle has next week off, I suggest you update the copyrights to 2023 and we can integrate next year one all the comments have been resolved.

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

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

From simonis at openjdk.org  Fri Dec 23 10:29:56 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 10:29:56 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
 <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
Message-ID: <GpEFtwu6cM3pHrpFw7LZBCpIiCrvLxEz19CdEoAGjHo=.e737635b-cc1c-4b2d-8058-2a8c8d3b1c50@github.com>

On Thu, 22 Dec 2022 18:59:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 97:
> 
>> 95:             currentKeyID = this.hashCode();
>> 96:         } else {
>> 97:             keyHashMap = null;
> 
> I may use an unmodifiable empty map so that we don't have to worry about null pointer exception.
> 
> `keyHashMap = Map.of();`

Done.

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

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

From simonis at openjdk.org  Fri Dec 23 10:40:55 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 10:40:55 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
 <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
Message-ID: <JIor6IlMx5V2ePGoI1q5W20zVShB3tfSrNd8UJWQ9Mk=.515a865c-41da-4590-88b0-587b2f0451cf@github.com>

On Thu, 22 Dec 2022 18:54:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 95:
> 
>> 93:             // Should be "randomly generated" according to RFC 5077,
>> 94:             // but doesn't necessarily has to be a true random number.
>> 95:             currentKeyID = this.hashCode();
> 
> As the hashCode() is called in the constructor, I'm not very sure if it works as expected.   Maybe, the system nano time could be used instead.

I don't think calling `hashCode()` is an issue as long as `SSLSessionContextImpl` doesn't override `hashCode()` (which it doesn't do) and that overridden version of `hashCode()` accesses uninitialized fields. But for the sake of getting this done, I've changed the initialization to use the result `System.nanoTime()` as a seed for a new `java.util.Random` instance and call `nextInt()` on that instance. That seems like a good compromise to me :)

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

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

From jwilhelm at openjdk.org  Fri Dec 23 10:56:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 10:56:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299237: add ArraysSupport.newLength test to a test group
 - 8299230: Use https: in links
 - 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes
 - 8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
 - 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears
 - 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus

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

Changes: https://git.openjdk.org/jdk/pull/11773/files
  Stats: 572 lines in 15 files changed: 407 ins; 76 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/11773.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11773/head:pull/11773

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

From simonis at openjdk.org  Fri Dec 23 11:07:56 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 11:07:56 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <NX37SPn7fLzE3FUyUuMfz3IFrF60hne_s8ycWvVMfGY=.ffce0c43-5be8-4ba0-9301-bfa64690fde4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
 <NX37SPn7fLzE3FUyUuMfz3IFrF60hne_s8ycWvVMfGY=.ffce0c43-5be8-4ba0-9301-bfa64690fde4@github.com>
Message-ID: <4UwK_S9SyZq_3Xlfv5RVOEh_4k9Ba1TJJcC9FCzMufk=.ce601b4d-88b9-4763-8239-196ddfa63276@github.com>

On Thu, 22 Dec 2022 17:15:36 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino
>
> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 122:
> 
>> 120:             try {
>> 121:                 KeyGenerator kg = KeyGenerator.getInstance("AES");
>> 122:                 kg.init(KEYLEN, hc.sslContext.getSecureRandom());
> 
> I think it's important to use random from hc. Configurations with specific providers would not want to use a different provider for key generations.

Understood and fixed.

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

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

From simonis at openjdk.org  Fri Dec 23 11:07:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 11:07:58 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v4]
In-Reply-To: <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <2F8qQ4zq7cPD9bKGl-tQCaOI9Ewdmi9oPIVY5tVumQQ=.1e9cccec-fe09-465a-bef9-ba87cd2bcea0@github.com>
 <1fdlpYWV9RlspFUfDmyj0SDZpaRDY0ze2KYQGuJ85L0=.c4a858b0-30d4-4c0b-a238-efc53eeb96b7@github.com>
Message-ID: <pXtmHOxo6mT91heYi_R6qPf1qgNthDFxpF3qF5ZKMqw=.17c0050a-f37e-4a26-8050-63e4bb20891c@github.com>

On Thu, 22 Dec 2022 19:13:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and addressed comments by @XueleiFan and @ascarpino
>
> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 163:
> 
>> 161:             SSLSessionContextImpl serverCache =
>> 162:                 (SSLSessionContextImpl)hc.sslContext.engineGetServerSessionContext();
>> 163:             return serverCache.getKey();
> 
> I think the `HandshakeContext hc` could be passed as a parameter for the getKey() method, and thus you have a way to get the secure random for StatelessKey().
> 
>       return serverCache.getKey(hc);
> ->     SessionTicketExtension.StatelessKey getKey(HandshakeContext hc) {
> ->     ssk = new SessionTicketExtension.StatelessKey(hc, newID);
> ->     StatelessKey(HandshakeContext hc, int newNum) {
> ->     kg.init(KEYLEN, hc.sslContext.getSecureRandom());

Done.

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

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

From jwilhelm at openjdk.org  Fri Dec 23 11:28:55 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 23 Dec 2022 11:28:55 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
References: <dcbxW50q2KMbb5q8mKS1UJ3Ihxpb8U-MSd2dt29r5R0=.65568df4-6705-4285-8cae-0e0043311df3@github.com>
Message-ID: <Qpqs-x1BDsAeBRIOYkSaGMve-66Gv1MsBzE83e5C_Nc=.b629f16d-7df6-482d-bcc0-d9d8a27380fd@github.com>

On Fri, 23 Dec 2022 10:48:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 19ce23c6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19ce23c6459a452c8d3856b9ed96bfa54a8346ae
Stats:     572 lines in 15 files changed: 407 ins; 76 del; 89 mod

Merge

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

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

From simonis at openjdk.org  Fri Dec 23 11:51:32 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 11:51:32 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts [v5]
In-Reply-To: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
Message-ID: <sZRhosUwjIv2lcRhOXsJ2qzKkhz9WpgKHvj8NkWaQfk=.3f1d0524-60fe-4095-b2b2-810c9b09bc1e@github.com>

> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s.
> 
> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads.
> 
> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe.
> 
> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues.
> 
> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000
> 605:             1             32  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
>   11:          1000          32000  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> With my proposed patch, the numbers goes back to two instances again:
> 
> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000
> 611:             2             64  sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal)
> 
> 
> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Use HandshakeContext's secure random for keygen in StatelessKey and improve initialization in SSLSessionContextImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11590/files
  - new: https://git.openjdk.org/jdk/pull/11590/files/ece9c733..68ed71dd

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

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

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

From simonis at openjdk.org  Fri Dec 23 11:56:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 23 Dec 2022 11:56:58 GMT
Subject: RFR: 8298381: Improve handling of session tickets for multiple
 SSLContexts
In-Reply-To: <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
References: <wSSObs5K1aJksbR02e7l1lByF2Nw0QjOzrAEiC5BA2w=.71f5b651-542c-40ac-8a71-e5d4001f5ba4@github.com>
 <Dc09Ty5iWLjR6WjFHVLPdPUCEDP_wFhwbYRgNPIREOc=.27d4f596-19b5-4913-8709-84780610cbbe@github.com>
 <1tyFc_T8kdFJqx-FCKPFk1jOGrr-dQrpeCYHN2O-dA8=.249e0225-0772-4e14-a012-f5b43dc17b2d@github.com>
Message-ID: <ddU-e0UoBGit4dJ2Y7LxYHsU9vIx_7aY04tLYOqwyl8=.f8974d19-b294-4b22-8576-e1b949b7288c@github.com>

On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>>> The same example with the 1000 connections being opened alternatively on two different contexts will instead create 1000 `StatelessKey` instances:
>> 
>> That's obviously not the expected behaviors.  It is a good catch for the `static currentKeyID` issue.
>> 
>> What do you think to move `SSLContextImpl.keyHashMap` into `SSLSessionContextImpl`?  I would like to have SSLContextImpl focusing on configuration.
>
> Hi @XueleiFan, @ascarpino,
> 
> Thank you for your reviews and comments. I think I've addressed all of your suggestions in the latest version of the PR.
> 
> There's just one more thing I had to change. Now that I've moved all the logic to `SSLSessionContextImpl` I can't get a reference to `SSLContextImpl`s secure random instance any more when creating a new `StatelessKey`. For simplicity I've therefor decided to use the `KeyGenerator.init()` method which doesn't require an extra secure random instance. 
> 
> If you think that it is important that the `KeyGenerator` uses the same secure random instance like the corresponding `SSLContextImpl`, I can easily change `SSLSessionContextImpl::getKey()` to take a `SecureRandom` argument and pass `SSLContextImpl`s secure random instance down to  `SSLSessionContextImpl::getKey()` (and up to `StatelessKey::<init>`) when calling `getKey()` from `KeyState::getCurrentKey()`.
> 
> What do you think?

> @simonis, I don't think @XueleiFan and I are going to finish reviews by Friday. As Oracle has next week off, I suggest you update the copyrights to 2023 and we can integrate next year one all the comments have been resolved.

>From my understanding there hasn't been much left to resolve except using `HandshakeContext`s secure random for the key generation in `StatelessKey`  and some minor initialization improvements in `SSLSessionContextImpl` which I've just pushed both.

So if you'll find some time to approve the PR this year it'll be great. Otherwise, it will be easy to update the copyright years if that will be last issue :)

Thanks for your support and have a nice and peaceful end of year,
Volker

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

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

From duke at openjdk.org  Fri Dec 23 17:15:25 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 23 Dec 2022 17:15:25 GMT
Subject: RFR: 8298874: Update TestAllSuites.java for TLS v1.2 and 1.3
Message-ID: <vNwQ6EUHIarE-ckuoWktruvCu8BU83nbZQgxdi0YIsE=.7cd7e412-d870-4a91-a6f8-f7131cd827d5@github.com>

* updated test for new TLS protocols and ciphersuites
* code cleanup

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

Commit messages:
 - 8298874: Update TestAllSuites.java for TLS v1.2 and 1.3

Changes: https://git.openjdk.org/jdk/pull/11780/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298874
  Stats: 187 lines in 2 files changed: 70 ins; 41 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/11780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11780/head:pull/11780

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

From mpowers at openjdk.org  Fri Dec 23 21:43:49 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 23 Dec 2022 21:43:49 GMT
Subject: [jdk20] RFR: JDK-8299235 broken link referencing missing id
Message-ID: <b6NJKZqOS7aRXcmQyewzXO9whIulEYV5-pAw5rdEvmU=.4b2bd092-a489-485b-9b3a-9a8c1e668606@github.com>

https://bugs.openjdk.org/browse/JDK-8299235

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

Commit messages:
 - first iteration

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

PR: https://git.openjdk.org/jdk20/pull/77

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
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: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@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 seven commits:

 - Merge ../jdk-openjdk into typos-typos
 - 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=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 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 mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

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

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

From mbaesken at openjdk.org  Wed Dec 28 08:30:53 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 08:30:53 GMT
Subject: Integrated: JDK-8235297:
 sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails
 intermittent
In-Reply-To: <JH9tFs6bUyXRVMWpIV8mYDjrFVcpcOY4COdwsB3TQW8=.50f21e20-ac3f-47c9-b2b3-6cf8d0b09bdd@github.com>
References: <JH9tFs6bUyXRVMWpIV8mYDjrFVcpcOY4COdwsB3TQW8=.50f21e20-ac3f-47c9-b2b3-6cf8d0b09bdd@github.com>
Message-ID: <F8Hyp8k3OG6uizpE1mSzzK1SWT-zS9o2N0QsQbwJ0zE=.cf745750-6dc4-4c2b-9cd3-43b1fde175d1@github.com>

On Thu, 22 Dec 2022 11:44:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test  sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent with timeouts ,  this info should be added to the test.

This pull request has now been integrated.

Changeset: d490f15e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d490f15e3b8222d0ba80e2161cc3f063092fc460
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8235297: sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent

Reviewed-by: xuelei

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

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

From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: RFR: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <lGGwZvwa0eAtXlap63EaW0vJxvWj_u_g1eG_0D7HaaI=.ee110e67-29a4-4120-a048-d1835913e3d0@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

okay, if keeping the block in the code that contains free and return, we probably just stay with what we have


if ((*env)->ExceptionCheck(env)) {
  free(xyz);
  return val;
}

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

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

From mbaesken at openjdk.org  Wed Dec 28 14:30:56 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Dec 2022 14:30:56 GMT
Subject: Withdrawn: JDK-8298170 : Introduce a macro for exception check,
 free and return
In-Reply-To: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
References: <90ZFDKRphHvOnZhdWYgDfGcsmXZsorQa9B_cX665I30=.769ba1d7-d248-4c24-b2c1-7a59e5e6bf58@github.com>
Message-ID: <hovzXng89xaaB2qEqOczilkrVMvf20YRYcHirL9CZ8k=.24116009-ed32-4562-9c00-a859bb2c8494@github.com>

On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of places in the codebase  where a macro could help when we check an exception and afterwrads free something and return.

This pull request has been closed without being integrated.

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

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

From jnimeh at openjdk.org  Wed Dec 28 16:06:40 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 28 Dec 2022 16:06:40 GMT
Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20 and
 Poly1305 intrinsics
Message-ID: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>

This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.

- JBS: https://bugs.openjdk.org/browse/JDK-8298592
- Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )

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

Commit messages:
 - 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics

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

PR: https://git.openjdk.org/jdk20/pull/78

From jnimeh at openjdk.org  Thu Dec 29 15:47:37 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 29 Dec 2022 15:47:37 GMT
Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20
 and Poly1305 intrinsics [v2]
In-Reply-To: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
Message-ID: <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>

> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add highlighting for intrinsic diag switch title

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/78/files
  - new: https://git.openjdk.org/jdk20/pull/78/files/83b7df59..4b0c4cd6

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

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

PR: https://git.openjdk.org/jdk20/pull/78

From weijun at openjdk.org  Thu Dec 29 20:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Dec 2022 20:47:02 GMT
Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20
 and Poly1305 intrinsics [v2]
In-Reply-To: <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
 <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>
Message-ID: <kxCRYX5UznDM65ljKq9Mzk1mj9WofTfkd6e2SnUAIFQ=.50f58bf4-6739-4e61-b324-cefcece1b2e3@github.com>

On Thu, 29 Dec 2022 15:47:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
>> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add highlighting for intrinsic diag switch title

Marked as reviewed by weijun (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/78

From jnimeh at openjdk.org  Thu Dec 29 22:38:01 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 29 Dec 2022 22:38:01 GMT
Subject: [jdk20] Integrated: 8298592: Add java man page documentation for
 ChaCha20 and Poly1305 intrinsics
In-Reply-To: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
Message-ID: <7u_1vMLUmsiYoCiAvJC1D6ayHzfLN-vsyXIgU5bhJrU=.c5a803a9-ad97-4616-8c16-801121d4e732@github.com>

On Wed, 28 Dec 2022 15:54:49 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )

This pull request has now been integrated.

Changeset: 37f8b059
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/37f8b059c1c9245e7f3af90d6ed47c862fee54a3
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk20/pull/78