From valeriep at openjdk.java.net  Tue Dec  1 00:49:13 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 1 Dec 2020 00:49:13 GMT
Subject: RFR: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header
 files [v4]
In-Reply-To: <czQeMeuSEDsE8AIAFu_voFDrnWo3-sy78y6OtcQ-nuY=.801ee2d6-643c-44b1-9520-a76dc42b9436@github.com>
References: <czQeMeuSEDsE8AIAFu_voFDrnWo3-sy78y6OtcQ-nuY=.801ee2d6-643c-44b1-9520-a76dc42b9436@github.com>
Message-ID: <Lk9phixzKyKmTsue4EyDxsaQPRu6l9qYKO0AZjVe0OQ=.77e43fe7-f585-428a-b66a-a4c02f50d01c@github.com>

> Could someone please help review this PKCS#11 v3.0 header files update?
> 
> Changes are straight-forward as below:
> 1) Updated pkcs11.h, pkcs11f.h, pkcs11t.h to v3.0
> 2) Updated java side w/ the new constants definitions and name/error code mappings.
> 
> For the native headers, it's a direct copy of the official v3.0 headers except that I have to remove the tab space, and trailing white spaces due to JDK code requirement. I verified the result using 'diff -w'. As for the java side, the edit is based on the diff of native headers. I also commented out some of the unused native identifiers at java side.
> 
> I am adding the SHA-3 digests, signatures, and macs in a separate RFE and would need this one to be reviewed/integrated first.
> 
> Thanks,
> Valerie

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

  Update the license file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/917/files
  - new: https://git.openjdk.java.net/jdk/pull/917/files/03f1b67a..74bdf869

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

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

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

From valeriep at openjdk.java.net  Tue Dec  1 00:52:59 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 1 Dec 2020 00:52:59 GMT
Subject: Integrated: 8244154: Update SunPKCS11 provider with PKCS11 v3.0
 header files
In-Reply-To: <czQeMeuSEDsE8AIAFu_voFDrnWo3-sy78y6OtcQ-nuY=.801ee2d6-643c-44b1-9520-a76dc42b9436@github.com>
References: <czQeMeuSEDsE8AIAFu_voFDrnWo3-sy78y6OtcQ-nuY=.801ee2d6-643c-44b1-9520-a76dc42b9436@github.com>
Message-ID: <QQ6ERccwLOFiJj9pu9m3Y1WourY3zxJBz1Ua9cwKnaY=.5857e90f-99a0-4ef3-8161-b5465cf32570@github.com>

On Wed, 28 Oct 2020 21:35:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this PKCS#11 v3.0 header files update?
> 
> Changes are straight-forward as below:
> 1) Updated pkcs11.h, pkcs11f.h, pkcs11t.h to v3.0
> 2) Updated java side w/ the new constants definitions and name/error code mappings.
> 
> For the native headers, it's a direct copy of the official v3.0 headers except that I have to remove the tab space, and trailing white spaces due to JDK code requirement. I verified the result using 'diff -w'. As for the java side, the edit is based on the diff of native headers. I also commented out some of the unused native identifiers at java side.
> 
> I am adding the SHA-3 digests, signatures, and macs in a separate RFE and would need this one to be reviewed/integrated first.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 7d898524
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d898524
Stats:     1818 lines in 7 files changed: 1215 ins; 69 del; 534 mod

8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files

Reviewed-by: weijun

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

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

From jjiang at openjdk.java.net  Tue Dec  1 01:53:56 2020
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 1 Dec 2020 01:53:56 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>

On Sat, 21 Nov 2020 11:45:42 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Just a question.
Do we have clear guideline or requirement for using this new lang feature?
We know there are a lot of old switch-case blocks in the existing codes,
including source codes and test codes.

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

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

From pconcannon at openjdk.java.net  Tue Dec  1 12:07:57 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 1 Dec 2020 12:07:57 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v2]
In-Reply-To: <xwCLbC42-nf62CT_UV37yw0N3VgRlJ-YxKC0ho1-RD8=.9407c92e-a189-43ea-ad45-74ec0318ae4c@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <xwCLbC42-nf62CT_UV37yw0N3VgRlJ-YxKC0ho1-RD8=.9407c92e-a189-43ea-ad45-74ec0318ae4c@github.com>
Message-ID: <CnhHotuAcIHz_E7fx7jxGZwCBVkacTgpe37mrieAfCg=.089234a4-3f49-4066-9957-54d9b28c8302@github.com>

On Mon, 30 Nov 2020 13:04:11 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 74:

> 72: 
> 73:     private String name(int i) {
> 74:         return switch (i + 1) {

Hi Kartik. I think it would improve the readability for each of the switch/case expressions if you tab aligned each of the cases, and place the default case on its own line e.g.

   
        
        return switch (i + 1) {
            case HEADER_TABLE_SIZE      -> "HEADER_TABLE_SIZE";
            case ENABLE_PUSH            -> "ENABLE_PUSH";
            case MAX_CONCURRENT_STREAMS -> "MAX_CONCURRENT_STREAMS";
            case INITIAL_WINDOW_SIZE    -> "INITIAL_WINDOW_SIZE";
            case MAX_FRAME_SIZE         -> "MAX_FRAME_SIZE";
            case MAX_HEADER_LIST_SIZE   -> "MAX_HEADER_LIST_SIZE";

            default -> "unknown parameter";
        };

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

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

From dfuchs at openjdk.java.net  Tue Dec  1 12:40:54 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 1 Dec 2020 12:40:54 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http
In-Reply-To: <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>
Message-ID: <kZ4tF8MrzOGPXFmgVitbDUMQFoAp1shdWIs-hmAguqc=.d754b826-7479-48e7-a84f-8ec795aadf41@github.com>

On Tue, 1 Dec 2020 01:51:35 GMT, John Jiang <jjiang at openjdk.org> wrote:

> Do we have clear guideline or requirement for using this new lang feature?
> We know there are a lot of old switch-case blocks in the existing codes,
> including source codes and test codes.

@johnshajiang I don't think we have any global guideline but in this specific case I agree that using switch expressions as proposed is making the code generally more readable, with maybe a few cases where it might not have improved readability as much (for instance I'm not a big fan of line 54 in that file: https://github.com/openjdk/jdk/pull/1364/files#diff-ae0f662913a65511f983a3f0f9a98b708c11906a6f87aa4c96ab6fc7abf5ae9f )

best regards,

-- daniel

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

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

From dfuchs at openjdk.java.net  Tue Dec  1 21:27:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 1 Dec 2020 21:27:10 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 353:

> 351:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
> 352:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
> 353:  *         ...

Hi Brad,

There's a missing closing parenthesis here on line 352. 

Additionally - the unicode characters in the string above will be substituted by the compiler before the API documentation is generated. I am suspecting that this is not what you want. If you want to see the literal unicode escape in the generated documentation, you will need to employ some tricks. One of them could be to use the unicode escape of \ instead of \ to prevent the compiler from interpreting \uabcd as a unicode escape.

Something like:

 *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
 *     if (unicodeString.equals("\u005cuabcd\u005cuabce\u005cuabcf")) {

would do the trick. Alternatively - this would probably work too:

 *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
 *     {@code if (unicodeString.equals("}{@code uabcd}{@code uabce}{@code uabcf"))} {

I realize none of these alternatives are ideal - maybe someone knows a better trick...

src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 146:

> 144:  *
> 145:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
> 146:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {

Same remark here

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:09 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:09 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
Message-ID: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>

Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.

Full details are available in:

- Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
- CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

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

Commit messages:
 - Code Review Comments 4
 - Code Review Comments #3
 - Code Review Comments #2
 - Code Review Comments
 - Seventh iteration
 - Sixth iteration
 - Fifth iteration
 - Fourth iteration
 - Third iteration
 - Second iteration
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b52f6c05...9e6f0a4f

Changes: https://git.openjdk.java.net/jdk/pull/1440/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1440&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254631
  Stats: 451 lines in 6 files changed: 440 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1440.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1440/head:pull/1440

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
 <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>
Message-ID: <iQOk4zo2TjYeFL-lQjLn7XaC7ULBV3DZkcw9QOHWn-A=.378cffd3-fc2b-4a84-8acb-44b072d6825b@github.com>

On Thu, 26 Nov 2020 10:33:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
>> 
>> Full details are available in:
>> 
>> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
>> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 353:
> 
>> 351:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>> 352:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
>> 353:  *         ...
> 
> Hi Brad,
> 
> There's a missing closing parenthesis here on line 352. 
> 
> Additionally - the unicode characters in the string above will be substituted by the compiler before the API documentation is generated. I am suspecting that this is not what you want. If you want to see the literal unicode escape in the generated documentation, you will need to employ some tricks. One of them could be to use the unicode escape of \ instead of \ to prevent the compiler from interpreting \uabcd as a unicode escape.
> 
> Something like:
> 
>  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>  *     if (unicodeString.equals("\u005cuabcd\u005cuabce\u005cuabcf")) {
> 
> would do the trick. Alternatively - this would probably work too:
> 
>  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>  *     {@code if (unicodeString.equals("}{@code uabcd}{@code uabce}{@code uabcf"))} {
> 
> I realize none of these alternatives are ideal - maybe someone knows a better trick...

I made this change in SSLParameters, and forgot that I had a similar change to make in SSLEngine/SSLSocket.

> src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 146:
> 
>> 144:  *
>> 145:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>> 146:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
> 
> Same remark here

Also fixed using \u005c.

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <T7m8sRkEeHWahPwFEFDe-ukadDcp7kFpNW4uqzED0s4=.4932d4b6-f616-4ba6-9a8a-327366ca5aa0@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

I am not able to see the comment here in github due to the Terms of Use issue flagged by github, but did get email with the issue so I'm hoping/assuming that the terms have been accepted.

For this test, I just took the standard JSSE test template and added the few lines to check for the proper ALPN exchange.

I'm 99% sure that for the JDK testsuite, the default Charset is UTF-8 which will accept ASCII values like this.  If not, there's going to be a lot more problems.  :)

Consulted with the Sustaining Team, they requested that this note not be included, as the versions are not yet known.

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:13 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:13 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
 <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>
Message-ID: <po-_Vbi2Ng-mabLPoRZv_87XbM-DopXhNG3U_0ENQm4=.a6a0bc89-8650-42e4-9dfb-878223835e18@github.com>

On Thu, 26 Nov 2020 20:26:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
>> 
>> Full details are available in:
>> 
>> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
>> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 341:
> 
>> 339:  * The ApplicationProtocol {@code String} values returned by the methods in
>> 340:  * this class are in the network byte representation sent by the peer and
>> 341:  * may need to be converted to its Unicode format before use.  For example,
> 
> I think there are two possible directions to use the bytes, concerting application ALPN representation to network byte representation, or concerting network bytes to application representation.  The 1st sentence, I may focus on the the network byte representation description.
> 
> "The ApplicationProtocol {@code String} values returned by the methods in this class are in the network byte representation sent by the peer.  If an ALPN value is not encoded in network byte ..., an conversion may be required.  For example, ..."

Discussed with Xuelei, the concern was it wasn't clear that you could compare using byte[] or Strings, and possible byte encodings that might be received.  I believe these have been addressed in the current version.

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

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

From xuelei at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 341:

> 339:  * The ApplicationProtocol {@code String} values returned by the methods in
> 340:  * this class are in the network byte representation sent by the peer and
> 341:  * may need to be converted to its Unicode format before use.  For example,

I think there are two possible directions to use the bytes, concerting application ALPN representation to network byte representation, or concerting network bytes to application representation.  The 1st sentence, I may focus on the the network byte representation description.

"The ApplicationProtocol {@code String} values returned by the methods in this class are in the network byte representation sent by the peer.  If an ALPN value is not encoded in network byte ..., an conversion may be required.  For example, ..."

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

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

From valeriep at openjdk.java.net  Tue Dec  1 21:59:13 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 1 Dec 2020 21:59:13 GMT
Subject: RFR: 8242332: Add SHA3 support to SunPKCS11 provider
Message-ID: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>

Could someone please help review this RFE? SunPKCS11 provider is updated with SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA Signature, and Hmac KeyGenerator.

As SHA-3 can be used as drop-in replacement for SHA-2 which are already supported by SunPKCS11 provider, the changes for MessageDigest, Mac, and Signature are straightforward. P11KeyGenerator class is updated to support general Hmac key generation including SHA-3 and more. 

While testing against NSS 3.57, there are some unexpected NSS errors with CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those mechanisms in the NSS config file for regression tests. For ECDSA signatures, SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting ourselves.

Thanks,
Valerie

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

Commit messages:
 - Fixed javadoc of P11KeyGenerator class
 - 8242332: Add SHA3 support to SunPKCS11 provider

Changes: https://git.openjdk.java.net/jdk/pull/1546/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1546&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242332
  Stats: 1505 lines in 25 files changed: 885 ins; 465 del; 155 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1546/head:pull/1546

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

From valeriep at openjdk.java.net  Tue Dec  1 23:21:11 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 1 Dec 2020 23:21:11 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
Message-ID: <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>

On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - test updates
>  - test check mixup
>  - Overlap protection
>  - Updated code comments, all tests pass
>  - Updated code comments, all tests pass

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

> 555:                 // If a block or more was encrypted from 'buffer' only, but the
> 556:                 // rest of 'buffer' with 'in' could not construct a block, then
> 557:                 // put the rest if 'buffer' back into ibuffer.

typo: if => of

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

> 537:             // Construct and encrypt a block if there is enough 'buffer' and
> 538:             // 'in' to make one
> 539:             if ((inLen + remainder) >= blockSize) {

This big block of code is only needed when (remainder != 0), right?

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

> 552:                 ibuffer.reset();
> 553:                 // Code below will write the remainder from 'in' to ibuffer
> 554:             } else if (blen > 0) {

Instead of blen >0, maybe you meant remainder > 0?

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

> 512:         checkDataLength(inLen, getBufferedLength());
> 513:         ArrayUtil.nullAndBoundsCheck(in, inOfs, inLen);
> 514: 

How about checking out, outOfs with ArrayUtil.nullAndBoundsCheck(...) call? I saw one below, but there are already prior calls writing into out. Existing impl checks it before writing data into it.

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

> 578: 
> 579:         // Encrypt the remaining blocks inside of 'in'
> 580:         if (len > 0) {

Shouldn't this be 'inLen' instead of 'len'?

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

> 655:      */
> 656:     int decrypt(byte[] in, int inOfs, int len, byte[] out, int outOfs) {
> 657:         checkDataLength(ibuffer.size(), len);

Just curious, why remove this checkDataLength(...) call? Seems inconsistent to other methods?

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

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

From valeriep at openjdk.java.net  Wed Dec  2 00:38:09 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 2 Dec 2020 00:38:09 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
Message-ID: <lrUZG9UH9miy5Xd8mZJ5E43OC9vCBy9q1JDYp0zZ_xE=.ef015b8e-3e52-420e-b91a-08f61b0ebd87@github.com>

On Thu, 26 Nov 2020 02:14:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - test updates
>  - test check mixup
>  - Overlap protection
>  - Updated code comments, all tests pass
>  - Updated code comments, all tests pass

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

> 908:         // Decrypt the all the input data and put it into dst
> 909:         doLastBlock(buffer, ct, dst);
> 910:         dst.limit(dst.position());

Based on Cipher javadoc, the output buffer's limit should remain the same, just its position be advanced by the number of bytes written into it. So, we should not call limit(int) to set a new limit on user-specified ByteBuffer objects.

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

> 998:         tmp.position(dst.position());
> 999:         bb.put(tmp);
> 1000:         bb.flip();

Since we don't need to read the content of output buffer, I suppose we can just do ByteBuffer.allocate(dst.remaining())?

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

> 933:      */
> 934:     ByteBuffer overlapDetection(ByteBuffer src, ByteBuffer dst) {
> 935:         if (src.isDirect() && dst.isDirect()) {

originalDst is only set to null at construction time. It should be reset here or in restoreDst(). Otherwise, there may be some strange interaction between various ByteBuffer calls using the same Cipher object. Say, the first call uses an extra copy and set originalDst, then the second call does not, but originalDst is still non-null.

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

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

From valeriep at openjdk.java.net  Wed Dec  2 01:11:57 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 2 Dec 2020 01:11:57 GMT
Subject: RFR: 8242332: Add SHA3 support to SunPKCS11 provider
In-Reply-To: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
References: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
Message-ID: <uY2pUKLNPaE1cZ4ubwCOVnH2mGMb6_-HWGYPjSzq8U0=.67861b21-696f-4625-8eae-ebbb4a73848b@github.com>

On Tue, 1 Dec 2020 21:51:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this RFE? SunPKCS11 provider is updated with SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA Signature, and Hmac KeyGenerator.
> 
> As SHA-3 can be used as drop-in replacement for SHA-2 which are already supported by SunPKCS11 provider, the changes for MessageDigest, Mac, and Signature are straightforward. P11KeyGenerator class is updated to support general Hmac key generation including SHA-3 and more. 
> 
> While testing against NSS 3.57, there are some unexpected NSS errors with CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those mechanisms in the NSS config file for regression tests. For ECDSA signatures, SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting ourselves.
> 
> Thanks,
> Valerie

Please also review CSR at https://bugs.openjdk.java.net/browse/JDK-8256082
Thanks~

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

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

From xuelei at openjdk.java.net  Wed Dec  2 02:18:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 02:18:58 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <4S5Tvet2ywtZza1zto6XTi62wbHL4kqTbqtvDwK_hbg=.6e71357e-0f59-4895-9cb1-1cb63426b276@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

Marked as reviewed by xuelei (Reviewer).

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 02:39:10 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 02:39:10 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
 <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
Message-ID: <CHeYpIxADX8sAxJvR-ESFxCtW0C62qhgX-siu-SG0lc=.8a3c55cf-0762-4833-9952-2b037bf2c8d8@github.com>

On Tue, 1 Dec 2020 22:42:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - test updates
>>  - test check mixup
>>  - Overlap protection
>>  - Updated code comments, all tests pass
>>  - Updated code comments, all tests pass
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 539:
> 
>> 537:             // Construct and encrypt a block if there is enough 'buffer' and
>> 538:             // 'in' to make one
>> 539:             if ((inLen + remainder) >= blockSize) {
> 
> This big block of code is only needed when (remainder != 0), right?

If there is nothing in the ibuffer, then it never gets here.  Yes.

btw, make sure you're looking at the right webrev, the line numbers didn't match up with revision 4.

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 03:05:09 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 03:05:09 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
 <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
Message-ID: <oZZpVhk-oTt_mnUfTf9Df89J1TE-jV4BIiRzWGcDrXU=.59346354-5120-4840-9ec6-90731f1631ac@github.com>

On Tue, 1 Dec 2020 22:44:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - test updates
>>  - test check mixup
>>  - Overlap protection
>>  - Updated code comments, all tests pass
>>  - Updated code comments, all tests pass
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 554:
> 
>> 552:                 ibuffer.reset();
>> 553:                 // Code below will write the remainder from 'in' to ibuffer
>> 554:             } else if (blen > 0) {
> 
> Instead of blen >0, maybe you meant remainder > 0?

Yes, you're right, it should be remainder.

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 03:18:11 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 03:18:11 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
 <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
Message-ID: <uLS3w0MBuH1zeD67mWw_KSEly8chGacQf7hApKSPeJM=.6c55221c-fd51-4099-94b1-c5f4303ec523@github.com>

On Tue, 1 Dec 2020 22:53:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - test updates
>>  - test check mixup
>>  - Overlap protection
>>  - Updated code comments, all tests pass
>>  - Updated code comments, all tests pass
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 514:
> 
>> 512:         checkDataLength(inLen, getBufferedLength());
>> 513:         ArrayUtil.nullAndBoundsCheck(in, inOfs, inLen);
>> 514: 
> 
> How about checking out, outOfs with ArrayUtil.nullAndBoundsCheck(...) call? I saw one below, but there are already prior calls writing into out. Existing impl checks it before writing data into it.

Yes, I'll add it back in.. I wanted to change it so it would verify correctly output length rather than inLen, which is not necessarily right given there is ibuffer available.  Maybe Ill try to do that in a later update.

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 580:
> 
>> 578: 
>> 579:         // Encrypt the remaining blocks inside of 'in'
>> 580:         if (len > 0) {
> 
> Shouldn't this be 'inLen' instead of 'len'?

Yes, that appears to be right

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 03:31:08 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 03:31:08 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
 <6QM0e4AACzjO6zLru7knvlN3p_nM6g9NWcMWcVgEpoI=.dfea4260-a287-453b-8fbb-963243f9aa8f@github.com>
Message-ID: <mB2dxZjgTJUjfDScP4YtU131MY73RAIYxXAvQZYPiJ8=.f6ef591f-489f-4cc0-b144-35cc0839e53a@github.com>

On Tue, 1 Dec 2020 23:14:19 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - test updates
>>  - test check mixup
>>  - Overlap protection
>>  - Updated code comments, all tests pass
>>  - Updated code comments, all tests pass
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 657:
> 
>> 655:      */
>> 656:     int decrypt(byte[] in, int inOfs, int len, byte[] out, int outOfs) {
>> 657:         checkDataLength(ibuffer.size(), len);
> 
> Just curious, why remove this checkDataLength(...) call? Seems inconsistent to other methods?

All decrypt() does is put the data into the ibuffer.  I didn't find it useful to calculate that data lengths for the GCM rollover when decryption was not happening.  It's probably a personal preference to wait until doFinal().  The situation when ibuffer is > 64M is very unlikely.

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 910:
> 
>> 908:         // Decrypt the all the input data and put it into dst
>> 909:         doLastBlock(buffer, ct, dst);
>> 910:         dst.limit(dst.position());
> 
> Based on Cipher javadoc, the output buffer's limit should remain the same, just its position be advanced by the number of bytes written into it. So, we should not call limit(int) to set a new limit on user-specified ByteBuffer objects.

ok

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 935:
> 
>> 933:      */
>> 934:     ByteBuffer overlapDetection(ByteBuffer src, ByteBuffer dst) {
>> 935:         if (src.isDirect() && dst.isDirect()) {
> 
> originalDst is only set to null at construction time. It should be reset here or in restoreDst(). Otherwise, there may be some strange interaction between various ByteBuffer calls using the same Cipher object. Say, the first call uses an extra copy and set originalDst, then the second call does not, but originalDst is still non-null.

Yeah, that makes sense.

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 03:36:10 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 03:36:10 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v5]
In-Reply-To: <lrUZG9UH9miy5Xd8mZJ5E43OC9vCBy9q1JDYp0zZ_xE=.ef015b8e-3e52-420e-b91a-08f61b0ebd87@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <V6X_e9VdjZexULIAFTHSX4DWgBfoSdBw17R8pg5hKDo=.4ae26e91-5972-4de7-92f5-c9d946f67cb9@github.com>
 <lrUZG9UH9miy5Xd8mZJ5E43OC9vCBy9q1JDYp0zZ_xE=.ef015b8e-3e52-420e-b91a-08f61b0ebd87@github.com>
Message-ID: <IfM81WTsZhLJvr3zYNgccGHwLj7ocnyjbNemRmjekmM=.ed3de34e-15f8-4576-8849-67c44a34d961@github.com>

On Wed, 2 Dec 2020 00:02:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - test updates
>>  - test check mixup
>>  - Overlap protection
>>  - Updated code comments, all tests pass
>>  - Updated code comments, all tests pass
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1000:
> 
>> 998:         tmp.position(dst.position());
>> 999:         bb.put(tmp);
>> 1000:         bb.flip();
> 
> Since we don't need to read the content of output buffer, I suppose we can just do ByteBuffer.allocate(dst.remaining())?

yes, remaining() is good here.

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

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

From wetmore at openjdk.java.net  Wed Dec  2 04:17:59 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 2 Dec 2020 04:17:59 GMT
Subject: Integrated: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <ZCJq8GDjts0vDcdy2cVetasHRVVFTGQViKy63Fl1v94=.e0aef136-1802-4fa3-9293-d0cf581a0813@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

This pull request has now been integrated.

Changeset: fe5cccc1
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe5cccc1
Stats:     451 lines in 6 files changed: 440 ins; 1 del; 10 mod

8254631: Better support ALPN byte wire values in SunJSSE

Reviewed-by: xuelei, dfuchs

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 05:01:28 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 05:01:28 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v6]
In-Reply-To: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
Message-ID: <4ahM8RttKuOnFWEgKagrpajFm3Wi2uq_G6BTWDuAo4Y=.48fea738-627f-4b3e-9ce4-1b0cba8dea1c@github.com>

> 8253821: Improve ByteBuffer performance with GCM

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

  comments v4

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/411/files
  - new: https://git.openjdk.java.net/jdk/pull/411/files/836bf3ed..3a2f614e

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

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 05:01:28 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 05:01:28 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v6]
In-Reply-To: <hw5T-JCopKVN9OEQ0o90wdKrV4SZicqhEsCEhwPncME=.f0f9d178-6a3e-4e02-8ded-dfed98cc3a07@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <9IvsxvHGzvQoM756tUBFHLcMyZjvdbevzh7c-I3i6zU=.03c89dcb-a547-4a07-b0db-358fa9b3fe27@github.com>
 <ffzrbvhNAQR0xEOdWAKHRBHeWwjG1xWT8DA5Ti8xZIA=.e4ce288d-277f-49b9-ba9c-f660e312dff9@github.com>
 <MdIHGvNOnH5n120ZPSjcfXdb79GjfgxON4dqhxNy4x0=.0278db81-9124-497d-ad8d-bcca1f22142a@github.com>
 <hw5T-JCopKVN9OEQ0o90wdKrV4SZicqhEsCEhwPncME=.f0f9d178-6a3e-4e02-8ded-dfed98cc3a07@github.com>
Message-ID: <Qjnm9R7qRTRLS0ofAQ6FedOk5nHJdzsBjNbWRaTRVBA=.c8be0ddf-a9a3-4b9a-99fc-6e4917d56a68@github.com>

On Thu, 26 Nov 2020 02:18:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> The latest update should address all outstanding comments.  The biggest change was to the test, which had major reorganization and created tests that increments data sizes for update and doFinal ops byte-by-byte to check for any errors.  That should reduce concerns about buffer corruption.
>
> The biggest part of this change is the addition of overlap protection and the tests to verify it for GCM, as there were none in the open repo.  Additionally, GCMBufferTest had some significant changes to clean it up and handle offsets better.  All tests pass.  With RDP1 coming, I want to get this into the repo soon, so please limit comments to bugs. Any "nice to have" changes, they can be added onto follow-on changes I plan.

Webrev updated with latest comments..  rev 5.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 09:26:11 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 09:26:11 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v3]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <AMNvpmPxqHpk9jo5D-Xkr0qErLjYp61j8JRalOA843w=.fe0f0790-8c8f-47ad-b219-f325d58b1f62@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

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

  Vertically align statements in switch expressions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/542298e0..7fa11daf

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

  Stats: 74 lines in 14 files changed: 14 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1364/head:pull/1364

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 09:42:09 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 09:42:09 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Vertically align statements in switch expressions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/7fa11daf..3e667427

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

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

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

From jnimeh at openjdk.java.net  Wed Dec  2 15:35:58 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 2 Dec 2020 15:35:58 GMT
Subject: RFR: JDK-8166596: TLS support for the EdDSA signature algorithm
 [v3]
In-Reply-To: <KZU-TcVnneJlDUFlfk9RIAaLSWkpyc98wSxZPDg7U2U=.360c978e-457a-446b-832d-0baaf28a1eef@github.com>
References: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
 <eT12DXEJPAbP4G6RHwzuBhoyaZw1FUhZk_gOoXxXu_A=.e623532c-769a-4ef4-a5e6-35dd124aa872@github.com>
 <ZUfte32e3N6OkzjcdSD_M6fiY1kwadai2tK9IjO2VP0=.d551119f-5c39-4dd5-826b-f70d2a1ab9b9@github.com>
 <KZU-TcVnneJlDUFlfk9RIAaLSWkpyc98wSxZPDg7U2U=.360c978e-457a-446b-832d-0baaf28a1eef@github.com>
Message-ID: <rJpwImy-C9O6o5bw-eobrVohUy119brKf7E57IVVjOU=.17864f8f-3f9e-408c-9e3c-cca8274b9981@github.com>

On Fri, 20 Nov 2020 20:05:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/JsseJce.java line 97:
>> 
>>> 95:      */
>>> 96:     static final String SIGNATURE_EDDSA = "EdDSA";
>>> 97: 
>> 
>> Please update the copyright year.
>> 
>> Is it possible that "ed25519" or "ed448" is used as the signature algorithm, especially in the X.509 certificate implementation?
>
> SunEC's algorithm name for keys are always "EdDSA", but I know BC returns "Ed25519" or "Ed448".

Filed and took ownership of JDK-8257607 to address BC JCE provider issues for both XDH and EdDSA when used with SunJSSE.

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

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

From chegar at openjdk.java.net  Wed Dec  2 16:17:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 2 Dec 2020 16:17:58 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I think that the actual source changes look good.

A few notes:
1. there are whitespace issues. jcheck is failing.
2. Please so not force push - just push. Force push messes up prior comments in the thread.

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

Marked as reviewed by chegar (Reviewer).

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

From dfuchs at openjdk.java.net  Wed Dec  2 16:25:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 16:25:59 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 82:

> 80:             case MAX_HEADER_LIST_SIZE ->    "MAX_HEADER_LIST_SIZE";
> 81:             
> 82:             default -> "unknown parameter";

> Check failure on line 81 in src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java
> openjdk / jcheck
> 
> Whitespace error
> 
> Column 0: trailing whitespace
> ...

WRT to whitespace errors detected by `jcheck`, note that you can fix them by running the script:

make/scripts/normalizer.pl

on this file.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:17 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:17 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

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

  Align -> and remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/3e667427..e73ab02b

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

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:18 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:18 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>
Message-ID: <I5Dl-JscFeCmHxsOGiaxjSD2da4-GcEu9_OHDCWze98=.3d9835b8-6df8-4e16-9352-eec885be4efa@github.com>

On Wed, 2 Dec 2020 16:15:13 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> I think that the actual source changes look good.
> 
> A few notes:
> 1. there are whitespace issues. jcheck is failing.
> 2. Please do not force push - just push. Force push messes up prior comments in the thread.

@ChrisHegarty Thanks for the review. I'll keep in mind not to use force push again.

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

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

From pconcannon at openjdk.java.net  Wed Dec  2 16:34:19 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 2 Dec 2020 16:34:19 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:

> 117:         while (canContinueParsing(input)) {
> 118:             switch (state) {
> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;

Looks good. Although, I think you can improve it further if you align the lambda operators as well

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:20 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:20 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
Message-ID: <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>

On Wed, 2 Dec 2020 16:26:43 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:
> 
>> 117:         while (canContinueParsing(input)) {
>> 118:             switch (state) {
>> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;
> 
> Looks good. Although, I think you can improve it further if you align the lambda operators as well

Yes right. Just noticed I had missed that. Fixed in latest commit :)

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:21 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:21 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>
Message-ID: <vZEoCuY6RoxhNj69TO7ovTqg1_J_6xz__iIkd_Lw0II=.f33cdf38-4b69-4d51-ab12-068d0698fa49@github.com>

On Wed, 2 Dec 2020 16:23:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kartik Ohri has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 82:
> 
>> 80:             case MAX_HEADER_LIST_SIZE ->    "MAX_HEADER_LIST_SIZE";
>> 81:             
>> 82:             default -> "unknown parameter";
> 
>> Check failure on line 81 in src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java
>> openjdk / jcheck
>> 
>> Whitespace error
>> 
>> Column 0: trailing whitespace
>> ...
> 
> WRT to whitespace errors detected by `jcheck`, note that you can fix them by running the script:
> 
> make/scripts/normalizer.pl
> 
> on this file.

That's handy. Thanks!

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

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

From jnimeh at openjdk.java.net  Wed Dec  2 16:38:00 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 2 Dec 2020 16:38:00 GMT
Subject: RFR: JDK-8166596: TLS support for the EdDSA signature algorithm
 [v3]
In-Reply-To: <rJpwImy-C9O6o5bw-eobrVohUy119brKf7E57IVVjOU=.17864f8f-3f9e-408c-9e3c-cca8274b9981@github.com>
References: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
 <eT12DXEJPAbP4G6RHwzuBhoyaZw1FUhZk_gOoXxXu_A=.e623532c-769a-4ef4-a5e6-35dd124aa872@github.com>
 <ZUfte32e3N6OkzjcdSD_M6fiY1kwadai2tK9IjO2VP0=.d551119f-5c39-4dd5-826b-f70d2a1ab9b9@github.com>
 <KZU-TcVnneJlDUFlfk9RIAaLSWkpyc98wSxZPDg7U2U=.360c978e-457a-446b-832d-0baaf28a1eef@github.com>
 <rJpwImy-C9O6o5bw-eobrVohUy119brKf7E57IVVjOU=.17864f8f-3f9e-408c-9e3c-cca8274b9981@github.com>
Message-ID: <96G2ukwlsKGV3TQrgfcBM6ls91zPON2uYOJG4qqa01s=.db9f0d8a-a3c3-414f-a50d-be3f7be7d5de@github.com>

On Wed, 2 Dec 2020 15:33:20 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> SunEC's algorithm name for keys are always "EdDSA", but I know BC returns "Ed25519" or "Ed448".
>
> Filed and took ownership of JDK-8257607 to address BC JCE provider issues for both XDH and EdDSA when used with SunJSSE.

Also, specific to this particular algorithm the signature type can be EdDSA for both BC and SunJCE, regardless of if the key type is EdDSA (SunJCE) or Ed25519 or Ed448 (BC).  Creating a signature with algorithm EdDSA and the use of the key from either provider will perform a signature of the proper kind.

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

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

From dfuchs at openjdk.java.net  Wed Dec  2 16:39:58 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 16:39:58 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
Message-ID: <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>

On Wed, 2 Dec 2020 16:34:17 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align -> and remove trailing whitespace

Marked as reviewed by dfuchs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Wed Dec  2 16:40:01 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 2 Dec 2020 16:40:01 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
 <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>
Message-ID: <LwCEPGKqk6aAq2fNJNiVIQDgm1ktaLsv_DoN9ZtApGc=.378c3a12-8b2b-4543-9560-8eeb5de4d843@github.com>

On Wed, 2 Dec 2020 16:28:44 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:
>> 
>>> 117:         while (canContinueParsing(input)) {
>>> 118:             switch (state) {
>>> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;
>> 
>> Looks good. Although, I think you can improve it further if you align the lambda operators as well
>
> Yes right. Just noticed I had missed that. Fixed in latest commit :)

Looks much better, Kartik. Thanks

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 17:13:01 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 17:13:01 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size
Message-ID: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>

I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.

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

Commit messages:
 - Remove from problemlist
 - Allow use of ASN.1 for publickeyspec

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

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

From jnimeh at openjdk.java.net  Wed Dec  2 17:14:11 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 2 Dec 2020 17:14:11 GMT
Subject: RFR: JDK-8166596: TLS support for the EdDSA signature algorithm
 [v5]
In-Reply-To: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
References: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
Message-ID: <XtqP9wIK2UcmFmSzKa-S79VnNem96ZZ-1xRyMPM1F5w=.fcbbd0ea-88ae-464d-b0b0-c4e9c4247bad@github.com>

> Hello all,
> This change brings in support for certificates with EdDSA keys (both Ed25519 and Ed448) allowing those signature algorithms to be used both on the certificates themselves and used during the handshaking process for messages like CertificateVerify, ServerKeyExchange and so forth.

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

  Applied code review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1197/files
  - new: https://git.openjdk.java.net/jdk/pull/1197/files/58651fc5..9f9164a5

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

  Stats: 31 lines in 2 files changed: 10 ins; 12 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1197/head:pull/1197

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

From xuelei at openjdk.java.net  Wed Dec  2 17:38:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 17:38:58 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size
In-Reply-To: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
Message-ID: <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>

On Wed, 2 Dec 2020 17:08:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.

Marked as reviewed by xuelei (Reviewer).

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11ECKeyFactory.java line 303:

> 301:                 } else {
> 302:                     point = decodePoint(attributes[0].getByteArray(), params.getCurve());
> 303:                 }

You could save a "!" operation in 299 if switch line 302 and line 300.

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

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

From xuelei at openjdk.java.net  Wed Dec  2 17:45:59 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 17:45:59 GMT
Subject: RFR: JDK-8166596: TLS support for the EdDSA signature algorithm
 [v5]
In-Reply-To: <XtqP9wIK2UcmFmSzKa-S79VnNem96ZZ-1xRyMPM1F5w=.fcbbd0ea-88ae-464d-b0b0-c4e9c4247bad@github.com>
References: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
 <XtqP9wIK2UcmFmSzKa-S79VnNem96ZZ-1xRyMPM1F5w=.fcbbd0ea-88ae-464d-b0b0-c4e9c4247bad@github.com>
Message-ID: <S9MV3fX1HwDbNFp-btBJ1wYzo6fLvhK0BL7Usg1tGdI=.f78be17b-1634-4f75-855b-852ea543cabd@github.com>

On Wed, 2 Dec 2020 17:14:11 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519 and Ed448) allowing those signature algorithms to be used both on the certificates themselves and used during the handshaking process for messages like CertificateVerify, ServerKeyExchange and so forth.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied code review comments

There are still a few minor concerns, but nothing significant.  We could have them addressed in separate bugs.

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

Marked as reviewed by xuelei (Reviewer).

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

From ascarpino at openjdk.java.net  Wed Dec  2 17:51:56 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 17:51:56 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size
In-Reply-To: <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
 <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>
Message-ID: <MNvDSNEDwn3nIlgVjH0SzeQYg60pi_bFyHpAHLzlXro=.8d6396de-d557-4537-b412-3f8354d66199@github.com>

On Wed, 2 Dec 2020 17:34:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11ECKeyFactory.java line 303:
> 
>> 301:                 } else {
>> 302:                     point = decodePoint(attributes[0].getByteArray(), params.getCurve());
>> 303:                 }
> 
> You could save a "!" operation in 299 if switch line 302 and line 300.

I only used "!" for consistency with existing usage in PK11Key.java:1080.    Is there a reason to avoid "!" other than maybe readability?

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

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

From xuelei at openjdk.java.net  Wed Dec  2 18:03:59 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 18:03:59 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v3]
In-Reply-To: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
Message-ID: <AhFn4a4-m00SXjmy4ynUzFLj_ZZolzSyXWVVKLJE4nc=.1bf5edd6-0001-4361-a703-15f184e2bba3@github.com>

On Sun, 22 Nov 2020 18:27:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
>> 
>> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
>> 
>> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
>> 
>> This problem can be reproduced by this code:
>> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
>> 		        sslSocket.getSSLParameters();
>> 		        sslSocket.close();
>> 
>> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
>> 
>> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
>> 
>> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
>> 
>> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small test improvement

test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 57:

> 55:         if ((fds_end - fds_start) > (NUM_TEST_SOCK / 10)) {
> 56:             throw new RuntimeException("Too many open file descriptors. Looks leaky.");
> 57:         }

This test case may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.

test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37:

> 35:  *          will not leave leaking socket file descriptors
> 36:  * @library /test/lib
> 37:  * @run main/othervm SSLSocketLeak

See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted.
@run main/manual SSLSocketLeak

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

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

From xuelei at openjdk.java.net  Wed Dec  2 18:09:00 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 18:09:00 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size
In-Reply-To: <MNvDSNEDwn3nIlgVjH0SzeQYg60pi_bFyHpAHLzlXro=.8d6396de-d557-4537-b412-3f8354d66199@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
 <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>
 <MNvDSNEDwn3nIlgVjH0SzeQYg60pi_bFyHpAHLzlXro=.8d6396de-d557-4537-b412-3f8354d66199@github.com>
Message-ID: <K6yzJzDWp_SZGmMBjUCpsxf0Qt20IE4ltx0Qd30Cye0=.676ba949-43d4-4e65-a6f0-1b8533723088@github.com>

On Wed, 2 Dec 2020 17:49:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11ECKeyFactory.java line 303:
>> 
>>> 301:                 } else {
>>> 302:                     point = decodePoint(attributes[0].getByteArray(), params.getCurve());
>>> 303:                 }
>> 
>> You could save a "!" operation in 299 if switch line 302 and line 300.
>
> I only used "!" for consistency with existing usage in P11Key.java:1080.    Is there a reason to avoid "!" other than maybe readability?

Save a operation could get a little bit performance.  Comparing to "if (!a)", "if (a)" is easier to read to me, and save me a cycle to compute the "!".  Anyway, not a big concern of mine, you can leave it as is if you prefer the "if (!a)" style.

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

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

From clanger at openjdk.java.net  Wed Dec  2 18:44:57 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 2 Dec 2020 18:44:57 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v3]
In-Reply-To: <AhFn4a4-m00SXjmy4ynUzFLj_ZZolzSyXWVVKLJE4nc=.1bf5edd6-0001-4361-a703-15f184e2bba3@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
 <AhFn4a4-m00SXjmy4ynUzFLj_ZZolzSyXWVVKLJE4nc=.1bf5edd6-0001-4361-a703-15f184e2bba3@github.com>
Message-ID: <xSMAOG_Vocm0_5QNaLQGXpiRbS76xHKJcqSPDkvFum4=.348aa548-d459-421e-b2a7-d9c9474f6064@github.com>

On Wed, 2 Dec 2020 18:01:04 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small test improvement
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37:
> 
>> 35:  *          will not leave leaking socket file descriptors
>> 36:  * @library /test/lib
>> 37:  * @run main/othervm SSLSocketLeak
> 
> See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted.
> @run main/manual SSLSocketLeak

Hm, I think it's fine as it is. Running it in othervm will make sure the test runs in its own vm (see http://openjdk.java.net/jtreg/command-help.html). So within the VM process there should not be any interference by other workload. And we check open files before testing and afterwards, and allow for some margin.

The test has been running in our test setup for several days now, so I think it should be ok. And if worst comes to worse, and we see test noise, we might change the test to manual later on.

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

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

From xuelei at openjdk.java.net  Wed Dec  2 18:54:01 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 18:54:01 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v3]
In-Reply-To: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
Message-ID: <PzUnpK4HEC7QfhRoMhCXWEn3NEgnaUyM7GlsawWxves=.c9d8477e-3210-4f64-b73d-2307ae5cd772@github.com>

On Sun, 22 Nov 2020 18:27:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
>> 
>> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
>> 
>> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
>> 
>> This problem can be reproduced by this code:
>> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
>> 		        sslSocket.getSSLParameters();
>> 		        sslSocket.close();
>> 
>> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
>> 
>> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
>> 
>> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
>> 
>> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small test improvement

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.java.net  Wed Dec  2 18:54:04 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 18:54:04 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v3]
In-Reply-To: <xSMAOG_Vocm0_5QNaLQGXpiRbS76xHKJcqSPDkvFum4=.348aa548-d459-421e-b2a7-d9c9474f6064@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>
 <AhFn4a4-m00SXjmy4ynUzFLj_ZZolzSyXWVVKLJE4nc=.1bf5edd6-0001-4361-a703-15f184e2bba3@github.com>
 <xSMAOG_Vocm0_5QNaLQGXpiRbS76xHKJcqSPDkvFum4=.348aa548-d459-421e-b2a7-d9c9474f6064@github.com>
Message-ID: <NatvSRZhw3skgT1LFidfwI2KcgAVpPaBXdC3AO8gqAU=.199fd8b3-4964-437e-b4b9-a58acb0774df@github.com>

On Wed, 2 Dec 2020 18:42:36 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 37:
>> 
>>> 35:  *          will not leave leaking socket file descriptors
>>> 36:  * @library /test/lib
>>> 37:  * @run main/othervm SSLSocketLeak
>> 
>> See bellow comment, I may suggest to have it as a manual test case if you agree the test case could be impacted.
>> @run main/manual SSLSocketLeak
>
> Hm, I think it's fine as it is. Running it in othervm will make sure the test runs in its own vm (see http://openjdk.java.net/jtreg/command-help.html). So within the VM process there should not be any interference by other workload. And we check open files before testing and afterwards, and allow for some margin.
> 
> The test has been running in our test setup for several days now, so I think it should be ok. And if worst comes to worse, and we see test noise, we might change the test to manual later on.

Sounds good to me.  Thanks!

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

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

From clanger at openjdk.java.net  Wed Dec  2 19:27:00 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 2 Dec 2020 19:27:00 GMT
Subject: Integrated: 8256818: SSLSocket that is never bound or connected leaks
 socket resources
In-Reply-To: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
Message-ID: <tzEJg1j7SeIsOMftmDR2rxFLpUQj_O11vKOugZ71kr0=.cfae9f4f-eef8-4245-948d-dc9864ab957b@github.com>

On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
> 
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
> 
> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
> 
> This problem can be reproduced by this code:
> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
> 		        sslSocket.getSSLParameters();
> 		        sslSocket.close();
> 
> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
> 
> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
> 
> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
> 
> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.

This pull request has now been integrated.

Changeset: 93b6ab56
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/93b6ab56
Stats:     129 lines in 5 files changed: 97 ins; 15 del; 17 mod

8256818: SSLSocket that is never bound or connected leaks socket resources

Reviewed-by: xuelei

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

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

From valeriep at openjdk.java.net  Wed Dec  2 20:49:08 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 2 Dec 2020 20:49:08 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v6]
In-Reply-To: <4ahM8RttKuOnFWEgKagrpajFm3Wi2uq_G6BTWDuAo4Y=.48fea738-627f-4b3e-9ce4-1b0cba8dea1c@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <4ahM8RttKuOnFWEgKagrpajFm3Wi2uq_G6BTWDuAo4Y=.48fea738-627f-4b3e-9ce4-1b0cba8dea1c@github.com>
Message-ID: <jYnZ3NB6bhG5bxDuGA1A5-K-EwQAjDON-PuGGMFx0y4=.190f00a0-7ffa-471b-971f-ea86a169d0ca@github.com>

On Wed, 2 Dec 2020 05:01:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments v4

Marked as reviewed by valeriep (Reviewer).

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

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

From valeriep at openjdk.java.net  Wed Dec  2 20:49:09 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 2 Dec 2020 20:49:09 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v6]
In-Reply-To: <Qjnm9R7qRTRLS0ofAQ6FedOk5nHJdzsBjNbWRaTRVBA=.c8be0ddf-a9a3-4b9a-99fc-6e4917d56a68@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <9IvsxvHGzvQoM756tUBFHLcMyZjvdbevzh7c-I3i6zU=.03c89dcb-a547-4a07-b0db-358fa9b3fe27@github.com>
 <ffzrbvhNAQR0xEOdWAKHRBHeWwjG1xWT8DA5Ti8xZIA=.e4ce288d-277f-49b9-ba9c-f660e312dff9@github.com>
 <MdIHGvNOnH5n120ZPSjcfXdb79GjfgxON4dqhxNy4x0=.0278db81-9124-497d-ad8d-bcca1f22142a@github.com>
 <hw5T-JCopKVN9OEQ0o90wdKrV4SZicqhEsCEhwPncME=.f0f9d178-6a3e-4e02-8ded-dfed98cc3a07@github.com>
 <Qjnm9R7qRTRLS0ofAQ6FedOk5nHJdzsBjNbWRaTRVBA=.c8be0ddf-a9a3-4b9a-99fc-6e4917d56a68@github.com>
Message-ID: <3jaAXlQ8Ew2Bjw-AuyOpvnshf9F4aHsicBQ5AQcv5EA=.f3cd7f14-820e-4f29-8c1e-16b65a374890@github.com>

On Wed, 2 Dec 2020 04:58:13 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> The biggest part of this change is the addition of overlap protection and the tests to verify it for GCM, as there were none in the open repo.  Additionally, GCMBufferTest had some significant changes to clean it up and handle offsets better.  All tests pass.  With RDP1 coming, I want to get this into the repo soon, so please limit comments to bugs. Any "nice to have" changes, they can be added onto follow-on changes I plan.
>
> Webrev updated with latest comments..  rev 5.

Ok, I have no more comments.

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 23:14:06 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 23:14:06 GMT
Subject: Integrated: 8253821: Improve ByteBuffer performance with GCM
In-Reply-To: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
Message-ID: <xaevZiYm57VPriWPMeC5QQDZ1c7STTDiKl7twKKIWSo=.815f86cb-f469-4d41-84a9-26ecf0615cc9@github.com>

On Tue, 29 Sep 2020 20:22:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> 8253821: Improve ByteBuffer performance with GCM

This pull request has now been integrated.

Changeset: cc1915b3
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc1915b3
Stats:     2187 lines in 15 files changed: 2027 ins; 50 del; 110 mod

8253821: Improve ByteBuffer performance with GCM

Reviewed-by: xuelei, valeriep

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

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

From ascarpino at openjdk.java.net  Wed Dec  2 23:34:55 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 2 Dec 2020 23:34:55 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size
In-Reply-To: <K6yzJzDWp_SZGmMBjUCpsxf0Qt20IE4ltx0Qd30Cye0=.676ba949-43d4-4e65-a6f0-1b8533723088@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
 <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>
 <MNvDSNEDwn3nIlgVjH0SzeQYg60pi_bFyHpAHLzlXro=.8d6396de-d557-4537-b412-3f8354d66199@github.com>
 <K6yzJzDWp_SZGmMBjUCpsxf0Qt20IE4ltx0Qd30Cye0=.676ba949-43d4-4e65-a6f0-1b8533723088@github.com>
Message-ID: <YMvyD5e5P96pP1TmjOjathOcfXFhuSc7KewOrAWmZWk=.0cdde823-b88a-4e96-9257-f3124a2eedee@github.com>

On Wed, 2 Dec 2020 18:06:33 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I only used "!" for consistency with existing usage in P11Key.java:1080.    Is there a reason to avoid "!" other than maybe readability?
>
> Save a operation could get a little bit performance.  Comparing to "if (!a)", "if (a)" is easier to read to me, and save me a cycle to compute the "!".  Anyway, not a big concern of mine, you can leave it as is if you prefer the "if (!a)" style.

Just to finish up the thought.  The assembly instructions are the same using if(!a) or if(a).  The difference would be how the code is setup during compile time and I believe that would be the same speed as well..

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

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

From jnimeh at openjdk.java.net  Thu Dec  3 06:14:58 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 3 Dec 2020 06:14:58 GMT
Subject: Integrated: JDK-8166596: TLS support for the EdDSA signature algorithm
In-Reply-To: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
References: <494dyYv2GdCxfYFY_sWHiggwJDfTmt5yYAXLil4peLI=.6c49d2f4-4036-4a24-a671-e50cef636fd4@github.com>
Message-ID: <Ua9LJ0Z6oRGUHJxbE3NWGBj1jcddlM7hrhzRHfCrMxE=.67171776-4c28-4268-99a6-1206a5aa5a7e@github.com>

On Fri, 13 Nov 2020 04:57:12 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> Hello all,
> This change brings in support for certificates with EdDSA keys (both Ed25519 and Ed448) allowing those signature algorithms to be used both on the certificates themselves and used during the handshaking process for messages like CertificateVerify, ServerKeyExchange and so forth.

This pull request has now been integrated.

Changeset: d80ae05f
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d80ae05f
Stats:     843 lines in 9 files changed: 783 ins; 18 del; 42 mod

8166596: TLS support for the EdDSA signature algorithm

Reviewed-by: xuelei

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

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

From raj.arora.sw.eng at gmail.com  Wed Dec  2 19:29:28 2020
From: raj.arora.sw.eng at gmail.com (Raj Arora)
Date: Wed, 2 Dec 2020 14:29:28 -0500
Subject: jar signing and verification
Message-ID: <CAK64GV1qByf1h83Zs33QAiy2RJXBJCeqU58q4YNZPvd+uy8VJA@mail.gmail.com>

Hi

In attempting to validate jar signing I am seeing warnings as such
displaying Invalid certificate chain

-----------------------
>jarsigner -verify -certs bcprov-jdk15on-1.66.jar

s     606774 Sat Jul 04 15:48:42 EDT 2020 META-INF/MANIFEST.MF

      >>> Signer
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code
Signing, O=Sun Microsystems Inc
      [certificate expired on 4/25/20 3:00 AM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun
Microsystems Inc, L=Palo Alto, ST=CA, C=US
      [certificate expired on 4/25/20 3:00 AM]
      [Invalid certificate chain: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target]

      >>> Signer
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code
Signing, O=Oracle Corporation
      [certificate is valid from 3/10/17 8:07 PM to 3/10/22 8:07 PM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing,
O=Oracle Corporation
      [certificate is valid from 7/6/16 7:48 PM to 12/30/30 7:00 PM]
      [Invalid certificate chain: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target]

-----------------------
jarsigner -keystore ...\jre\lib\security\cacerts -verify -verbose -certs
bcprov-jdk15on-1.66.jar >out.txt


s     606774 Sat Jul 04 15:48:42 EDT 2020 META-INF/MANIFEST.MF

      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code
Signing, O=Sun Microsystems Inc
      [certificate expired on 4/25/20 3:00 AM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun
Microsystems Inc, L=Palo Alto, ST=CA, C=US
      [certificate expired on 4/25/20 3:00 AM]
      [CertPath not validated: Path does not chain with any of the trust
anchors]

      [entry was signed on 7/4/20 1:48 AM]
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code
Signing, O=Oracle Corporation
      [certificate is valid from 3/10/17 8:07 PM to 3/10/22 8:07 PM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing,
O=Oracle Corporation
      [certificate is valid from 7/6/16 7:48 PM to 12/30/30 7:00 PM]
      [CertPath not validated: Path does not chain with any of the trust
anchors]

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



Why do we get warnings of  "Invalid certificate chain"?

(I do not believe it's related to the expired warning as I see newer jars
exhibiting the same outcome without an expired notice)

Is the jar incorrectly signed or is the required chain simply not found in
cacerts and if so why is it not there. I do see that at the end of the
listing it says "jar verified"

The samples in
https://docs.oracle.com/en/java/javase/15/docs/specs/man/jarsigner.html#errors-and-warnings
seem to show a fully validated chain.

thanks
Raj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201202/2b249768/attachment.htm>

From ecki at zusammenkunft.net  Thu Dec  3 11:50:47 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 3 Dec 2020 11:50:47 +0000
Subject: jar signing and verification
In-Reply-To: <CAK64GV1qByf1h83Zs33QAiy2RJXBJCeqU58q4YNZPvd+uy8VJA@mail.gmail.com>
References: <CAK64GV1qByf1h83Zs33QAiy2RJXBJCeqU58q4YNZPvd+uy8VJA@mail.gmail.com>
Message-ID: <AM6PR03MB4389E60ABF2A44FB69BCEBFFFFF20@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

It is a bit unfortunate but the JCE Codesigning Roots are not part of the cacerts file. They are hardcoded in the Oracle JDK and not present in OpenJDK as far as I understand it.

It is documented here, that those CAs are not available for general deployments:
https://www.oracle.com/java/technologies/javase/getcodesigningcertificate.html

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Raj Arora <raj.arora.sw.eng at gmail.com>
Gesendet: Wednesday, December 2, 2020 8:29:28 PM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: jar signing and verification

Hi

In attempting to validate jar signing I am seeing warnings as such displaying Invalid certificate chain

-----------------------
>jarsigner -verify -certs bcprov-jdk15on-1.66.jar

s     606774 Sat Jul 04 15:48:42 EDT 2020 META-INF/MANIFEST.MF

      >>> Signer
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code Signing, O=Sun Microsystems Inc
      [certificate expired on 4/25/20 3:00 AM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto, ST=CA, C=US
      [certificate expired on 4/25/20 3:00 AM]
      [Invalid certificate chain: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

      >>> Signer
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code Signing, O=Oracle Corporation
      [certificate is valid from 3/10/17 8:07 PM to 3/10/22 8:07 PM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Oracle Corporation
      [certificate is valid from 7/6/16 7:48 PM to 12/30/30 7:00 PM]
      [Invalid certificate chain: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

-----------------------
jarsigner -keystore ...\jre\lib\security\cacerts -verify -verbose -certs bcprov-jdk15on-1.66.jar >out.txt


s     606774 Sat Jul 04 15:48:42 EDT 2020 META-INF/MANIFEST.MF

      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code Signing, O=Sun Microsystems Inc
      [certificate expired on 4/25/20 3:00 AM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto, ST=CA, C=US
      [certificate expired on 4/25/20 3:00 AM]
      [CertPath not validated: Path does not chain with any of the trust anchors]

      [entry was signed on 7/4/20 1:48 AM]
      X.509, CN=Legion of the Bouncy Castle Inc., OU=Java Software Code Signing, O=Oracle Corporation
      [certificate is valid from 3/10/17 8:07 PM to 3/10/22 8:07 PM]
      X.509, CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Oracle Corporation
      [certificate is valid from 7/6/16 7:48 PM to 12/30/30 7:00 PM]
      [CertPath not validated: Path does not chain with any of the trust anchors]

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



Why do we get warnings of  "Invalid certificate chain"?

(I do not believe it's related to the expired warning as I see newer jars exhibiting the same outcome without an expired notice)

Is the jar incorrectly signed or is the required chain simply not found in cacerts and if so why is it not there. I do see that at the end of the listing it says "jar verified"

The samples in
https://docs.oracle.com/en/java/javase/15/docs/specs/man/jarsigner.html#errors-and-warnings
seem to show a fully validated chain.

thanks
Raj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201203/20110c77/attachment-0001.htm>

From ascarpino at openjdk.java.net  Thu Dec  3 16:14:03 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 3 Dec 2020 16:14:03 GMT
Subject: RFR: 8257642: CipherByteBufferOverwriteTest copyright issue
Message-ID: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>

It's missing a comma

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

Commit messages:
 - fix copyright

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

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

From xuelei at openjdk.java.net  Thu Dec  3 16:32:57 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 16:32:57 GMT
Subject: RFR: 8257642: CipherByteBufferOverwriteTest copyright issue
In-Reply-To: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
References: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
Message-ID: <WXhfTxh-q5DmTQOG4cnm3AxTvft3GK2JK0IXWBcBkC0=.e2707ff5-96de-4f27-96d7-4e9de44ab5c6@github.com>

On Thu, 3 Dec 2020 16:09:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> It's missing a comma

Marked as reviewed by xuelei (Reviewer).

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

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

From wetmore at openjdk.java.net  Thu Dec  3 16:32:57 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 3 Dec 2020 16:32:57 GMT
Subject: RFR: 8257642: CipherByteBufferOverwriteTest copyright issue
In-Reply-To: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
References: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
Message-ID: <ts_B0h69gzIUX5eJHaoDxgTsJhQCnj_2idAztwuhX4Y=.03c6e9fa-93ae-4690-96eb-2f6e606f3e68@github.com>

On Thu, 3 Dec 2020 16:09:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> It's missing a comma

Marked as reviewed by wetmore (Reviewer).

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

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

From ascarpino at openjdk.java.net  Thu Dec  3 16:32:58 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 3 Dec 2020 16:32:58 GMT
Subject: Integrated: 8257642: CipherByteBufferOverwriteTest copyright issue
In-Reply-To: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
References: <Hj-fweL7ieUqRO8TMqt_BYPS5XHDJh8_V5EQ1b2NmcM=.017c8e24-e0e6-47e4-9e2c-2028e112b36f@github.com>
Message-ID: <6-Rv2yxHbMXKC9q2ds9lFbQtR9YA7KAH_Psg7JlHXB8=.00d7fcd6-7436-45f6-9d7e-9e54b0c20fe5@github.com>

On Thu, 3 Dec 2020 16:09:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> It's missing a comma

This pull request has now been integrated.

Changeset: 70517c83
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70517c83
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8257642: CipherByteBufferOverwriteTest copyright issue

Reviewed-by: xuelei, wetmore

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

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

From ascarpino at openjdk.java.net  Thu Dec  3 16:36:09 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 3 Dec 2020 16:36:09 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size [v2]
In-Reply-To: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
Message-ID: <6y6u8XG-NvjSTYNUIcEDRfbodWvfGNx5ZhAitAexeg4=.019761e7-9c54-4557-b808-8e70f4283b5b@github.com>

> I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.

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

  copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1568/files
  - new: https://git.openjdk.java.net/jdk/pull/1568/files/2b939a85..60a27caa

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

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

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

From xuelei at openjdk.java.net  Thu Dec  3 16:43:55 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 16:43:55 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size [v2]
In-Reply-To: <6y6u8XG-NvjSTYNUIcEDRfbodWvfGNx5ZhAitAexeg4=.019761e7-9c54-4557-b808-8e70f4283b5b@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
 <6y6u8XG-NvjSTYNUIcEDRfbodWvfGNx5ZhAitAexeg4=.019761e7-9c54-4557-b808-8e70f4283b5b@github.com>
Message-ID: <H0pg6HRAYdgI6DOrIQ1aRQcFgjoTeDwCmIzHT1NPpKw=.d1831e0c-16f1-4abb-aaa8-5170525fb0e6@github.com>

On Thu, 3 Dec 2020 16:36:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright date

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.java.net  Thu Dec  3 16:43:56 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 16:43:56 GMT
Subject: RFR: 8026976: ECParameters, Point does not match field size [v2]
In-Reply-To: <YMvyD5e5P96pP1TmjOjathOcfXFhuSc7KewOrAWmZWk=.0cdde823-b88a-4e96-9257-f3124a2eedee@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
 <nNv8BSlv6N_jronhuP_KS26p9R7LdBqJgREmtQr4g0w=.f0814e24-af2a-4637-a735-1f3752be30f8@github.com>
 <MNvDSNEDwn3nIlgVjH0SzeQYg60pi_bFyHpAHLzlXro=.8d6396de-d557-4537-b412-3f8354d66199@github.com>
 <K6yzJzDWp_SZGmMBjUCpsxf0Qt20IE4ltx0Qd30Cye0=.676ba949-43d4-4e65-a6f0-1b8533723088@github.com>
 <YMvyD5e5P96pP1TmjOjathOcfXFhuSc7KewOrAWmZWk=.0cdde823-b88a-4e96-9257-f3124a2eedee@github.com>
Message-ID: <INMEBsxzJHTQ5gGmWpFwRDC1d0nX6Tl_qWGW5lTKnvY=.f0ec485f-f60d-4e1e-a805-2f696b061a8e@github.com>

On Wed, 2 Dec 2020 23:32:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Save a operation could get a little bit performance.  Comparing to "if (!a)", "if (a)" is easier to read to me, and save me a cycle to compute the "!".  Anyway, not a big concern of mine, you can leave it as is if you prefer the "if (!a)" style.
>
> Just to finish up the thought.  The assembly instructions are the same using if(!a) or if(a).  The difference would be how the code is setup during compile time and I believe that would be the same speed as well..

Thank you for the check.  It looks good to me and I have no more comment.

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

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

From ascarpino at openjdk.java.net  Thu Dec  3 18:08:56 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 3 Dec 2020 18:08:56 GMT
Subject: Integrated: 8026976: ECParameters, Point does not match field size
In-Reply-To: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
References: <_B8pIorOu3Yx_DLWBI5rZ7Tno4_RHANvVphTx8ForAg=.df23f413-1ab0-45cd-9938-ed2220ea16b2@github.com>
Message-ID: <c0m_SMpkVYo8KE2y4uDiOKvKwAH5HTyXeFQzXu-eRHs=.cbd7571a-328d-4523-a0c6-0c16c64d28be@github.com>

On Wed, 2 Dec 2020 17:08:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I need a code review for this small code change.  The code did not run the data through the DER decoding class before setting it to the point when the SunPKCS11 configuration had UseEcX963Encoding set to false.

This pull request has now been integrated.

Changeset: 55f5542c
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/55f5542c
Stats:     9 lines in 2 files changed: 6 ins; 1 del; 2 mod

8026976: ECParameters, Point does not match field size

Reviewed-by: xuelei

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

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

From xuelei at openjdk.java.net  Thu Dec  3 20:50:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 20:50:03 GMT
Subject: RFR: 8257724: Incorrect package of the linked class in
 BaseSSLSocketImpl
Message-ID: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>

In sun.security.ssl.BaseSSLSocketImpl.java, the package of SocketChannel in the getChannel() spec is java.nio, which is incorrect. It should be java.nio.channels.

Doc cleanup only, no new regression test.

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

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

Commit messages:
 - 8257724: Incorrect package of the linked class in BaseSSLSocketImpl

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

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

From xuelei at openjdk.java.net  Thu Dec  3 21:03:08 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 21:03:08 GMT
Subject: RFR: 8257725: No throws of SSLHandshakeException
Message-ID: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>

In the StatusResponseManager.get() method spec, the SSLHandshakeException is declared as throws exception. However, no such checked-exception would be thrown in the method implementation. 

/** 
... 
 * @throws SSLHandshakeException if an unsupported 
 * {@code CertStatusRequest} is provided. 
 */ 
Map<X509Certificate, byte[]> get(CertStatusRequestType type, 
            CertStatusRequest request, X509Certificate[] chain, long delay, 
            TimeUnit unit) {

As the exception is a checked-exception, and is not declared in the method, it is safe to remove the throws spec.

Cleanup only, no new regression test.

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

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

Commit messages:
 - 8257725: No throws of SSLHandshakeException
 - 8257724: Incorrect package of the linked class in BaseSSLSocketImpl

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

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

From xuelei at openjdk.java.net  Thu Dec  3 21:06:59 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 21:06:59 GMT
Subject: RFR: 8257725: No throws of SSLHandshakeException
In-Reply-To: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
References: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
Message-ID: <EL6ziGJ9BzSIQFiTPvFPGDDXwFt3RLH38_hzdCYmfQ8=.bc8ff589-d860-4e4e-abe8-3a5201aecf6d@github.com>

On Thu, 3 Dec 2020 20:58:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the StatusResponseManager.get() method spec, the SSLHandshakeException is declared as throws exception. However, no such checked-exception would be thrown in the method implementation. 
> 
> /** 
> ... 
>  * @throws SSLHandshakeException if an unsupported 
>  * {@code CertStatusRequest} is provided. 
>  */ 
> Map<X509Certificate, byte[]> get(CertStatusRequestType type, 
>             CertStatusRequest request, X509Certificate[] chain, long delay, 
>             TimeUnit unit) {
> 
> As the exception is a checked-exception, and is not declared in the method, it is safe to remove the throws spec.
> 
> Cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257725

src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java line 1:

> 1: /*

This update should be in another branch.  I'm not very sure why it comes into this branch.  I will make sure to get rid of it before integration.

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

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

From jnimeh at openjdk.java.net  Thu Dec  3 21:26:57 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 3 Dec 2020 21:26:57 GMT
Subject: RFR: 8257725: No throws of SSLHandshakeException
In-Reply-To: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
References: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
Message-ID: <x0pmy94hmvZEnZ2vBX0NVDMxwmegWxMJ4SIpFpiuhIE=.50385522-33db-4055-ba2c-f199e2f40561@github.com>

On Thu, 3 Dec 2020 20:58:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the StatusResponseManager.get() method spec, the SSLHandshakeException is declared as throws exception. However, no such checked-exception would be thrown in the method implementation. 
> 
> /** 
> ... 
>  * @throws SSLHandshakeException if an unsupported 
>  * {@code CertStatusRequest} is provided. 
>  */ 
> Map<X509Certificate, byte[]> get(CertStatusRequestType type, 
>             CertStatusRequest request, X509Certificate[] chain, long delay, 
>             TimeUnit unit) {
> 
> As the exception is a checked-exception, and is not declared in the method, it is safe to remove the throws spec.
> 
> Cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257725

Looks OK to me.

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

Marked as reviewed by jnimeh (Reviewer).

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

From xuelei at openjdk.java.net  Thu Dec  3 23:30:54 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Dec 2020 23:30:54 GMT
Subject: RFR: 8242332: Add SHA3 support to SunPKCS11 provider
In-Reply-To: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
References: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
Message-ID: <Xd-y_608c04Acm7wDvulJp3IlAqYDRu8BjuiW9Es-6I=.7e5def34-a79e-4cb9-92d0-385337a8e3f2@github.com>

On Tue, 1 Dec 2020 21:51:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this RFE? SunPKCS11 provider is updated with SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA Signature, and Hmac KeyGenerator.
> 
> As SHA-3 can be used as drop-in replacement for SHA-2 which are already supported by SunPKCS11 provider, the changes for MessageDigest, Mac, and Signature are straightforward. P11KeyGenerator class is updated to support general Hmac key generation including SHA-3 and more. 
> 
> While testing against NSS 3.57, there are some unexpected NSS errors with CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those mechanisms in the NSS config file for regression tests. For ECDSA signatures, SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting ourselves.
> 
> Thanks,
> Valerie

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From valeriep at openjdk.java.net  Fri Dec  4 01:26:06 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 4 Dec 2020 01:26:06 GMT
Subject: RFR: 8257734: Extraneous output in HmacSHA3_512 constructor
Message-ID: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>

Somehow there is a debugging statement accidentally introduced into the HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
Please help review this one-line fix which removed the undesirable System.out.println(...) call. Did a grep on other classes under the same package and rest are ok.

No regression test, thus added noreg-trivial label to the bug record.

Thanks,
Valerie

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

Commit messages:
 - 8257734: Extraneous output in HmacSHA3_512 constructor

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

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

From ascarpino at openjdk.java.net  Fri Dec  4 02:00:55 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 4 Dec 2020 02:00:55 GMT
Subject: RFR: 8257734: Extraneous output in HmacSHA3_512 constructor
In-Reply-To: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>
References: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>
Message-ID: <BAk17wPm4DbZP4YtIbaYl7ZHCcZ5kldkj5-RIYMJe9Q=.69132dff-8370-41e5-aad6-873ad6162e32@github.com>

On Fri, 4 Dec 2020 01:21:43 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Somehow there is a debugging statement accidentally introduced into the HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
> Please help review this one-line fix which removed the undesirable System.out.println(...) call. Did a grep on other classes under the same package and rest are ok.
> 
> No regression test, thus added noreg-trivial label to the bug record.
> 
> Thanks,
> Valerie

Marked as reviewed by ascarpino (Reviewer).

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

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

From valeriep at openjdk.java.net  Fri Dec  4 02:11:02 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 4 Dec 2020 02:11:02 GMT
Subject: RFR: 8257734: Extraneous output in HmacSHA3_512 constructor
In-Reply-To: <BAk17wPm4DbZP4YtIbaYl7ZHCcZ5kldkj5-RIYMJe9Q=.69132dff-8370-41e5-aad6-873ad6162e32@github.com>
References: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>
 <BAk17wPm4DbZP4YtIbaYl7ZHCcZ5kldkj5-RIYMJe9Q=.69132dff-8370-41e5-aad6-873ad6162e32@github.com>
Message-ID: <pXKchRTiO0kx_1QwyHPe1XYZJLYbS3apuuRv-I91bSg=.527ac0c4-18e6-44da-8fce-113a7f2296dc@github.com>

On Fri, 4 Dec 2020 01:57:59 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Somehow there is a debugging statement accidentally introduced into the HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
>> Please help review this one-line fix which removed the undesirable System.out.println(...) call. Did a grep on other classes under the same package and rest are ok.
>> 
>> No regression test, thus added noreg-trivial label to the bug record.
>> 
>> Thanks,
>> Valerie
>
> Marked as reviewed by ascarpino (Reviewer).

> 
> 
> Looks good

Thanks for the quick review~

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

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

From valeriep at openjdk.java.net  Fri Dec  4 02:15:54 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 4 Dec 2020 02:15:54 GMT
Subject: RFR: 8242332: Add SHA3 support to SunPKCS11 provider
In-Reply-To: <Xd-y_608c04Acm7wDvulJp3IlAqYDRu8BjuiW9Es-6I=.7e5def34-a79e-4cb9-92d0-385337a8e3f2@github.com>
References: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
 <Xd-y_608c04Acm7wDvulJp3IlAqYDRu8BjuiW9Es-6I=.7e5def34-a79e-4cb9-92d0-385337a8e3f2@github.com>
Message-ID: <jd8dBlVdxzypVFnAIsV7BlUbAvp3rfWW1VfCk7Ii_9k=.64e5acb2-52d0-4328-baee-1470437d6909@github.com>

On Thu, 3 Dec 2020 23:28:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> 
> 
> Looks good to me.

Thanks for the quick review~

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

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

From valeriep at openjdk.java.net  Fri Dec  4 03:54:55 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 4 Dec 2020 03:54:55 GMT
Subject: Integrated: 8257734: Extraneous output in HmacSHA3_512 constructor
In-Reply-To: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>
References: <1qm2bETh2Ma8Jyqe_UviNM-AYvN7JBVm9AaA60CGMFs=.6c5ad058-98c6-48b5-8e33-7a7cc1a0e8d9@github.com>
Message-ID: <RbFpRXxn1A-7TXRQfvuJpK9_vl_l0miUdextW9o6cNw=.109a2f03-e864-49f0-9a76-7153d08824ba@github.com>

On Fri, 4 Dec 2020 01:21:43 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Somehow there is a debugging statement accidentally introduced into the HmacSHA3_512 constructor before the JDK-8172680 changes are integrated.
> Please help review this one-line fix which removed the undesirable System.out.println(...) call. Did a grep on other classes under the same package and rest are ok.
> 
> No regression test, thus added noreg-trivial label to the bug record.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 49f9e577
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49f9e577
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8257734: Extraneous output in HmacSHA3_512 constructor

Reviewed-by: ascarpino

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

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

From ihse at openjdk.java.net  Fri Dec  4 10:28:30 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:28:30 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective module
Message-ID: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 

These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 

This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

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

Commit messages:
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

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

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

From ihse at openjdk.java.net  Fri Dec  4 10:32:11 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:32:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

To facilitate review, here is a list on how the different directories under make/data has moved.

**To java.base:**
* blacklistedcertsconverter
* cacerts
* characterdata
* charsetmapping
* cldr
* currency
* lsrdata
* publicsuffixlist
* tzdata
* unicodedata

**To java.desktop:**
* dtdbuilder
* fontconfig
* macosxicons
* x11wrappergen

**To jdk.compiler:**
* symbols

**To jdk.jdi:**
* jdwp

**Remaining in make:**
* bundle
* docs-resources
* macosxsigning
* mainmanifest

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

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

From alanb at openjdk.java.net  Fri Dec  4 11:17:12 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 11:17:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
Message-ID: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>

On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> To facilitate review, here is a list on how the different directories under make/data has moved.
> 
> **To java.base:**
> * blacklistedcertsconverter
> * cacerts
> * characterdata
> * charsetmapping
> * cldr
> * currency
> * lsrdata
> * publicsuffixlist
> * tzdata
> * unicodedata
> 
> **To java.desktop:**
> * dtdbuilder
> * fontconfig
> * macosxicons
> * x11wrappergen
> 
> **To jdk.compiler:**
> * symbols
> 
> **To jdk.jdi:**
> * jdwp
> 
> **Remaining in make:**
> * bundle
> * docs-resources
> * macosxsigning
> * mainmanifest

Are you proposing any text or guidelines to be added to JEP 201 as part of this?

I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Fri Dec  4 11:25:19 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Fri, 4 Dec 2020 11:25:19 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
 <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
Message-ID: <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>

On Wed, 2 Dec 2020 16:35:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Align -> and remove trailing whitespace
>
> Marked as reviewed by dfuchs (Reviewer).

@pconcannon, If everything is in order, can you please approve the changes on Github. I'll then issue the integrate command. Thanks.

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

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

From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
Message-ID: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>

On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To facilitate review, here is a list on how the different directories under make/data has moved.
>> 
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsrdata
>> * publicsuffixlist
>> * tzdata
>> * unicodedata
>> 
>> **To java.desktop:**
>> * dtdbuilder
>> * fontconfig
>> * macosxicons
>> * x11wrappergen
>> 
>> **To jdk.compiler:**
>> * symbols
>> 
>> **To jdk.jdi:**
>> * jdwp
>> 
>> **Remaining in make:**
>> * bundle
>> * docs-resources
>> * macosxsigning
>> * mainmanifest
>
> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
> 
> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

@AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.

I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

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

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

From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
Message-ID: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>

On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
>> 
>> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.
>
> @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.
> 
> I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.

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

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

From alanb at openjdk.java.net  Fri Dec  4 12:33:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 12:33:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
Message-ID: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>

On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> And I can certainly move jdwp.spec to java.base instead. 

If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

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

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

From pconcannon at openjdk.java.net  Fri Dec  4 14:03:13 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 4 Dec 2020 14:03:13 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
 <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
 <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>
Message-ID: <prnolCuQ860auLlfTAjFdKrgCQLIt-bCOp8KnToHMp4=.a5cadb0d-3b23-4017-a98c-a7f97631f8b5@github.com>

On Fri, 4 Dec 2020 11:22:34 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> @pconcannon, If everything is in order, can you please approve the changes on Github. I'll then issue the integrate command. Thanks.

Hi @amCap1712, you will have to /integrate first, and then afterwards I will sponsor

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

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

From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
Message-ID: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>

On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.
>
>> And I can certainly move jdwp.spec to java.base instead. 
> 
> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

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

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

From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
Message-ID: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>

On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> And I can certainly move jdwp.spec to java.base instead. 
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.
>
> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Fri Dec  4 15:20:15 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Fri, 4 Dec 2020 15:20:15 GMT
Subject: Integrated: JDK-8257401: Use switch expressions in
 jdk.internal.net.http and java.net.http
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <bGnOZfCLLjEZDzWeaXKn3lPz54SzLLPPBj5q6W3RgYA=.4e84fd83-8d7c-41a8-94b3-eccd28e01ebb@github.com>

On Sat, 21 Nov 2020 11:45:42 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

This pull request has now been integrated.

Changeset: ac549008
Author:    Kartik Ohri <kartikohri13 at gmail.com>
URL:       https://git.openjdk.java.net/jdk/commit/ac549008
Stats:     271 lines in 17 files changed: 2 ins; 124 del; 145 mod

8257401: Use switch expressions in jdk.internal.net.http and java.net.http

Reviewed-by: chegar, dfuchs, pconcannon

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

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

From ihse at openjdk.java.net  Fri Dec  4 15:20:14 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 15:20:14 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
Message-ID: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>

On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.
>
> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

@erikj79 Good point, that makes much more sense.

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

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

From valeriep at openjdk.java.net  Fri Dec  4 18:12:15 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 4 Dec 2020 18:12:15 GMT
Subject: RFR: 8257724: Incorrect package of the linked class in
 BaseSSLSocketImpl
In-Reply-To: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
References: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
Message-ID: <l2jDWx98XlTRMjNdGMD0eyn80jHHwXSaY2DqYZCS2A0=.9d71e713-4bcc-4ceb-8518-62032b5e0b03@github.com>

On Thu, 3 Dec 2020 20:44:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In sun.security.ssl.BaseSSLSocketImpl.java, the package of SocketChannel in the getChannel() spec is java.nio, which is incorrect. It should be java.nio.channels.
> 
> Doc cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257724

Marked as reviewed by valeriep (Reviewer).

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

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

From wetmore at openjdk.java.net  Fri Dec  4 18:12:16 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Dec 2020 18:12:16 GMT
Subject: RFR: 8257724: Incorrect package of the linked class in
 BaseSSLSocketImpl
In-Reply-To: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
References: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
Message-ID: <MMRrI-BaQDpajEaNvTxcn7i-jBjqmeIAHhqquuWF1Tg=.77fdb626-566b-4d2b-aa9b-97bb36eba867@github.com>

On Thu, 3 Dec 2020 20:44:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In sun.security.ssl.BaseSSLSocketImpl.java, the package of SocketChannel in the getChannel() spec is java.nio, which is incorrect. It should be java.nio.channels.
> 
> Doc cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257724

Marked as reviewed by wetmore (Reviewer).

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

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

From xuelei at openjdk.java.net  Fri Dec  4 18:23:17 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Dec 2020 18:23:17 GMT
Subject: Integrated: 8257724: Incorrect package of the linked class in
 BaseSSLSocketImpl
In-Reply-To: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
References: <fIHgiH5b6DUCvmhSlVK5ol4KEfZ3VxD5mCAJshv-_cA=.8a34a204-e1e4-4c78-927c-01ae9d675b01@github.com>
Message-ID: <OfYZEwsS_sDA3jGD_cL9k0CRFykpR8x_EvEKslFwAuM=.e851cbd2-4f08-4caf-a4f1-465c485da1dc@github.com>

On Thu, 3 Dec 2020 20:44:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In sun.security.ssl.BaseSSLSocketImpl.java, the package of SocketChannel in the getChannel() spec is java.nio, which is incorrect. It should be java.nio.channels.
> 
> Doc cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257724

This pull request has now been integrated.

Changeset: fcc84795
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fcc84795
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8257724: Incorrect package of the linked class in BaseSSLSocketImpl

Reviewed-by: valeriep, wetmore

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

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

From xuelei at openjdk.java.net  Fri Dec  4 18:33:26 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Dec 2020 18:33:26 GMT
Subject: RFR: 8257725: No throws of SSLHandshakeException [v2]
In-Reply-To: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
References: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
Message-ID: <X-DGVl5bYCWR6usvriwTvi7rGxftBWhHh8J3Zxmfmyc=.2b06da19-3125-4c61-bc4f-9d368025cf92@github.com>

> In the StatusResponseManager.get() method spec, the SSLHandshakeException is declared as throws exception. However, no such checked-exception would be thrown in the method implementation. 
> 
> /** 
> ... 
>  * @throws SSLHandshakeException if an unsupported 
>  * {@code CertStatusRequest} is provided. 
>  */ 
> Map<X509Certificate, byte[]> get(CertStatusRequestType type, 
>             CertStatusRequest request, X509Certificate[] chain, long delay, 
>             TimeUnit unit) {
> 
> As the exception is a checked-exception, and is not declared in the method, it is safe to remove the throws spec.
> 
> Cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257725

Xue-Lei Andrew Fan 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
 - 8257725: No throws of SSLHandshakeException
 - 8257724: Incorrect package of the linked class in BaseSSLSocketImpl

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1607/files
  - new: https://git.openjdk.java.net/jdk/pull/1607/files/13d84784..b5fc532f

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

  Stats: 2303 lines in 75 files changed: 1713 ins; 207 del; 383 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1607/head:pull/1607

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

From xuelei at openjdk.java.net  Fri Dec  4 18:33:27 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Dec 2020 18:33:27 GMT
Subject: Integrated: 8257725: No throws of SSLHandshakeException
In-Reply-To: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
References: <bYeiHCp2oN4_nRN6M_brSjz2SAzPykFU3X6_IDqtGNs=.f454df7a-1e01-4789-821c-c75b751257a4@github.com>
Message-ID: <aQwOwaJ_mt9jMO9AnSZWcl1Cq5IHME6zFLCxs6smGJQ=.be4d5045-40d7-4dfa-b5a1-7e3ee67adcae@github.com>

On Thu, 3 Dec 2020 20:58:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the StatusResponseManager.get() method spec, the SSLHandshakeException is declared as throws exception. However, no such checked-exception would be thrown in the method implementation. 
> 
> /** 
> ... 
>  * @throws SSLHandshakeException if an unsupported 
>  * {@code CertStatusRequest} is provided. 
>  */ 
> Map<X509Certificate, byte[]> get(CertStatusRequestType type, 
>             CertStatusRequest request, X509Certificate[] chain, long delay, 
>             TimeUnit unit) {
> 
> As the exception is a checked-exception, and is not declared in the method, it is safe to remove the throws spec.
> 
> Cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257725

This pull request has now been integrated.

Changeset: d76039d3
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d76039d3
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8257725: No throws of SSLHandshakeException

Reviewed-by: jnimeh

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

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

From xuelei at openjdk.java.net  Fri Dec  4 23:02:20 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Dec 2020 23:02:20 GMT
Subject: RFR: 8257788: Class fields could be local in the SunJSSE provider
Message-ID: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>

In the SunJSSE provider implementation, there are a few class fields are not used other than the constructors. Those fields could be removed and replaced with local variables.

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

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

Commit messages:
 - 8257788: Class fields could be local in the SunJSSE provider

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

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

From hchao at openjdk.java.net  Sat Dec  5 00:07:14 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Sat, 5 Dec 2020 00:07:14 GMT
Subject: RFR: 8257788: Class fields could be local in the SunJSSE provider
In-Reply-To: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
References: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
Message-ID: <CO9QmbCaZ4g9zvUQjogQmehIOli8eGtppZaHxy-Z6HY=.f1653b0a-8068-48af-9f19-9b8860c9b77a@github.com>

On Fri, 4 Dec 2020 22:58:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the SunJSSE provider implementation, there are a few class fields are not used other than the constructors. Those fields could be removed and replaced with local variables.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257788

Looks good to me.

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

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

From valeriep at openjdk.java.net  Sat Dec  5 00:47:34 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 5 Dec 2020 00:47:34 GMT
Subject: RFR: 8242332: Add SHA3 support to SunPKCS11 provider [v2]
In-Reply-To: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
References: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
Message-ID: <lBAVZA25Q33GhhNBs3bsbOjAEwwvv0Umz1mkwSAEDfc=.3ef1a1c4-4602-4b62-ba60-83cbe60914c9@github.com>

> Could someone please help review this RFE? SunPKCS11 provider is updated with SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA Signature, and Hmac KeyGenerator.
> 
> As SHA-3 can be used as drop-in replacement for SHA-2 which are already supported by SunPKCS11 provider, the changes for MessageDigest, Mac, and Signature are straightforward. P11KeyGenerator class is updated to support general Hmac key generation including SHA-3 and more. 
> 
> While testing against NSS 3.57, there are some unexpected NSS errors with CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those mechanisms in the NSS config file for regression tests. For ECDSA signatures, SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting ourselves.
> 
> Thanks,
> Valerie

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

  Removed commented out code and minor cleanups on 2 RSASSA-PSS-related tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1546/files
  - new: https://git.openjdk.java.net/jdk/pull/1546/files/7b0d7882..4f7488b6

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

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

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

From jnimeh at openjdk.java.net  Sat Dec  5 23:28:19 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Sat, 5 Dec 2020 23:28:19 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305
Message-ID: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>

This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

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

Commit messages:
 - 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305

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

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

From valeriep at openjdk.java.net  Sat Dec  5 23:50:13 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 5 Dec 2020 23:50:13 GMT
Subject: Integrated: 8242332: Add SHA3 support to SunPKCS11 provider
In-Reply-To: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
References: <qfi_hOiXC4sZ35EXJ5PnGAeslD3NfIyzZS3a8xq4LOc=.09db0fae-1bc4-49c9-937d-76a90624f1b1@github.com>
Message-ID: <jfAbFevJxk803wLQEzJStm6nSV1yIWSrI6xBOUK4pC0=.e0b08666-8520-4d51-b9cf-55f69bf69e32@github.com>

On Tue, 1 Dec 2020 21:51:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this RFE? SunPKCS11 provider is updated with SHA-3 support, including MessageDigest, Hmac Mac, DSA/RSA/RSASSA-PSS/ECDSA Signature, and Hmac KeyGenerator.
> 
> As SHA-3 can be used as drop-in replacement for SHA-2 which are already supported by SunPKCS11 provider, the changes for MessageDigest, Mac, and Signature are straightforward. P11KeyGenerator class is updated to support general Hmac key generation including SHA-3 and more. 
> 
> While testing against NSS 3.57, there are some unexpected NSS errors with CKM_ECDSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512] and CKM_DSA_SHA[224/256/384/512/3_224/3_256/3_384/3_512], so I disabled those mechanisms in the NSS config file for regression tests. For ECDSA signatures, SunPKCS11 provider will fallback to CKM_ECDSA and do the digesting ourselves.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 78be334c
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/78be334c
Stats:     1502 lines in 25 files changed: 883 ins; 465 del; 154 mod

8242332: Add SHA3 support to SunPKCS11 provider

Reviewed-by: xuelei

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

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

From shade at openjdk.java.net  Mon Dec  7 07:34:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Dec 2020 07:34:14 GMT
Subject: RFR: 8257788: Class fields could be local in the SunJSSE provider
In-Reply-To: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
References: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
Message-ID: <XP8a7rDbn0DKGg1qUnANjIpbqM4lWRLOVdryJ4A2Xeg=.ff6f2693-6087-4ad7-bedb-6d81955afa6a@github.com>

On Fri, 4 Dec 2020 22:58:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the SunJSSE provider implementation, there are a few class fields are not used other than the constructors. Those fields could be removed and replaced with local variables.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257788

Looks fine to me.

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

Marked as reviewed by shade (Reviewer).

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

From ccleary at openjdk.java.net  Mon Dec  7 10:44:26 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 10:44:26 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the condition in
 KeepAliveStreamCleaner
Message-ID: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>

The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).

...
long timeout = TIMEOUT;
    while ((kace = poll()) == null) {
            waiter.await(timeout, TimeUnit.MILLISECONDS); 
...
While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

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

Commit messages:
 - 8255583: Updated copyright notes
 - 8255583: Investigate creating a test to trigger the condition in KeepAliveStreamCleaner

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

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

From dfuchs at openjdk.java.net  Mon Dec  7 10:58:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 10:58:12 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
Message-ID: <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>

On Mon, 7 Dec 2020 09:52:47 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
> 
> ...
> long timeout = TIMEOUT;
>     while ((kace = poll()) == null) {
>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
> ...
> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @modules java.base/sun.net.www.http

Hi Conor,

Can you add:

@bug 8255124

here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.

best regards,

-- daniel

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:12:18 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:12:18 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
Message-ID: <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>

On Mon, 7 Dec 2020 10:55:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @modules java.base/sun.net.www.http
> 
> Hi Conor,
> 
> Can you add:
> 
> @bug 8255124
> 
> here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.
> 
> best regards,
> 
> -- daniel

Will do Daniel, thanks for pointing that out!

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:12:20 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:12:20 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
 <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>
Message-ID: <Ez4D6jTKawCNmSNcATNWvDG7g3RMwMmUppUhL7egyVU=.472558d8-137b-4f8c-b4c6-439ee4005bac@github.com>

On Mon, 7 Dec 2020 11:08:37 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @modules java.base/sun.net.www.http
>> 
>> Hi Conor,
>> 
>> Can you add:
>> 
>> @bug 8255124
>> 
>> here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.
>> 
>> best regards,
>> 
>> -- daniel
>
> Will do Daniel, thanks for pointing that out!

Should probably add a short summary as well

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

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

From ihse at openjdk.java.net  Mon Dec  7 14:27:45 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:27:45 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move to share/data, and move jdwp.spec to java.se

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/8e775e40..f0047704

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

  Stats: 56 lines in 1565 files changed: 1 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

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

From ihse at openjdk.java.net  Mon Dec  7 14:28:05 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:05 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
Message-ID: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>

On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?
>
> @erikj79 Good point, that makes much more sense.

I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

Rendered as markdown, it would look somewhat like this:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

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

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

From ihse at openjdk.java.net  Mon Dec  7 14:28:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
 <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
Message-ID: <kxhbRD192TEhTH1lD3HBgly5Z1cKWEwKwyQLH88LCQc=.527bba0f-bf8c-4a11-a95d-228d628f5d91@github.com>

On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.
> 
> Rendered as markdown, it would look somewhat like this:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.

I hope I understood the purpose of the `lib` directory correctly. Our only instance of this is for `java.base/*/lib/security/default.policy`.

I also noted that jdk.hotspot.agent violates this scheme by having a top-level `test` and `doc` directories, apart from `share` and the OS directories. The purposes of these two directories are not clear to me. The tests in `test` are definitely never executed. I don't know if this is an omission, or if they should be removed. The documentation in `doc` is not exported to the end product, nor is it references in any developer documentation. That too should either be removed, or moved to a more suitable home.

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

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

From mullan at openjdk.java.net  Mon Dec  7 15:45:17 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Dec 2020 15:45:17 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305
In-Reply-To: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
Message-ID: <m9QFG43Ds5r9rSOMTyNwo3G-0PaPq0j6x-CXFJhoHHo=.ac851431-02b8-40c7-8485-70fbc33696bd@github.com>

On Sat, 5 Dec 2020 23:23:47 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:

> 230:             // this call should cause a random nonce to be generated.
> 231:             if (!initialized || nonce == null) {
> 232:                 nonce = createRandomNonce(null);

Should nonce be a local variable instead? I think you don't want the nonce field to be set unless the caller passes back in the returned params in an init call.

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

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

From xuelei at openjdk.java.net  Mon Dec  7 16:38:15 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Dec 2020 16:38:15 GMT
Subject: Integrated: 8257788: Class fields could be local in the SunJSSE
 provider
In-Reply-To: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
References: <xro1TS2rYHPthWSdlXEETD96A39MBMp80IP9DDik1sI=.0bddd713-695f-479d-89f5-465ca55ab3a8@github.com>
Message-ID: <Oy94qptcSyZX8sgKB22gyKidydcDjMDCErUG2GZw01Q=.0d32b886-5c84-494b-9f2a-26e1226920d0@github.com>

On Fri, 4 Dec 2020 22:58:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the SunJSSE provider implementation, there are a few class fields are not used other than the constructors. Those fields could be removed and replaced with local variables.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8257788

This pull request has now been integrated.

Changeset: dcf63f85
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dcf63f85
Stats:     15 lines in 4 files changed: 0 ins; 11 del; 4 mod

8257788: Class fields could be local in the SunJSSE provider

Reviewed-by: shade

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 17:04:13 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 17:04:13 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305
In-Reply-To: <m9QFG43Ds5r9rSOMTyNwo3G-0PaPq0j6x-CXFJhoHHo=.ac851431-02b8-40c7-8485-70fbc33696bd@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <m9QFG43Ds5r9rSOMTyNwo3G-0PaPq0j6x-CXFJhoHHo=.ac851431-02b8-40c7-8485-70fbc33696bd@github.com>
Message-ID: <W1SkAtsdKxcQi1a7E3pGIKikdYJLghPoQXQ2MUlvjxg=.29f5a07f-1ce5-41b1-bfcc-ce4b9fd61c68@github.com>

On Mon, 7 Dec 2020 15:42:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:
> 
>> 230:             // this call should cause a random nonce to be generated.
>> 231:             if (!initialized || nonce == null) {
>> 232:                 nonce = createRandomNonce(null);
> 
> Should nonce be a local variable instead? I think you don't want the nonce field to be set unless the caller passes back in the returned params in an init call.

Yes, it should be a local variable.  I'll fix this.

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 17:50:25 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 17:50:25 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
Message-ID: <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>

> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

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

  pre-init getParameters nonce data is now a local variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1644/files
  - new: https://git.openjdk.java.net/jdk/pull/1644/files/56fd18c7..b9a24482

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

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

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

From jjg at openjdk.java.net  Mon Dec  7 19:35:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:35:17 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

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

Marked as reviewed by jjg (Reviewer).

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

From mullan at openjdk.java.net  Mon Dec  7 19:40:16 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Dec 2020 19:40:16 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
Message-ID: <DxZrBT9VtvgogEIR2CXa9dHKKhvJnFqhu_KwHB4cGnw=.540790f0-e452-488d-86e6-ab980c9975e3@github.com>

On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pre-init getParameters nonce data is now a local variable

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:

> 230:             // this call should cause a random nonce to be generated, but
> 231:             // not attached to the object.
> 232:             byte[] nonceData = initialized ? nonce : createRandomNonce(null);

A minor unrelated comment is that createRandomNonce() could be made static.

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

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

From mullan at openjdk.java.net  Mon Dec  7 19:40:17 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Dec 2020 19:40:17 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <DxZrBT9VtvgogEIR2CXa9dHKKhvJnFqhu_KwHB4cGnw=.540790f0-e452-488d-86e6-ab980c9975e3@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <DxZrBT9VtvgogEIR2CXa9dHKKhvJnFqhu_KwHB4cGnw=.540790f0-e452-488d-86e6-ab980c9975e3@github.com>
Message-ID: <9J8dgUvySQ8hSSNhPJe0FylFV8YbKD78AYG8vKDn0WI=.a767c78a-86e3-42b8-a484-8fa5f5f4f0f0@github.com>

On Mon, 7 Dec 2020 19:35:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   pre-init getParameters nonce data is now a local variable
>
> Marked as reviewed by mullan (Reviewer).

The test should probably have the bugid added to it.

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

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

From valeriep at openjdk.java.net  Mon Dec  7 19:46:14 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 7 Dec 2020 19:46:14 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
Message-ID: <IAmsewGw0sxJOe-CeGYesemzyZYT0CVttdVjKQ3nSs0=.3bcb2b9e-1afe-4c80-86dd-f9d1de47acc8@github.com>

On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pre-init getParameters nonce data is now a local variable

Outside of Cipher.getParameters(), there are other direct references of nonce which may lead to NPE which we should fix also. Inside engineGetIV(), it should check for null nonce before directly calling clone().

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

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

From valeriep at openjdk.java.net  Mon Dec  7 19:56:15 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 7 Dec 2020 19:56:15 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
Message-ID: <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>

On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pre-init getParameters nonce data is now a local variable

src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:

> 230:             // this call should cause a random nonce to be generated, but
> 231:             // not attached to the object.
> 232:             byte[] nonceData = initialized ? nonce : createRandomNonce(null);

The "initialized" variable is set to false in engineDoFinal() call. So, if users call getParameters() after finish cipher operation, this will return random nonces instead of the one used in previous doFinal operation. Will this be a little un-intuitive?

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 20:02:15 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 20:02:15 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <DxZrBT9VtvgogEIR2CXa9dHKKhvJnFqhu_KwHB4cGnw=.540790f0-e452-488d-86e6-ab980c9975e3@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <DxZrBT9VtvgogEIR2CXa9dHKKhvJnFqhu_KwHB4cGnw=.540790f0-e452-488d-86e6-ab980c9975e3@github.com>
Message-ID: <dD5HNHyfDCzlKzDZGeUAOHnVvKPGK46o2AMSrxh5W38=.ff572ad0-54c1-4ec7-bafe-1bb36b7e256e@github.com>

On Mon, 7 Dec 2020 19:35:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   pre-init getParameters nonce data is now a local variable
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:
> 
>> 230:             // this call should cause a random nonce to be generated, but
>> 231:             // not attached to the object.
>> 232:             byte[] nonceData = initialized ? nonce : createRandomNonce(null);
> 
> A minor unrelated comment is that createRandomNonce() could be made static.

Easy enough to do.

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 20:05:16 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 20:05:16 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>
Message-ID: <GxiVA2aK9VmTr21R0pTm1sUHXOmB8WCMBcIwQjtRc9U=.fb09f842-2dc5-47ba-a7ee-de0afd2dc808@github.com>

On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   pre-init getParameters nonce data is now a local variable
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:
> 
>> 230:             // this call should cause a random nonce to be generated, but
>> 231:             // not attached to the object.
>> 232:             byte[] nonceData = initialized ? nonce : createRandomNonce(null);
> 
> The "initialized" variable is set to false in engineDoFinal() call. So, if users call getParameters() after finish cipher operation, this will return random nonces instead of the one used in previous doFinal operation. Will this be a little un-intuitive?

Unintuitive is a charitable way to put it.  After doFinal the Cipher technically isn't in an uninitialized state per the spec, it's supposed to be in the state it would be immediately following init().  So the wrong behavior would happen in this use case.  Will fix.

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 22:32:23 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 22:32:23 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v3]
In-Reply-To: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
Message-ID: <lN4DP3dDxJc5JadJ46TqTuUow4La0FVdN1l8r-xwO5o=.fdbd2f2b-0787-4f69-aa19-75ce4b80ae11@github.com>

> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

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

  Fix minor issues in getIV() and post-encryption getParameters() behavior

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1644/files
  - new: https://git.openjdk.java.net/jdk/pull/1644/files/b9a24482..0f74545b

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

  Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1644/head:pull/1644

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

From valeriep at openjdk.java.net  Mon Dec  7 23:10:14 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 7 Dec 2020 23:10:14 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v3]
In-Reply-To: <lN4DP3dDxJc5JadJ46TqTuUow4La0FVdN1l8r-xwO5o=.fdbd2f2b-0787-4f69-aa19-75ce4b80ae11@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <lN4DP3dDxJc5JadJ46TqTuUow4La0FVdN1l8r-xwO5o=.fdbd2f2b-0787-4f69-aa19-75ce4b80ae11@github.com>
Message-ID: <7QMspN2vb6Pf3oKjCkBPcZAlQeyb_imE-wDOEj6agMM=.ea9c9e1c-7f90-4e98-93dd-128b487fb4ca@github.com>

On Mon, 7 Dec 2020 22:32:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minor issues in getIV() and post-encryption getParameters() behavior

Marked as reviewed by valeriep (Reviewer).

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

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

From xuelei at openjdk.java.net  Mon Dec  7 23:40:18 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Dec 2020 23:40:18 GMT
Subject: RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 reports leaks
Message-ID: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>

This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.  Move it to manual test.

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

Commit messages:
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks

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

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

From jnimeh at openjdk.java.net  Mon Dec  7 23:49:15 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Dec 2020 23:49:15 GMT
Subject: RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 reports leaks
In-Reply-To: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
References: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
Message-ID: <cowu-ApZRpFyImDPqaREpZ9cnfE_xZVcxXocnDggbUk=.60e99abc-0f0e-4e83-8c4c-565cbf9a54c9@github.com>

On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.  Move it to manual test.

Looks fine to me.

test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 39:

> 37:  * @run main/manual SSLSocketLeak
> 38:  */
> 39: // Note: this test is not reliabe, run it manually.

Typo reliabe -> reliable

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

Marked as reviewed by jnimeh (Reviewer).

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

From clanger at openjdk.java.net  Mon Dec  7 23:49:15 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 7 Dec 2020 23:49:15 GMT
Subject: RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 reports leaks
In-Reply-To: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
References: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
Message-ID: <ueI5Fq0-X4qlgh6pOTZL0ETOOlpw8t-b-V46MgadFYU=.77a87d5b-6f62-4659-96c9-6adb5e4bc63c@github.com>

On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.  Move it to manual test.

Did you check whether the test failure is maybe specific to windows? Comments at the JBS issue are suggesting that...

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

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

From xuelei at openjdk.java.net  Mon Dec  7 23:56:23 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Dec 2020 23:56:23 GMT
Subject: RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 reports leaks [v2]
In-Reply-To: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
References: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
Message-ID: <s6pBX-5JA_6W6SSQEaYBwZJzi0QnxSxuQbtK9S8ZmJ0=.e5784137-7784-4863-a36b-526cf05b6acf@github.com>

> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.  Move it to manual test.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  typo correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1681/files
  - new: https://git.openjdk.java.net/jdk/pull/1681/files/4324892c..58ec75fa

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

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

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

From xuelei at openjdk.java.net  Mon Dec  7 23:56:24 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Dec 2020 23:56:24 GMT
Subject: RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 reports leaks [v2]
In-Reply-To: <cowu-ApZRpFyImDPqaREpZ9cnfE_xZVcxXocnDggbUk=.60e99abc-0f0e-4e83-8c4c-565cbf9a54c9@github.com>
References: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
 <cowu-ApZRpFyImDPqaREpZ9cnfE_xZVcxXocnDggbUk=.60e99abc-0f0e-4e83-8c4c-565cbf9a54c9@github.com>
Message-ID: <uISQIrocW_Hm9SOYZOlRZ0vuElbhZ1XE8fHaNwI3iXs=.6774ca9b-285e-4024-b3a8-6ef3f48c28d2@github.com>

On Mon, 7 Dec 2020 23:44:41 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo correction
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 39:
> 
>> 37:  * @run main/manual SSLSocketLeak
>> 38:  */
>> 39: // Note: this test is not reliabe, run it manually.
> 
> Typo reliabe -> reliable

Thank you! Corrected.

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

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

From xuelei at openjdk.java.net  Mon Dec  7 23:56:25 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Dec 2020 23:56:25 GMT
Subject: Integrated: 8257670:
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
In-Reply-To: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
References: <7PCZJCnD_rrN_mHOXSl4F28fXsyn5QFlvAExC-niNTk=.5d62d0c2-e4a9-450b-962a-f2a536f03690@github.com>
Message-ID: <sEVZIWfBcg3GLzuQKpPxOfR1I2cxNi2VLhRQ67pTLAU=.d196715c-f393-4bae-ba42-d10414ca7556@github.com>

On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not reliable if there are some other test cases or applications running at the same time.  It's a good manual test, but might be not suitable for OpenJDK automation regression test if it could be impacted.  Move it to manual test.

This pull request has now been integrated.

Changeset: 39b8a2e6
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39b8a2e6
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks

Reviewed-by: jnimeh

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

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

From ecki at zusammenkunft.net  Tue Dec  8 01:19:48 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 8 Dec 2020 01:19:48 +0000
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <GxiVA2aK9VmTr21R0pTm1sUHXOmB8WCMBcIwQjtRc9U=.fb09f842-2dc5-47ba-a7ee-de0afd2dc808@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>,
 <GxiVA2aK9VmTr21R0pTm1sUHXOmB8WCMBcIwQjtRc9U=.fb09f842-2dc5-47ba-a7ee-de0afd2dc808@github.com>
Message-ID: <AM6PR03MB438990A3BF049D5107CA6FD1FFCD0@AM6PR03MB4389.eurprd03.prod.outlook.com>

BTW stupid - somewhat related - question, why does the nonce to be parsed out of a DER blob, shouldn?t there be an getter on the Parameter Spec object? Many protocols would need the raw array, is there a matching spec - or should we add one?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Jamil Nimeh <jnimeh at openjdk.java.net>
Gesendet: Monday, December 7, 2020 9:05:16 PM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: RFR: 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305 [v2]

On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   pre-init getParameters nonce data is now a local variable
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 232:
>
>> 230:             // this call should cause a random nonce to be generated, but
>> 231:             // not attached to the object.
>> 232:             byte[] nonceData = initialized ? nonce : createRandomNonce(null);
>
> The "initialized" variable is set to false in engineDoFinal() call. So, if users call getParameters() after finish cipher operation, this will return random nonces instead of the one used in previous doFinal operation. Will this be a little un-intuitive?

Unintuitive is a charitable way to put it.  After doFinal the Cipher technically isn't in an uninitialized state per the spec, it's supposed to be in the state it would be immediately following init().  So the wrong behavior would happen in this use case.  Will fix.

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

PR: https://git.openjdk.java.net/jdk/pull/1644
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201208/1507b679/attachment-0001.htm>

From jamil.j.nimeh at oracle.com  Tue Dec  8 01:39:15 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 7 Dec 2020 17:39:15 -0800
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <AM6PR03MB438990A3BF049D5107CA6FD1FFCD0@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>
 <GxiVA2aK9VmTr21R0pTm1sUHXOmB8WCMBcIwQjtRc9U=.fb09f842-2dc5-47ba-a7ee-de0afd2dc808@github.com>
 <AM6PR03MB438990A3BF049D5107CA6FD1FFCD0@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <651186a8-76d6-d5b7-d959-f52eb8a838ab@oracle.com>

Hi Bernd, it's not a stupid question at all.? I think what you might be 
looking for is Cipher.getIV()?? In the case of ChaCha20-Poly1305, that 
method returns the nonce as a byte array where getParameters() returns 
an AlgorithmParameters object where the encoding is consistent with RFC 
8103.

But both getParameters() and getIV() were doing the wrong thing 
(chucking NPE) when they should've either come up with a random param or 
null, respectively when in a pre-initialized state.

--Jamil

On 12/7/2020 5:19 PM, Bernd Eckenfels wrote:
> BTW stupid - somewhat related - question, why does the nonce to be 
> parsed out of a DER blob, shouldn?t there be an getter on the 
> Parameter Spec object? Many protocols would need the raw array, is 
> there a matching spec - or should we add one?
>
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-retn at openjdk.java.net> im Auftrag 
> von Jamil Nimeh <jnimeh at openjdk.java.net>
> *Gesendet:* Monday, December 7, 2020 9:05:16 PM
> *An:* security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> *Betreff:* Re: RFR: 8257769: Cipher.getParameters() throws NPE for 
> ChaCha20-Poly1305 [v2]
> On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng <valeriep at openjdk.org> 
> wrote:
>
> >> Jamil Nimeh has updated the pull request incrementally with one 
> additional commit since the last revision:
> >>
> >>?? pre-init getParameters nonce data is now a local variable
> >
> > 
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java 
> line 232:
> >
> >> 230:???????????? // this call should cause a random nonce to be 
> generated, but
> >> 231:???????????? // not attached to the object.
> >> 232:???????????? byte[] nonceData = initialized ? nonce : 
> createRandomNonce(null);
> >
> > The "initialized" variable is set to false in engineDoFinal() call. 
> So, if users call getParameters() after finish cipher operation, this 
> will return random nonces instead of the one used in previous doFinal 
> operation. Will this be a little un-intuitive?
>
> Unintuitive is a charitable way to put it.? After doFinal the Cipher 
> technically isn't in an uninitialized state per the spec, it's 
> supposed to be in the state it would be immediately following init().? 
> So the wrong behavior would happen in this use case.? Will fix.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1644 
> <https://git.openjdk.java.net/jdk/pull/1644>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201207/629fdbc9/attachment.htm>

From jamil.j.nimeh at oracle.com  Tue Dec  8 01:56:31 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 7 Dec 2020 17:56:31 -0800
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v2]
In-Reply-To: <651186a8-76d6-d5b7-d959-f52eb8a838ab@oracle.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
 <D-BM9oySCiN_yLL-dlWQtlGl3pOq953--kc-SP800eI=.eb0b7b0e-0282-48d0-ba3f-ecd056884f94@github.com>
 <WUwE3_tobN8ScRs5irkRE1ZSnrtUS1Mwi1zw25eYBKg=.dd4602c0-ce13-4163-9371-0f22714d336b@github.com>
 <GxiVA2aK9VmTr21R0pTm1sUHXOmB8WCMBcIwQjtRc9U=.fb09f842-2dc5-47ba-a7ee-de0afd2dc808@github.com>
 <AM6PR03MB438990A3BF049D5107CA6FD1FFCD0@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <651186a8-76d6-d5b7-d959-f52eb8a838ab@oracle.com>
Message-ID: <75003d5f-09b5-d984-6460-6f5cc716a314@oracle.com>

Oh, one other thing in case you weren't talking about this in the 
context of Cipher and instead were talking about the AlgorithmParameters 
object itself.? If that's all you've got in scope one approach is to 
call getParameterSpec(IvParameterSpec.class).getIV();? That will give 
you the byte array as well.? Now that I think about it, I should 
probably do that in my test code because I went and manually parsed the 
DER encoding.? :)? Glad you brought it up.

--Jamil

On 12/7/2020 5:39 PM, Jamil Nimeh wrote:
>
> Hi Bernd, it's not a stupid question at all.? I think what you might 
> be looking for is Cipher.getIV()?? In the case of ChaCha20-Poly1305, 
> that method returns the nonce as a byte array where getParameters() 
> returns an AlgorithmParameters object where the encoding is consistent 
> with RFC 8103.
>
> But both getParameters() and getIV() were doing the wrong thing 
> (chucking NPE) when they should've either come up with a random param 
> or null, respectively when in a pre-initialized state.
>
> --Jamil
>
> On 12/7/2020 5:19 PM, Bernd Eckenfels wrote:
>> BTW stupid - somewhat related - question, why does the nonce to be 
>> parsed out of a DER blob, shouldn?t there be an getter on the 
>> Parameter Spec object? Many protocols would need the raw array, is 
>> there a matching spec - or should we add one?
>>
>> Gruss
>> Bernd
>> -- 
>> http://bernd.eckenfels.net
>> ------------------------------------------------------------------------
>> *Von:* security-dev <security-dev-retn at openjdk.java.net> im Auftrag 
>> von Jamil Nimeh <jnimeh at openjdk.java.net>
>> *Gesendet:* Monday, December 7, 2020 9:05:16 PM
>> *An:* security-dev at openjdk.java.net <security-dev at openjdk.java.net>
>> *Betreff:* Re: RFR: 8257769: Cipher.getParameters() throws NPE for 
>> ChaCha20-Poly1305 [v2]
>> On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng <valeriep at openjdk.org> 
>> wrote:
>>
>> >> Jamil Nimeh has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> >>
>> >>?? pre-init getParameters nonce data is now a local variable
>> >
>> > 
>> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java 
>> line 232:
>> >
>> >> 230:???????????? // this call should cause a random nonce to be 
>> generated, but
>> >> 231:???????????? // not attached to the object.
>> >> 232:???????????? byte[] nonceData = initialized ? nonce : 
>> createRandomNonce(null);
>> >
>> > The "initialized" variable is set to false in engineDoFinal() call. 
>> So, if users call getParameters() after finish cipher operation, this 
>> will return random nonces instead of the one used in previous doFinal 
>> operation. Will this be a little un-intuitive?
>>
>> Unintuitive is a charitable way to put it.? After doFinal the Cipher 
>> technically isn't in an uninitialized state per the spec, it's 
>> supposed to be in the state it would be immediately following 
>> init().? So the wrong behavior would happen in this use case.? Will fix.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1644 
>> <https://git.openjdk.java.net/jdk/pull/1644>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201207/a4cf13f7/attachment.htm>

From mchung at openjdk.java.net  Tue Dec  8 02:43:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 02:43:19 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
Message-ID: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>

On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

Hi Magnus,

I see the motivation of moving these build files for better identification of ownership.   Placing them under
`src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

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

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

From jnimeh at openjdk.java.net  Tue Dec  8 05:03:23 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 8 Dec 2020 05:03:23 GMT
Subject: RFR: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305 [v4]
In-Reply-To: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
Message-ID: <m-M2cvHIT28oFPzo_Md8vh03MHsIUTJh8U5XE0pyThQ=.1896cd89-b6f9-4c44-8d90-5794bbde4926@github.com>

> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

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

  Simplfied getNonceFromParams to use IvParameterSpec.getIV()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1644/files
  - new: https://git.openjdk.java.net/jdk/pull/1644/files/0f74545b..fc2cb52f

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

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

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

From minqi at openjdk.java.net  Tue Dec  8 05:45:20 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Dec 2020 05:45:20 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <TguKP3F3tuAgdzImLvrt5s35nBTy1w6msEIGYNmWsq8=.0c36bee0-a2d6-48c0-84a8-a60b31e1df28@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision:

 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - 8257805: Add compiler/blackhole tests to tier1
   
   Reviewed-by: kvn
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/dd9ae050...f7958306

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1657/files
  - new: https://git.openjdk.java.net/jdk/pull/1657/files/dd9ae050..f7958306

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

  Stats: 8052 lines in 156 files changed: 4548 ins; 2755 del; 749 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From jnimeh at openjdk.java.net  Tue Dec  8 06:13:14 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 8 Dec 2020 06:13:14 GMT
Subject: Integrated: 8257769: Cipher.getParameters() throws NPE for
 ChaCha20-Poly1305
In-Reply-To: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
References: <U1tX6Gnj3_XiEGys8hcRKLDnbjhqnQgCIJr_jdhcb_4=.9a36f5df-e9b1-46a4-8224-5c9d56bdf091@github.com>
Message-ID: <0TsSN6Zcs0Nr-YVSVAPybx-YbOCwSMM4L_mbS_xQqAU=.0bdee62f-8e79-447c-99c6-3953828f8c92@github.com>

On Sat, 5 Dec 2020 23:23:47 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init throw NPE when getParameters() is called.  It will now generate parameters containing a random nonce on each pre-init call to getParameters(). Post-initialization calls to the getParameters() method will always return the same set of parameters until the next initialization occurs.

This pull request has now been integrated.

Changeset: 500ab457
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/500ab457
Stats:     125 lines in 2 files changed: 119 ins; 0 del; 6 mod

8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305

Reviewed-by: mullan, valeriep

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

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

From clanger at openjdk.java.net  Tue Dec  8 07:32:18 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 8 Dec 2020 07:32:18 GMT
Subject: RFR: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
Message-ID: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>

The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic noise because sometimes it opens more file handles than expected. It was moved to a manual test to quiesce this ([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))

It would be good, however, to have this test as an automatic test to be able to spot potential regressions. The threshold for windows should be adapted.

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

Commit messages:
 - 8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test

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

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

From ihse at openjdk.java.net  Tue Dec  8 08:30:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:30:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
Message-ID: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>

On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>
> Hi Magnus,
> 
> I see the motivation of moving these build files for better identification of ownership.   Placing them under
> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

@mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!

This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

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

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

From ihse at openjdk.java.net  Tue Dec  8 08:35:13 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:35:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>

On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Magnus,
>> 
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
>
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
> 
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

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

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

From alanb at openjdk.java.net  Tue Dec  8 12:18:20 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 12:18:20 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
Message-ID: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>

On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>> 
>> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

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

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

From erik.joelsson at oracle.com  Tue Dec  8 14:05:28 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 8 Dec 2020 06:05:28 -0800
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <c7811a03-ceba-1482-ae36-1c3bf5e0eed3@oracle.com>


On 2020-12-08 00:30, Magnus Ihse Bursie wrote:
> On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>
>>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
I strongly agree with Magnus for all the same reasons. To me, the data 
files are clearly a form of source code that should be considered owned 
by the component teams. I'm honestly perplexed over why this is being 
argued against.

/Erik

> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1611

From herrick at openjdk.java.net  Tue Dec  8 15:11:50 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 15:11:50 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618 [v2]
In-Reply-To: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
Message-ID: <UhKMC14CZoXTrgGQrC8iJJFVSzaTYCXD3whnca5s7Dw=.fd4c1d0f-822c-43c4-a27b-7cfa610d571d@github.com>

> increase retries and timeout increasing in runMsiexecWithRetries

Andy Herrick has updated the pull request incrementally with 18 additional commits since the last revision:

 - 8256149: Weird AST structure for incomplete member select
   
   Reviewed-by: vromero
 - 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary
   
   Reviewed-by: jvernee, shade
 - 8257848: -XX:CompileCommand=blackhole,* should be diagnostic
   
   Reviewed-by: vlivanov
 - 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input
   
   Reviewed-by: alanb
 - 8254733: HotSpot Style Guide should permit using range-based for loops
   
   Reviewed-by: dholmes, pliden, jrose, dcubed, iklam, eosterlund, tschatzl, kvn
 - 8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected
   
   Reviewed-by: roland, kvn
 - 8256411: Based anonymous classes have a weird end position
   
   Reviewed-by: vromero
 - 8257813: [redo] C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops
   
   Reviewed-by: chagedorn, kvn
 - 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305
   
   Reviewed-by: mullan, valeriep
 - 8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java
   
   Reviewed-by: jjg
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/7c4743c5...5d065497

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1676/files
  - new: https://git.openjdk.java.net/jdk/pull/1676/files/7c4743c5..5d065497

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

  Stats: 1938 lines in 49 files changed: 1465 ins; 276 del; 197 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1676.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1676/head:pull/1676

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

From weijun at openjdk.java.net  Tue Dec  8 15:28:11 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 8 Dec 2020 15:28:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?

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

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

From ihse at openjdk.java.net  Tue Dec  8 16:20:21 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:20:21 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <XJDGP3MtiEMsfcKaybq1ZpasjInl_6TwEOxVCVKnPgU=.9c47e0ac-6c43-42f9-b2d6-22675351814a@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

@AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:

> As to charsetmapping and cldrconverter, I believe they can reside in 
java.base, as jdk.charsets and jdk.localedata modules depend on it.

Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.

Specifically for  make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

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

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

From herrick at openjdk.java.net  Tue Dec  8 16:25:03 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 16:25:03 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618
In-Reply-To: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
 <s8py0M4XMsD6CRz15ZUuN2ipQFB9T5lGttkbIwqh_Us=.2b5ec883-00fe-49ca-b36c-cbe419f9a5cf@github.com>
 <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
Message-ID: <KXhwC_QsPvLZbWxx0VOSHwM2T11LVIahL_eGfyzUTw8=.239cab51-45a1-468d-bc51-58aae763e853@github.com>

On Tue, 8 Dec 2020 14:56:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
>
>> 
>> 
>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
> 
> If you scroll down from that error - you can see that that is the expected error and the return code from jpackage is asserted to be 1, and it is asserted that the resulting WinL10NTest.msi does not exist.
> 
> the @Parameters for "data" cause instance of this test to be run 8 times with different args.  This instances is expected to fail since allWxlFilesValid is false.
> later in the log (https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-16+26-1740-tier2-20201124-1335-16116386-open_test_jdk_tier2_part2-windows-x64-125-1606226621-1556/log) you can see the timeout, where unpack.bat is run three times with 3 second delay and returns 1618 each time:
> **13:58:30.303] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:33.469] TRACE: exec: Done. Exit code: 1618
> [13:58:36.492] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:39.636] TRACE: exec: Done. Exit code: 1618
> [13:58:42.652] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:45.803] TRACE: exec: Done. Exit code: 1618
> [13:58:48.832] ERROR: Expected [0]. Actual [1618]: Check command [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3) exited with 0 code
> [13:58:48.832] [  FAILED  ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=fr](length=2), fr;en-us, null).test; checks=17
> [13:58:48.832] [ RUN      ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=it, name=c.wxl; culture=fr, name=d.wxl; culture=it](length=4), fr;it;en-us,**
> 
> running unpack.bat with msiexec command in it succeed for one test instance after the expected failure, then got 1618 return on the second test instance after the expected failure with the above timeout.

I converted to draft because somehow merging with master caused a mess - since is simple change in one test file I may create a new branch and new pull request cleanly again.

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

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

From ihse at openjdk.java.net  Tue Dec  8 16:25:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:25:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
Message-ID: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>

On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
> 
> Update: I see all subdirs in tools are still there.

@wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.

I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

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

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

From xuelei at openjdk.java.net  Tue Dec  8 16:31:11 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Dec 2020 16:31:11 GMT
Subject: RFR: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
In-Reply-To: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
References: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
Message-ID: <zMDakwtLQ12herzK6ajopjbTdkg4qybADgyVBNtHSYA=.e797a479-6a13-410e-9048-05ece361ab00@github.com>

On Tue, 8 Dec 2020 07:27:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic noise because sometimes it opens more file handles than expected. It was moved to a manual test to quiesce this ([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))
> 
> It would be good, however, to have this test as an automatic test to be able to spot potential regressions. The threshold for windows should be adapted.

Marked as reviewed by xuelei (Reviewer).

test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 61:

> 59:         System.out.println("FDs in the end: " + fds_end);
> 60: 
> 61:         if ((fds_end - fds_start) > (NUM_TEST_SOCK / OPEN_HANDLE_GROWTH_THRESHOLD)) {

It looks like the test may still fail intermittently.  But let's do it for now and see if it is reliable to be an automation test case.

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

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

From alanb at openjdk.java.net  Tue Dec  8 17:36:08 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 17:36:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

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

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

From hchao at openjdk.java.net  Tue Dec  8 17:57:14 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 17:57:14 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?=
Message-ID: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>

This is a spec change with noreg-doc label.

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

Commit messages:
 - 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec mismatch to its behavior

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

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

From xuelei at openjdk.java.net  Tue Dec  8 18:13:07 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Dec 2020 18:13:07 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?=
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <-Oi_y56xsm13MiNJiCbdtr1aFHxyOvDbYhoRHipEXq0=.75137841-ebb3-41ee-b260-3639bbbf131d@github.com>

On Tue, 8 Dec 2020 17:52:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This is a spec change with noreg-doc label.

src/java.base/share/classes/java/security/KeyStoreSpi.java line 319:

> 317:      * @throws    CertificateException if any of the certificates included in
> 318:      *          the keystore data could not be stored
> 319:      * @throws    UnsupportedOperationException if this method is not supported

We might be able to get it more clear about the behavior.  For example, adding an implSpec tag, like:
     * @implSpec The default implementation throws
     *           an {@link UnsupportedOperationException}.
     ...
     * @throws UnsupportedOperationException if the implementation
     *         has not overridden this method

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:20:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:20:07 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
Message-ID: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>

On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
>> 
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
> 
> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

@magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.

I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:24:08 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:24:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
 <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
Message-ID: <XbBJA_8zarG-F3qYYl0yXuS4ftw17t0gQbvE-o8mBOc=.2d1bb989-40d6-48c8-bc79-7f36580e000c@github.com>

On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>> 
>> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.
>
> @magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.
> 
> I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

With these new files showing up in under `src` directory, should `bin/idea.sh` be changed to exclude `data` to avoid incurring costs in loading JDK project from IDE that many of us use for development?

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

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

From hchao at openjdk.java.net  Tue Dec  8 18:36:15 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 18:36:15 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?= [v2]
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>

> This is a spec change with noreg-doc label.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated with implSpec tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1701/files
  - new: https://git.openjdk.java.net/jdk/pull/1701/files/496360a7..a153f4f3

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

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

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

From hchao at openjdk.java.net  Tue Dec  8 18:36:16 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 18:36:16 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?= [v2]
In-Reply-To: <-Oi_y56xsm13MiNJiCbdtr1aFHxyOvDbYhoRHipEXq0=.75137841-ebb3-41ee-b260-3639bbbf131d@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <-Oi_y56xsm13MiNJiCbdtr1aFHxyOvDbYhoRHipEXq0=.75137841-ebb3-41ee-b260-3639bbbf131d@github.com>
Message-ID: <yVCYSjS2k0PR0o-BGfy9KVaS7DjjJbyNtMr2QJ5yvCo=.89eb7519-31f3-4aa3-8aeb-7d24760e0400@github.com>

On Tue, 8 Dec 2020 18:08:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with implSpec tag
>
> src/java.base/share/classes/java/security/KeyStoreSpi.java line 319:
> 
>> 317:      * @throws    CertificateException if any of the certificates included in
>> 318:      *          the keystore data could not be stored
>> 319:      * @throws    UnsupportedOperationException if this method is not supported
> 
> We might be able to get it more clear about the behavior.  For example, adding an implSpec tag, like:
>      * @implSpec The default implementation throws
>      *           an {@link UnsupportedOperationException}.
>      ...
>      * @throws UnsupportedOperationException if the implementation
>      *         has not overridden this method

tag implSpec added. Thanks for the review.

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

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

From naoto at openjdk.java.net  Tue Dec  8 18:44:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Dec 2020 18:44:10 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <k9qXBPmHPOK7f3RlgFTgAwZ_xNkAHcCP2BMajiIcUHA=.05b9e889-3dd2-4e3f-b5a5-41c629077255@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
> 
> > As to charsetmapping and cldrconverter, I believe they can reside in
> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
> 
> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.
> 
> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory.

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

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

From xuelei at openjdk.java.net  Tue Dec  8 18:45:16 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Dec 2020 18:45:16 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?= [v2]
In-Reply-To: <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
Message-ID: <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>

On Tue, 8 Dec 2020 18:36:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This is a spec change with noreg-doc label.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with implSpec tag

Marked as reviewed by xuelei (Reviewer).

src/java.base/share/classes/java/security/KeyStoreSpi.java line 322:

> 320:      * @throws    CertificateException if any of the certificates included in
> 321:      *          the keystore data could not be stored
> 322:      * @throws UnsupportedOperationException if the implementation

Please add an extra white space after the "throws" tag so that this line align with the lines above.

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

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

From xuelei at openjdk.java.net  Tue Dec  8 18:45:17 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Dec 2020 18:45:17 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?=
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <7zRPR7JNN1WmKOELOUk4ltda3r8OjEy7a51h0pYS40E=.9fd81f03-aed0-4988-a214-f4f424bb62b0@github.com>

On Tue, 8 Dec 2020 17:52:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This is a spec change with noreg-doc label.

There is a "Title mismatch between PR and JBS" issue.  I think it could be solved by use the same title/subject for the pull request and bug in JBS.

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

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

From mullan at openjdk.java.net  Tue Dec  8 18:55:12 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Dec 2020 18:55:12 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch =?UTF-8?B?dOKApg==?= [v2]
In-Reply-To: <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
Message-ID: <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>

On Tue, 8 Dec 2020 18:42:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with implSpec tag
>
> Marked as reviewed by xuelei (Reviewer).

This will also require a CSR since you are making some specification changes. I'm not sure if you were trying to get this into 16, but it is probably too late to make JDK 16 since RDP is a couple of days away. You can push to 17/latest once 16 forks and CSR is approved.

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

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

From ihse at openjdk.java.net  Tue Dec  8 19:15:46 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 19:15:46 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <NvyCKRMEPTJVNNstfqibDocrM3eRvRhp-oKn4RwS5JU=.25dc3794-c662-47ef-ac56-bed4e398cbbe@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

@AlanBateman @mlchung @naotoj I can certainly anticipate follow-up cleanups on this patch. In fact, I think this patch has the potential to be a catalyst for such change, since the data that has been "hidden away" in `make` now becomes more visible to the teams that are capable of doing something about it. (With that said, of course the build team will assist in helping to clear up messy code structure, as we always do.) But I think we should be restrictive in trying too hard to make everything right in this single patch; it's better to get things approximately right and then go through the "warts" one by one and solve them properly.

@AlanBateman What I meant by Jigsaw was that when the monolithic source code were modularized, the separation of concern between java.base and jdk.charsets/jdk.localedata was not complete, compared to (more or less) all other modules. It might very well be the case that we will never be able to make such a separation; but, prior to Jigsaw, this was not a "wart". It only became a code hygiene issue when some of the charsets and localedata was extraced from java.base.

@mlchung My gut reaction is that we should not change idea.sh. First of all, kind of the purpose of this move is to make it clear to module developers the full set of materials their module consists of. That purpose would be sort of defeated, if we were to hide this in a popular IDE configuration. Secondly, I doubt this will add any performance difference. Listing additional files in the workspace is unlikely to do much, unless you actively open and/or interact with these files. But if you are worried, please fetch the PR (Skara adds instructions in the body) and try it out yourself!

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

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

From hchao at openjdk.java.net  Tue Dec  8 20:30:51 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 20:30:51 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v3]
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <jUSVvjBQiISkuH6qxLtgvOjfeN7ituy2HEBQEz41l0A=.1c54ca5f-c0f3-4074-9998-55f37cc2bf3a@github.com>

> This is a spec change with noreg-doc label.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  white space after throw tag added

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1701/files
  - new: https://git.openjdk.java.net/jdk/pull/1701/files/a153f4f3..265b7e22

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

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

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

From mullan at openjdk.java.net  Tue Dec  8 20:30:53 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Dec 2020 20:30:53 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
Message-ID: <UodQ1GV3SiStomI5Z5XsKhf2NJSF0vsIBmA7AT-PlLo=.d78b64e1-dbb2-4323-85c2-c3a425896f51@github.com>

On Tue, 8 Dec 2020 18:42:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with implSpec tag
>
> src/java.base/share/classes/java/security/KeyStoreSpi.java line 322:
> 
>> 320:      * @throws    CertificateException if any of the certificates included in
>> 321:      *          the keystore data could not be stored
>> 322:      * @throws UnsupportedOperationException if the implementation
> 
> Please add an extra white space after the "throws" tag so that this line align with the lines above.

On line 310 and 315, can you also fix the typos as part of this change: s/KeyStore.LoadStoreParmeter/KeyStore.LoadStoreParameter/

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

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

From mullan at openjdk.java.net  Tue Dec  8 20:30:54 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Dec 2020 20:30:54 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
Message-ID: <AS7rBlbxCJsTPg7-JR30zaqoYQeGOxRZ4k5APTD7q94=.02ee8762-619e-446f-8571-77f2e79ce914@github.com>

On Tue, 8 Dec 2020 18:36:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This is a spec change with noreg-doc label.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with implSpec tag

src/java.base/share/classes/java/security/KeyStoreSpi.java line 323:

> 321:      *          the keystore data could not be stored
> 322:      * @throws UnsupportedOperationException if the implementation
> 323:      *          has not overridden this method

I think we should keep this more general and just say "If the implementation does not support this operation". There may be legitimate cases in which an implementation may override this method but throw UnsupportedOperationException if it doesn't support particular aspects of the LoadStoreParameter.

src/java.base/share/classes/java/security/KeyStore.java line 1424:

> 1422:      * @throws    CertificateException if any of the certificates included in
> 1423:      *          the keystore data could not be stored
> 1424:      * @throws    UnsupportedOperationException if this method is not supported

I would change "method" to "operation" as it is a bit more consistent with the exception.

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

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

From hchao at openjdk.java.net  Tue Dec  8 20:48:37 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 20:48:37 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <UodQ1GV3SiStomI5Z5XsKhf2NJSF0vsIBmA7AT-PlLo=.d78b64e1-dbb2-4323-85c2-c3a425896f51@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <UodQ1GV3SiStomI5Z5XsKhf2NJSF0vsIBmA7AT-PlLo=.d78b64e1-dbb2-4323-85c2-c3a425896f51@github.com>
Message-ID: <2ggQ5JpoVzIKWePx22vQtR18SjY2vclDTNvQGD3NDk0=.d47c3ca1-9cc1-4fde-98fe-e9133cf8c502@github.com>

On Tue, 8 Dec 2020 20:16:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/KeyStoreSpi.java line 322:
>> 
>>> 320:      * @throws    CertificateException if any of the certificates included in
>>> 321:      *          the keystore data could not be stored
>>> 322:      * @throws UnsupportedOperationException if the implementation
>> 
>> Please add an extra white space after the "throws" tag so that this line align with the lines above.
>
> On line 310 and 315, can you also fix the typos as part of this change: s/KeyStore.LoadStoreParmeter/KeyStore.LoadStoreParameter/

Added the white space. Sure, I can include those typos fix in this PR. Also, included another typo fix for line 305.

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

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

From hchao at openjdk.java.net  Tue Dec  8 21:00:41 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 21:00:41 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <AS7rBlbxCJsTPg7-JR30zaqoYQeGOxRZ4k5APTD7q94=.02ee8762-619e-446f-8571-77f2e79ce914@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <AS7rBlbxCJsTPg7-JR30zaqoYQeGOxRZ4k5APTD7q94=.02ee8762-619e-446f-8571-77f2e79ce914@github.com>
Message-ID: <OsTmoIxNrlAmSRKpS_JNXBhmnA2BMuMvhOBfitxQvGo=.68182c34-45c1-4fcd-b139-01011f7ed064@github.com>

On Tue, 8 Dec 2020 20:24:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with implSpec tag
>
> src/java.base/share/classes/java/security/KeyStoreSpi.java line 323:
> 
>> 321:      *          the keystore data could not be stored
>> 322:      * @throws UnsupportedOperationException if the implementation
>> 323:      *          has not overridden this method
> 
> I think we should keep this more general and just say "If the implementation does not support this operation". There may be legitimate cases in which an implementation may override this method but throw UnsupportedOperationException if it doesn't support particular aspects of the LoadStoreParameter.

Good point. Fixed as suggested.

> src/java.base/share/classes/java/security/KeyStore.java line 1424:
> 
>> 1422:      * @throws    CertificateException if any of the certificates included in
>> 1423:      *          the keystore data could not be stored
>> 1424:      * @throws    UnsupportedOperationException if this method is not supported
> 
> I would change "method" to "operation" as it is a bit more consistent with the exception.

Fixed as suggested. Thanks for the review.

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

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

From hchao at openjdk.java.net  Tue Dec  8 21:05:50 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Dec 2020 21:05:50 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v4]
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <fHe-mTwshLbsL_jeuJw6Rg5IXVJTE8aSbDq-mNrE8m0=.9e7522f7-0385-4c82-ba0d-fc81f4c85c11@github.com>

> This is a spec change with noreg-doc label.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  updated spec text and included typo fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1701/files
  - new: https://git.openjdk.java.net/jdk/pull/1701/files/265b7e22..12db7941

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

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

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

From clanger at openjdk.java.net  Tue Dec  8 22:19:36 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 8 Dec 2020 22:19:36 GMT
Subject: RFR: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
In-Reply-To: <zMDakwtLQ12herzK6ajopjbTdkg4qybADgyVBNtHSYA=.e797a479-6a13-410e-9048-05ece361ab00@github.com>
References: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
 <zMDakwtLQ12herzK6ajopjbTdkg4qybADgyVBNtHSYA=.e797a479-6a13-410e-9048-05ece361ab00@github.com>
Message-ID: <4h1gFe61jooAJvXGnpIg1lEPIK2mStLaLXLhQok8_T8=.15f670d3-cf62-4c19-9df6-4173147ff186@github.com>

On Tue, 8 Dec 2020 16:27:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic noise because sometimes it opens more file handles than expected. It was moved to a manual test to quiesce this ([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))
>> 
>> It would be good, however, to have this test as an automatic test to be able to spot potential regressions. The threshold for windows should be adapted.
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 61:
> 
>> 59:         System.out.println("FDs in the end: " + fds_end);
>> 60: 
>> 61:         if ((fds_end - fds_start) > (NUM_TEST_SOCK / OPEN_HANDLE_GROWTH_THRESHOLD)) {
> 
> It looks like the test may still fail intermittently.  But let's do it for now and see if it is reliable to be an automation test case.

The failing cases I've seen in SAP's infrastructure have all been on Windows and the number of handles was marginally above the 10 percent threshold. Do you have seen otherwise in Oracle's tests? The test prints out the handle count before and after...

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

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

From xuelei at openjdk.java.net  Tue Dec  8 22:37:38 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Dec 2020 22:37:38 GMT
Subject: RFR: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
In-Reply-To: <4h1gFe61jooAJvXGnpIg1lEPIK2mStLaLXLhQok8_T8=.15f670d3-cf62-4c19-9df6-4173147ff186@github.com>
References: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
 <zMDakwtLQ12herzK6ajopjbTdkg4qybADgyVBNtHSYA=.e797a479-6a13-410e-9048-05ece361ab00@github.com>
 <4h1gFe61jooAJvXGnpIg1lEPIK2mStLaLXLhQok8_T8=.15f670d3-cf62-4c19-9df6-4173147ff186@github.com>
Message-ID: <xN1WQ9zeQgdaNsgKJodc-MQkShWAdLgqLbsqMyNsv8k=.79252f07-a821-4b26-a8cb-7d88e4449ec2@github.com>

On Tue, 8 Dec 2020 22:16:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 61:
>> 
>>> 59:         System.out.println("FDs in the end: " + fds_end);
>>> 60: 
>>> 61:         if ((fds_end - fds_start) > (NUM_TEST_SOCK / OPEN_HANDLE_GROWTH_THRESHOLD)) {
>> 
>> It looks like the test may still fail intermittently.  But let's do it for now and see if it is reliable to be an automation test case.
>
> The failing cases I've seen in SAP's infrastructure have all been on Windows and the number of handles was marginally above the 10 percent threshold. Do you have seen otherwise in Oracle's tests? The test prints out the handle count before and after...

The number may help for general cases, but intermittent failure could happen if the test could fail in theory.  I did not dig into Oracle testing result.

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

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

From clanger at openjdk.java.net  Wed Dec  9 08:12:33 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 9 Dec 2020 08:12:33 GMT
Subject: RFR: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
In-Reply-To: <xN1WQ9zeQgdaNsgKJodc-MQkShWAdLgqLbsqMyNsv8k=.79252f07-a821-4b26-a8cb-7d88e4449ec2@github.com>
References: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
 <zMDakwtLQ12herzK6ajopjbTdkg4qybADgyVBNtHSYA=.e797a479-6a13-410e-9048-05ece361ab00@github.com>
 <4h1gFe61jooAJvXGnpIg1lEPIK2mStLaLXLhQok8_T8=.15f670d3-cf62-4c19-9df6-4173147ff186@github.com>
 <xN1WQ9zeQgdaNsgKJodc-MQkShWAdLgqLbsqMyNsv8k=.79252f07-a821-4b26-a8cb-7d88e4449ec2@github.com>
Message-ID: <wqx9-jncZ_DlBwmbZYWuR81PicaJmzlF9JOqCouFbG8=.6e05a3d2-f83a-4a2f-a2bd-0595e62a948a@github.com>

On Tue, 8 Dec 2020 22:34:44 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The failing cases I've seen in SAP's infrastructure have all been on Windows and the number of handles was marginally above the 10 percent threshold. Do you have seen otherwise in Oracle's tests? The test prints out the handle count before and after...
>
> The number may help for general cases, but intermittent failure could happen if the test could fail in theory.  I did not dig into Oracle testing result.

As per Tony's [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8257670?focusedCommentId=14387025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14387025), the test issue was observed on Windows only also in Oracle and it indicates that the threshold of 10% is just missed by few - it would be 50 fds. So I'd hope we're good with this modification.

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

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

From clanger at openjdk.java.net  Wed Dec  9 08:16:35 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 9 Dec 2020 08:16:35 GMT
Subject: Integrated: 8257884: Re-enable
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
In-Reply-To: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
References: <yNc9F2pQG0z_3sSiWzsjNuXI0nfQiQDsjjGMP712Sb4=.685f2aaa-d279-4da6-8203-8dea665373f1@github.com>
Message-ID: <zkqLFsjAUAwVSueVxviTfYNziOFwJy0K3JUlJZ-WDOY=.40f5540b-0874-48ca-8417-d488357c64db@github.com>

On Tue, 8 Dec 2020 07:27:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic noise because sometimes it opens more file handles than expected. It was moved to a manual test to quiesce this ([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))
> 
> It would be good, however, to have this test as an automatic test to be able to spot potential regressions. The threshold for windows should be adapted.

This pull request has now been integrated.

Changeset: fae7961a
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fae7961a
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test

Reviewed-by: xuelei

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

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

From weijun at openjdk.java.net  Thu Dec 10 00:46:35 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Dec 2020 00:46:35 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <Afb0e1sUCYbYLxrSDp5uPPHBTqhH7PY3tzrdP5JSB9w=.0a7838a0-71c3-4ac5-aa64-7af685f2373e@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From clanger at openjdk.java.net  Thu Dec 10 08:38:43 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 10 Dec 2020 08:38:43 GMT
Subject: RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again
 reports leaks after JDK-8257884
Message-ID: <wNKkWqdexI8SNHy0-RgOi2Tp8Fuh-RYSsfj5rGYMhp4=.38cac156-8430-4c57-8b46-a49ef4029415@github.com>

The fix for [JDK-8257884](https://bugs.openjdk.java.net/browse/JDK-8257884) had a flaw which made the test fail even more often on Windows than before. Here is the correction.

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

Commit messages:
 - 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884

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

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

From mbaesken at openjdk.java.net  Thu Dec 10 10:51:35 2020
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 10 Dec 2020 10:51:35 GMT
Subject: RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java
 again reports leaks after JDK-8257884
In-Reply-To: <wNKkWqdexI8SNHy0-RgOi2Tp8Fuh-RYSsfj5rGYMhp4=.38cac156-8430-4c57-8b46-a49ef4029415@github.com>
References: <wNKkWqdexI8SNHy0-RgOi2Tp8Fuh-RYSsfj5rGYMhp4=.38cac156-8430-4c57-8b46-a49ef4029415@github.com>
Message-ID: <-FcPNoBGuVIdLfn55W7Ek-x2LULopHuerpAiCJfkGaM=.c257c691-5cbd-47b2-9d4d-721d28ba51df@github.com>

On Thu, 10 Dec 2020 08:34:31 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The fix for [JDK-8257884](https://bugs.openjdk.java.net/browse/JDK-8257884) had a flaw which made the test fail even more often on Windows than before. Here is the correction.

Marked as reviewed by mbaesken (Reviewer).

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

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

From clanger at openjdk.java.net  Thu Dec 10 10:59:34 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 10 Dec 2020 10:59:34 GMT
Subject: Integrated: 8257997:
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after
 JDK-8257884
In-Reply-To: <wNKkWqdexI8SNHy0-RgOi2Tp8Fuh-RYSsfj5rGYMhp4=.38cac156-8430-4c57-8b46-a49ef4029415@github.com>
References: <wNKkWqdexI8SNHy0-RgOi2Tp8Fuh-RYSsfj5rGYMhp4=.38cac156-8430-4c57-8b46-a49ef4029415@github.com>
Message-ID: <c2O-Dikg7xdHUzLqqsfbu1yvd6ZE4wOkTUvSs73OhZc=.ec743eb5-c9dc-47df-a7ef-2ffc775fd184@github.com>

On Thu, 10 Dec 2020 08:34:31 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The fix for [JDK-8257884](https://bugs.openjdk.java.net/browse/JDK-8257884) had a flaw which made the test fail even more often on Windows than before. Here is the correction.

This pull request has now been integrated.

Changeset: 29ffffa7
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29ffffa7
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884

Reviewed-by: mbaesken

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

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

From naoto at openjdk.java.net  Thu Dec 10 23:10:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Dec 2020 23:10:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

test/jdk/java/util/Locale/LSRDataTest.java line 57:

> 55:     // path to the lsr file from the make folder, this test relies on the
> 56:     // relative path to the file in the make folder, considering
> 57:     // test and make will always exist in the same jdk layout

The comment refers to the "make" folder. (line 55 as well).

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

Marked as reviewed by naoto (Reviewer).

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

From minqi at openjdk.java.net  Fri Dec 11 05:17:33 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 05:17:33 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <mBghLCvd_6OOPgNdUHyl6QGPV9V_C30p2ILwh4bwIac=.4c28be41-fc69-432a-aa39-5f2ccb9820fc@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Added test case; Fixed an nmt issue caused by bitmap region not released after archive loading failed; Unmap bitmap after archive failure. Fixed reserved region name for adding reserved region.
 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/29a09c89...0421943d

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

Changes: https://git.openjdk.java.net/jdk/pull/1657/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=04
  Stats: 8183 lines in 159 files changed: 4666 ins; 2763 del; 754 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:56 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:56 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
 <vtqmULMCnP8KBSPw6V_NFKvYVQzd9nAT9Y4V-N3j9Zs=.3c935956-78ef-491f-b209-eca535b8ca40@github.com>
 <sAqnH0sEch5UPQIwaz0vgcwVE9P_8WS-FSBmH7VU4IQ=.d6161796-38fa-4267-a62d-4dbb82689af4@github.com>
 <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
Message-ID: <gxcE4bVzUGSQ_clecIjrse_78xNKil4-urgXqWbJmhU=.cadaa2df-7141-45a0-8d2e-e0d15d36f00c@github.com>

On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
> Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks

This branch has many conflicts, something wrong since push-02, closed this PR and will send a single patch in new PR.

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

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:57 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:57 GMT
Subject: Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region"
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <9Hu8Jqsqm4gG7-yV0AZIZvnOh72CmunbbQhdT-LnjBA=.da14a187-fb1b-4190-9e4b-d06896ad7202@github.com>

On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

This pull request has been closed without being integrated.

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

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

From hchao at openjdk.java.net  Fri Dec 11 18:37:57 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 11 Dec 2020 18:37:57 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
Message-ID: <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>

On Tue, 8 Dec 2020 18:52:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Marked as reviewed by xuelei (Reviewer).
>
> This will also require a CSR since you are making some specification changes. I'm not sure if you were trying to get this into 16, but it is probably too late to make JDK 16 since RDP is a couple of days away. You can push to 17/latest once 16 forks and CSR is approved.

Please review the CSR (JDK-8258114) at:
https://bugs.openjdk.java.net/browse/JDK-8258114

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

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

From herrick at openjdk.java.net  Fri Dec 11 18:43:55 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 11 Dec 2020 18:43:55 GMT
Subject: Withdrawn: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618
In-Reply-To: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
Message-ID: <zvIFwgHB8DT-0za_g0T9Xn1U-7cYNuLgiPn_E9snb-Y=.79e4391c-1b4c-4cfd-8757-4649726edc17@github.com>

On Mon, 7 Dec 2020 20:29:56 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> increase retries and timeout increasing in runMsiexecWithRetries

This pull request has been closed without being integrated.

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

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

From jamil.j.nimeh at oracle.com  Fri Dec 11 19:01:33 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 11 Dec 2020 11:01:33 -0800
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
 <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
Message-ID: <a67d1afa-4636-343f-34e1-8fabdc8c36ea@oracle.com>

Some minor comments:

  * General
      o I think you can backtick the UnsupportedOperationException text
        so it shows up in monospace format.
  * Specification
      o I think text-wise the wording is fine.? IIRC don't we normally
        show the proposed changes as a diff?? Or is that just one
        acceptable format and what's done here is fine too? Either way
        the intent is clearly communicated, IMO.

I'll put myself down as a reviewer.

--Jamil

On 12/11/2020 10:37 AM, Hai-May Chao wrote:
> On Tue, 8 Dec 2020 18:52:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:
>
>>> Marked as reviewed by xuelei (Reviewer).
>> This will also require a CSR since you are making some specification changes. I'm not sure if you were trying to get this into 16, but it is probably too late to make JDK 16 since RDP is a couple of days away. You can push to 17/latest once 16 forks and CSR is approved.
> Please review the CSR (JDK-8258114) at:
> https://bugs.openjdk.java.net/browse/JDK-8258114
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201211/562f1ab6/attachment.htm>

From hchao at openjdk.java.net  Fri Dec 11 19:45:55 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 11 Dec 2020 19:45:55 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
 <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
Message-ID: <u1VN9s_tKZTYJoSOhKjyJS17-g1hlupiNOcsH6w4Uww=.1f7918e4-4c77-4949-85b2-d2e13a56f075@github.com>

On Fri, 11 Dec 2020 18:35:27 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This will also require a CSR since you are making some specification changes. I'm not sure if you were trying to get this into 16, but it is probably too late to make JDK 16 since RDP is a couple of days away. You can push to 17/latest once 16 forks and CSR is approved.
>
> Please review the CSR (JDK-8258114) at:
> https://bugs.openjdk.java.net/browse/JDK-8258114

Thanks for the review. Updated CSR to backtick the UnsupportedOperationException text. I thought about placing the diff in Specification section, but decided to keep the document change in this format which is same as our javadoc API specification. I thought it'd be more clear. I'm open to make a change if diff format is required.

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

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

From xuelei at openjdk.java.net  Fri Dec 11 20:01:56 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 11 Dec 2020 20:01:56 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <u1VN9s_tKZTYJoSOhKjyJS17-g1hlupiNOcsH6w4Uww=.1f7918e4-4c77-4949-85b2-d2e13a56f075@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
 <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
 <u1VN9s_tKZTYJoSOhKjyJS17-g1hlupiNOcsH6w4Uww=.1f7918e4-4c77-4949-85b2-d2e13a56f075@github.com>
Message-ID: <9SgFWWpBlr4P5RPKsQUDfKFTCJMCKiN_fh73nKvQt_Y=.b0dc4ea1-bfb5-48cf-b245-145b11d96c81@github.com>

On Fri, 11 Dec 2020 19:43:41 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Please review the CSR (JDK-8258114) at:
>> https://bugs.openjdk.java.net/browse/JDK-8258114
>
> Thanks for the review. Updated CSR to backtick the UnsupportedOperationException text. I thought about placing the diff in Specification section, but decided to keep the document change in this format which is same as our javadoc API specification. I thought it'd be more clear. I'm open to make a change if diff format is required.

It may improve the readability to have the context specification of the update.  For example, have the full specification of the method, and mark the update of the spec, and the signature of the method.  A diff is often used as it is easier to have the context in the CSR request.

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

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

From jamil.j.nimeh at oracle.com  Fri Dec 11 20:03:54 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 11 Dec 2020 12:03:54 -0800
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <u1VN9s_tKZTYJoSOhKjyJS17-g1hlupiNOcsH6w4Uww=.1f7918e4-4c77-4949-85b2-d2e13a56f075@github.com>
Message-ID: <202012112004.0BBK41cK016055@userv0121.oracle.com>

No need to change it IMO.? I'm fine with it as is.--Jamil
-------- Original message --------From: Hai-May Chao <hchao at openjdk.java.net> Date: 12/11/20  11:45 AM  (GMT-08:00) To: security-dev at openjdk.java.net Subject: Re: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec mismatch to its behavior [v2] On Fri, 11 Dec 2020 18:35:27 GMT, Hai-May Chao <hchao at openjdk.org> wrote:>> This will also require a CSR since you are making some specification changes. I'm not sure if you were trying to get this into 16, but it is probably too late to make JDK 16 since RDP is a couple of days away. You can push to 17/latest once 16 forks and CSR is approved.>> Please review the CSR (JDK-8258114) at:> https://bugs.openjdk.java.net/browse/JDK-8258114Thanks for the review. Updated CSR to backtick the UnsupportedOperationException text. I thought about placing the diff in Specification section, but decided to keep the document change in this format which is same as our javadoc API specification. I thought it'd be more clear. I'm open to make a change if diff format is required.-------------PR: https://git.openjdk.java.net/jdk/pull/1701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201211/1f07d94b/attachment-0001.htm>

From hchao at openjdk.java.net  Fri Dec 11 21:45:57 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 11 Dec 2020 21:45:57 GMT
Subject: RFR: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec
 mismatch to its behavior [v2]
In-Reply-To: <9SgFWWpBlr4P5RPKsQUDfKFTCJMCKiN_fh73nKvQt_Y=.b0dc4ea1-bfb5-48cf-b245-145b11d96c81@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
 <IIFPF69Whb9G4_gVYIgdDvFdcgYNwE4mY2PrdV3dSkY=.88ee35b8-a29c-450a-beea-98b99ffe33e1@github.com>
 <LJMTDOImT4VAA-hej8w7IEmmF7U1UIkkWTiVJDIkTKc=.33b320c3-300e-4ecf-b4d5-bf9e78afb238@github.com>
 <U1b_CzGjb-azCxWFjyeoHbXTcT3bWHbZKHfAw8SkskI=.9956c5b0-0e04-4aa5-971b-a315127aea3f@github.com>
 <IjgglQzoV50udvyBf23vfNzLpxdLCPL9papPIK7i3yM=.7427acb9-1aaa-4fd5-8b23-f056a999d86e@github.com>
 <u1VN9s_tKZTYJoSOhKjyJS17-g1hlupiNOcsH6w4Uww=.1f7918e4-4c77-4949-85b2-d2e13a56f075@github.com>
 <9SgFWWpBlr4P5RPKsQUDfKFTCJMCKiN_fh73nKvQt_Y=.b0dc4ea1-bfb5-48cf-b245-145b11d96c81@github.com>
Message-ID: <LZpS-iRo9K4BXhQRcwPYATzgrqFSxQSc4ifsJ1bmvhM=.712bb1e8-a3d0-416a-9080-04a64fc81ed2@github.com>

On Fri, 11 Dec 2020 19:59:17 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Thanks for the review. Updated CSR to backtick the UnsupportedOperationException text. I thought about placing the diff in Specification section, but decided to keep the document change in this format which is same as our javadoc API specification. I thought it'd be more clear. I'm open to make a change if diff format is required.
>
> It may improve the readability to have the context specification of the update.  For example, have the full specification of the method, and mark the update of the spec, and the signature of the method.  A diff is often used as it is easier to have the context in the CSR request.

Thanks for the CSR review. Updated CSR to have diff on the full spec of the methods.

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

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

From xuelei at openjdk.java.net  Fri Dec 11 23:28:10 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 11 Dec 2020 23:28:10 GMT
Subject: RFR: 8217633: Configurable extensions with system properties
Message-ID: <b8NKhRjwTDexsi8ChJ1TqEFuO6waUFDZAdzOXnl1gMU=.4642774d-c1fb-4609-8f4c-8864a3ceb654@github.com>

The TLS protocols are designed to tolerant unknown TLS extensions. However, although it is not common, there are a few TLS implementations that cannot handle unknown extensions properly. As results in unexpected interoperability issue when new extensions are introduced in JDK. The interoperability impact could be mitigated If applications can customize the extensions if needed.

With this update, two system properties are added to configure the default extensions in either client or server side of TLS connections.  Please note that the impact of blocking TLS extensions is complicated.  For example, a TLS connection may not be able to established if a mandatory extension is blocked.  Please don't use this feature unless you clearly understand the impact.

Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
CSR: https://bugs.openjdk.java.net/browse/JDK-8217993

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

Commit messages:
 - Remove swp file
 - Add regression test
 - 8217633: Configurable extensions with system properties

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

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

From weijun at openjdk.java.net  Sat Dec 12 02:49:58 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 12 Dec 2020 02:49:58 GMT
Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version
 2.2.0
In-Reply-To: <snVS3gqhEzG3ACQNnb5hKmnFz619kAEV9IdDxMGCsVU=.31e25521-7753-4b96-8d97-518eb22545e4@github.com>
References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com>
 <snVS3gqhEzG3ACQNnb5hKmnFz619kAEV9IdDxMGCsVU=.31e25521-7753-4b96-8d97-518eb22545e4@github.com>
Message-ID: <ko5Mt9uw3aFlCcm8MLTIlCx91vJasBNbl6yxltDz9Fg=.ef25f95f-091e-4c6a-88ac-5b1c440a7bb2@github.com>

On Fri, 13 Nov 2020 22:00:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0.
>> 
>> The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces.
>> 
>> Next steps are patches applied by JDK. Some are old patches before the last import. Some are new.
>> 
>> Several tests need to be updated because of internal method signature changes.
>> 
>> The "Support RSA-PSS with parameters" commit introduces a new public API and would need a CSR.
>> 
>> The last patch is one we just fixed several days ago.
>
> The "Support RSA-PSS with parameters" commit is rewritten. Now a `PSSParameterSpec` object is encapsulated inside a `RSAPSSParameterSpec`.
> 
> Note: https://tools.ietf.org/html/rfc6931#section-2.3.9 define the algorithm name as RSASSA-PSS with URI fragment `#rsa-pss` (no SSA). So in comments I always use the long name but the `SignatureMethod` constant is named `RSA_PSS`. Hopefully this is fine.

> @wangweij This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Sure.

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

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

From jnimeh at openjdk.java.net  Sun Dec 13 19:24:02 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Sun, 13 Dec 2020 19:24:02 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls
Message-ID: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>

This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.

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

Commit messages:
 - Merge
 - 8179503: Java should support GET OCSP calls

Changes: https://git.openjdk.java.net/jdk/pull/1760/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1760&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8179503
  Stats: 358 lines in 3 files changed: 301 ins; 23 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1760/head:pull/1760

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

From mcimadamore at openjdk.java.net  Mon Dec 14 14:51:07 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 14 Dec 2020 14:51:07 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used
Message-ID: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>

This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.

In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.

To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).

Here are some numbers before the patch:

Benchmark                                            Mode  Cnt   Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op

As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:

Benchmark                                            Mode  Cnt  Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op

That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!

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

Commit messages:
 - * Add argument type profiling to MemoryAccess

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From vlivanov at openjdk.java.net  Mon Dec 14 15:43:56 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Dec 2020 15:43:56 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used
In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
Message-ID: <VwnacKhjTm48lzogXuC_T_ssUIYbuXPC5HNKfLjjgCs=.77a4fd5f-41ca-4c1c-a608-c81a0c572009@github.com>

On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
> 
> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
> 
> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
> 
> Here are some numbers before the patch:
> 
> Benchmark                                            Mode  Cnt   Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
> 
> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
> 
> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/19

From redestad at openjdk.java.net  Mon Dec 14 15:51:00 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 14 Dec 2020 15:51:00 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used
In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
Message-ID: <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com>

On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
> 
> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
> 
> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
> 
> Here are some numbers before the patch:
> 
> Benchmark                                            Mode  Cnt   Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
> 
> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
> 
> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!

src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 32:

> 30: 
> 31: /**
> 32:  * This proxy interface is required to allow instances of the {@code MemorySegment} interface (which is defined inside

"This abstract base class.."? 

I don't mind the current name, but should the class be renamed `AbstractMemorySegmentProxy`?

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From mcimadamore at openjdk.java.net  Mon Dec 14 17:17:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 14 Dec 2020 17:17:00 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used
In-Reply-To: <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
 <34cCfmLZjUH77gP1Hk0Fd-KT2vqZ5Ox1W08qeMmgjlM=.4e226bce-7f59-41dd-a64f-91be94568514@github.com>
Message-ID: <CTzgaaAN-RTBtnXA69VnDq0B5LdbOKa8G90BjdIXQHo=.e51fe109-5bb5-4d61-81d4-da70a9f6d9e2@github.com>

On Mon, 14 Dec 2020 15:48:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
>> 
>> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
>> 
>> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
>> 
>> Here are some numbers before the patch:
>> 
>> Benchmark                                            Mode  Cnt   Score   Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
>> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
>> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
>> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
>> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
>> 
>> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
>> 
>> Benchmark                                            Mode  Cnt  Score   Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
>> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
>> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
>> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
>> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
>> 
>> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!
>
> src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 32:
> 
>> 30: 
>> 31: /**
>> 32:  * This proxy interface is required to allow instances of the {@code MemorySegment} interface (which is defined inside
> 
> "This abstract base class.."? 
> 
> I don't mind the current name, but should the class be renamed `AbstractMemorySegmentProxy`?

I'll fix the doc - since this is a transitional artifact (will disappear when API is finalized an in java.base) I'd prefer to avoid the renaming

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From xuelei at openjdk.java.net  Mon Dec 14 18:01:00 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 14 Dec 2020 18:01:00 GMT
Subject: RFR: 8253368: TLS connection always receives close_notify
 exception
In-Reply-To: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
Message-ID: <35gyKMakIcdfOEna9DuqW_CGIutA5AsKvidrt4CmVhE=.f15cc6ab-1244-42dc-bbbb-c5fbc8c7ac20@github.com>

On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.

src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 820:

> 818:                     "closing inbound before receiving peer's close_notify");
> 819:         }
> 820: 

I am a little bit hesitate to close the inbound silently, especially when it is a layered socket and the write side does not stop write yet.  The shutdownInput() is used to Unsupported UnsupportedOperationException, and allowed to throw IOException.  I think application may be able to handle it properly already.

Instead, maybe we could put the block (line 821-824) in a finalize block so that the input get closed before throwing this exception.

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

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

From mcimadamore at openjdk.java.net  Mon Dec 14 18:07:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 14 Dec 2020 18:07:14 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used [v2]
In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
Message-ID: <z0A9U3JZ9R7UOr_mYZTBVVJRLpG3lPXusNtDeKGhKHU=.5c945c1d-558f-45ac-b62c-8e17f0b8d398@github.com>

> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
> 
> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
> 
> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
> 
> Here are some numbers before the patch:
> 
> Benchmark                                            Mode  Cnt   Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
> 
> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
> 
> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!

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

  Fix javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/19/files
  - new: https://git.openjdk.java.net/jdk16/pull/19/files/324d5b92..81472e6d

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

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From redestad at openjdk.java.net  Mon Dec 14 18:14:00 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 14 Dec 2020 18:14:00 GMT
Subject: [jdk16] RFR: 8258242: Type profile pollution occurs when memory
 segments of different kinds are used [v2]
In-Reply-To: <z0A9U3JZ9R7UOr_mYZTBVVJRLpG3lPXusNtDeKGhKHU=.5c945c1d-558f-45ac-b62c-8e17f0b8d398@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
 <z0A9U3JZ9R7UOr_mYZTBVVJRLpG3lPXusNtDeKGhKHU=.5c945c1d-558f-45ac-b62c-8e17f0b8d398@github.com>
Message-ID: <vZQwg5-qc5oC0kLd_-qXAk-rzR6--sJhNEoSD6GtfKk=.a50b9d19-9a00-4f95-b354-ca6fc1eb38a2@github.com>

On Mon, 14 Dec 2020 18:07:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
>> 
>> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
>> 
>> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
>> 
>> Here are some numbers before the patch:
>> 
>> Benchmark                                            Mode  Cnt   Score   Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
>> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
>> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
>> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
>> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
>> 
>> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
>> 
>> Benchmark                                            Mode  Cnt  Score   Error  Units
>> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
>> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
>> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
>> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
>> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
>> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
>> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
>> 
>> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From mcimadamore at openjdk.java.net  Tue Dec 15 13:54:03 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 15 Dec 2020 13:54:03 GMT
Subject: [jdk16] Integrated: 8258242: Type profile pollution occurs when
 memory segments of different kinds are used
In-Reply-To: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
References: <2nFyZPy1b_Vl4uZBODu1Eem_CsHjFG-X3CDlNmojpng=.41c944d0-b26e-4a45-9551-564d4a1eec36@github.com>
Message-ID: <qIvODpPn0J7Dl_0g6PLI68YaasuOjrw1OUVBKisdTdM=.0191a603-b8fc-4dff-bd63-f5bd373211c6@github.com>

On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same `MemoryAccess` static method.
> 
> In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the `MemorySegmentProxy` internal interface. This creates problems for C2, as concrete segment implementations have _two_ interface types: `MemorySegment` and the internal `MemorySegmentProxy` class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.
> 
> To solve this problem we realized, in hindisght, that `MemorySegmentProxy` didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in `MemoryAccess` class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for `ScopedMemoryAccess`).
> 
> Here are some numbers before the patch:
> 
> Benchmark                                            Mode  Cnt   Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op
> 
> As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
> LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
> LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
> LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
> LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
> LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
> LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
> LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op
> 
> That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!

This pull request has now been integrated.

Changeset: 7ff9c856
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/7ff9c856
Stats:     225 lines in 8 files changed: 215 ins; 0 del; 10 mod

8258242: Type profile pollution occurs when memory segments of different kinds are used

Reviewed-by: vlivanov, redestad

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

PR: https://git.openjdk.java.net/jdk16/pull/19

From jeetendranalawade at gmail.com  Tue Dec 15 09:48:33 2020
From: jeetendranalawade at gmail.com (Jeetendra Nalawade)
Date: Tue, 15 Dec 2020 15:18:33 +0530
Subject: FIPS support for JCE/JSSE
In-Reply-To: <CALr+c30xrCA+SRcq6-aA9POJxsg+Geg1BBS_c+0yCntuUzN5Gw@mail.gmail.com>
References: <CALr+c30xrCA+SRcq6-aA9POJxsg+Geg1BBS_c+0yCntuUzN5Gw@mail.gmail.com>
Message-ID: <CALr+c31L6EwSHSGzSbXBdzhLCi93614hksC2dtf8cA5nqjvHMg@mail.gmail.com>

Hi All,

Based on the search I did so far, looks like openJDK out of box, does not
provide FIPS compliant security providers and to enable FIPS support, we
need to use third party crypto libraries. If this assumption is correct,
can I use IBM security provider like IBMJCEFIPS & IBMJSSE2 with OpenJDK?
Rather any other FIPS compilant libraries like NSS etc.

This is gating for the move to OpenJDK and your inputs appreciated.

Regards
Jeetendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201215/824e2d23/attachment.htm>

From weijun at openjdk.java.net  Tue Dec 15 19:21:06 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Dec 2020 19:21:06 GMT
Subject: [jdk16] RFR: 8258419: RSA cipher buffer cleanup
Message-ID: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>

Some array allocation is not necessary, and the content can be cleaned.

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

Commit messages:
 - 8258419: RSA cipher buffer cleanup

Changes: https://git.openjdk.java.net/jdk16/pull/26/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=26&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258419
  Stats: 89 lines in 3 files changed: 34 ins; 17 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/26.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/26/head:pull/26

PR: https://git.openjdk.java.net/jdk16/pull/26

From valeriep at openjdk.java.net  Tue Dec 15 20:33:57 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 15 Dec 2020 20:33:57 GMT
Subject: [jdk16] RFR: 8258419: RSA cipher buffer cleanup
In-Reply-To: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
References: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
Message-ID: <WlJp6uY-Zh5c7CAyxlW5_xk6z-Yjq4k_-Xao_X3LQ1Y=.d5057efb-4810-4887-8c6c-f90f25c1767d@github.com>

On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Some array allocation is not necessary, and the content can be cleaned.

Need a noreg-xxx label since there is no regression test.

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

PR: https://git.openjdk.java.net/jdk16/pull/26

From valeriep at openjdk.java.net  Tue Dec 15 20:35:06 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 15 Dec 2020 20:35:06 GMT
Subject: RFR: 8023980: JCE doesn't provide any class to handle RSA private key
 in PKCS#1
Message-ID: <LBLCnY5uLti_uiMi40_7rbE4kp9vIGb2R_D68Y1KeDs=.ebcb4b01-873a-49ca-bc2b-d38717936e40@github.com>

Can someone help review this?

This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 providers to accept RSA keys in PKCS#1 format and encoding and translate them to provider-specific RSA keys. Updated the relevant tests with a sample PKCS#1 encoded key pair.

Thanks,
Valerie

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

Commit messages:
 - 8023980: JCE doesn't provide any class to handle RSA private key in PKCS #1

Changes: https://git.openjdk.java.net/jdk/pull/1787/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1787&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8023980
  Stats: 458 lines in 6 files changed: 302 ins; 55 del; 101 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1787/head:pull/1787

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

From weijun at openjdk.java.net  Tue Dec 15 20:39:01 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Dec 2020 20:39:01 GMT
Subject: [jdk16] RFR: 8258419: RSA cipher buffer cleanup
In-Reply-To: <WlJp6uY-Zh5c7CAyxlW5_xk6z-Yjq4k_-Xao_X3LQ1Y=.d5057efb-4810-4887-8c6c-f90f25c1767d@github.com>
References: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
 <WlJp6uY-Zh5c7CAyxlW5_xk6z-Yjq4k_-Xao_X3LQ1Y=.d5057efb-4810-4887-8c6c-f90f25c1767d@github.com>
Message-ID: <KGtWKVJqwZVHDYBBV8p4_7l0DwYh2hWsOWMM5jI902E=.cf510c8b-e869-4f41-8d08-ab22ba461d5c@github.com>

On Tue, 15 Dec 2020 20:31:28 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Need a noreg-xxx label since there is no regression test.

`noreg-cleanup` Added. Thanks.

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

PR: https://git.openjdk.java.net/jdk16/pull/26

From valeriep at openjdk.java.net  Tue Dec 15 20:44:56 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 15 Dec 2020 20:44:56 GMT
Subject: [jdk16] RFR: 8258419: RSA cipher buffer cleanup
In-Reply-To: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
References: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
Message-ID: <euIcoUtKeVnpc_g55DeC2BQvmk9k4f0LPUGWhtnloLc=.70049f8a-455b-46ac-9128-6a7f8f58e82b@github.com>

On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Some array allocation is not necessary, and the content can be cleaned.

Looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/26

From ihse at openjdk.java.net  Tue Dec 15 22:40:53 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:40:53 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v3]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <ZQKkeZnC0DkuVXm10pUBOC7eHbUSXleDRyOTUHMrW5k=.07290ec9-fd83-46bc-81bb-3b6423327507@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [ ] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [ ] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move macosxicons from share to macosx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/f0047704..00dc61c1

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

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

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

From weijun at openjdk.java.net  Tue Dec 15 22:53:01 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Dec 2020 22:53:01 GMT
Subject: [jdk16] Integrated: 8258419: RSA cipher buffer cleanup
In-Reply-To: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
References: <vxM7qafvycR0aM5OuAjg9yF_zv_Yipcn11Mpnqz--Bk=.b7529504-12df-40ee-85e8-d2c7e0a34581@github.com>
Message-ID: <SXw4Z49ydKUGr0-jiLu6XNGkHKxLYJI1ltblXdZ0WYU=.d420ab06-0b62-46d9-b775-bbb185dcec98@github.com>

On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Some array allocation is not necessary, and the content can be cleaned.

This pull request has now been integrated.

Changeset: b97fe6c4
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/b97fe6c4
Stats:     89 lines in 3 files changed: 34 ins; 17 del; 38 mod

8258419: RSA cipher buffer cleanup

Reviewed-by: valeriep

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

PR: https://git.openjdk.java.net/jdk16/pull/26

From ihse at openjdk.java.net  Tue Dec 15 22:56:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie 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:

 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/00dc61c1..68b252b5

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

  Stats: 38451 lines in 948 files changed: 28535 ins; 6611 del; 3305 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

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

From ihse at openjdk.java.net  Tue Dec 15 22:56:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:16 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

> test/jdk/java/util/Locale/LSRDataTest.java line 57:
> 
>> 55:     // path to the lsr file from the make folder, this test relies on the
>> 56:     // relative path to the file in the make folder, considering
>> 57:     // test and make will always exist in the same jdk layout
> 
> The comment refers to the "make" folder. (line 55 as well).

Fixed. Thank you for noticing!

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

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

From alanb at openjdk.java.net  Wed Dec 16 10:15:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 10:15:56 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
Message-ID: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>

On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.
>
> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

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

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

From ihse at openjdk.java.net  Wed Dec 16 14:02:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 14:02:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
 <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
Message-ID: <F1TBC8SJ4UagUp3gvVlBcWOmsIHsG6yqbF9-PUFI2mQ=.7ef21145-157f-4871-8045-979284284dce@github.com>

On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?
>
> I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

@AlanBateman Let me re-iterate: the data files are *not* "make" files. It is just as annoying to have team-specific data files in the make tree! So to keep things as they are is not an option. The fact that they currently reside there is just a continuation of the old view of make as a general dumping ground. I've requested this change since before Project Jigsaw. In fact, I opposed Erik's original Jigsaw patch on this ground, among other things. As a compromise, we agreed that it was to be fixed *after* Jigsaw, since that project had already dragged out in time for so long and was blocking the release. (See https://bugs.openjdk.java.net/browse/JDK-8055193 for details.)

So what do you propose for alternative? A new top-level data directory? I mean, sure, we could have like `data/java.base/share/charsetmapping` instead. I personally think that makes less sense. I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

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

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

From xuelei at openjdk.java.net  Wed Dec 16 17:18:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 16 Dec 2020 17:18:03 GMT
Subject: RFR: 8258514: Replace Collections.unmodifiableList with List.of
Message-ID: <ZJYtxHy3GrIRO0CGaOqGeHzsfRvS9JKOjqv2buFxVS8=.25dba230-179a-4c1a-8435-946bff482451@github.com>

The Collections.unmodifiableList() method could be recurring copy on itself and have potential problems. The List.of() method is solid, and could be used instead.

Code cleanup, no new regression text.

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

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

Commit messages:
 - 8258514: Replace Collections.unmodifiableList with List.of

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

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

From jnimeh at openjdk.java.net  Wed Dec 16 17:40:56 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 16 Dec 2020 17:40:56 GMT
Subject: RFR: 8258514: Replace Collections.unmodifiableList with List.of
In-Reply-To: <ZJYtxHy3GrIRO0CGaOqGeHzsfRvS9JKOjqv2buFxVS8=.25dba230-179a-4c1a-8435-946bff482451@github.com>
References: <ZJYtxHy3GrIRO0CGaOqGeHzsfRvS9JKOjqv2buFxVS8=.25dba230-179a-4c1a-8435-946bff482451@github.com>
Message-ID: <NGwpSPvXxAonvW9LTxxq1dCUbVlFoFRmDfYnB4PSRvw=.099132b6-0dbf-4d3d-aca7-3a9b71bceaa0@github.com>

On Wed, 16 Dec 2020 17:13:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The Collections.unmodifiableList() method could be recurring copy on itself and have potential problems. The List.of() method is solid, and could be used instead.
> 
> Code cleanup, no new regression text.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258514

Looks fine to me.

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

Marked as reviewed by jnimeh (Reviewer).

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

From naoto at openjdk.java.net  Wed Dec 16 18:37:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Dec 2020 18:37:00 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this.

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

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

From xuelei at openjdk.java.net  Wed Dec 16 19:45:00 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 16 Dec 2020 19:45:00 GMT
Subject: Integrated: 8258514: Replace Collections.unmodifiableList with List.of
In-Reply-To: <ZJYtxHy3GrIRO0CGaOqGeHzsfRvS9JKOjqv2buFxVS8=.25dba230-179a-4c1a-8435-946bff482451@github.com>
References: <ZJYtxHy3GrIRO0CGaOqGeHzsfRvS9JKOjqv2buFxVS8=.25dba230-179a-4c1a-8435-946bff482451@github.com>
Message-ID: <TlTcavXdmgM0Rnuuo1l313PmDU-Z00Ur5cGqgXpRL58=.964aaa77-3661-4d0b-8d77-c0baa081bcfa@github.com>

On Wed, 16 Dec 2020 17:13:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The Collections.unmodifiableList() method could be recurring copy on itself and have potential problems. The List.of() method is solid, and could be used instead.
> 
> Code cleanup, no new regression text.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258514

This pull request has now been integrated.

Changeset: efd61c6f
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/efd61c6f
Stats:     6 lines in 3 files changed: 0 ins; 3 del; 3 mod

8258514: Replace Collections.unmodifiableList with List.of

Reviewed-by: jnimeh

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

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

From jwilhelm at openjdk.java.net  Thu Dec 17 02:59:10 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 02:59:10 GMT
Subject: RFR: Merge jdk16
Message-ID: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>

Merge JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8258338: Support deprecated records
 - 8241353: NPE in ToolProvider.getSystemJavaCompiler
 - 8255880: UI of Swing components is not redrawn after their internal state changed
 - 8257637: Update usage of "type" terminology in java.lang.annotation
 - 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive
 - 8258419: RSA cipher buffer cleanup
 - 8258380: [JVMCI] don't clear InstalledCode reference when unloading JVMCI nmethods
 - 8258427: Problem List some tests related to FileDialog for MacOS
 - 8258140: Update @jls tags in java.base for renamed/renumbered sections
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b2f03554...951fc9c0

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

Changes: https://git.openjdk.java.net/jdk/pull/1812/files
  Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1812/head:pull/1812

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

From jwilhelm at openjdk.java.net  Thu Dec 17 03:08:57 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 03:08:57 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>
References: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>
Message-ID: <6qEv2eY0O11uVLbYwNrAVT7U4LFVK5INiyqa2hByAyQ=.5b8cb7e1-d127-487a-91fc-a1a65e4786b3@github.com>

On Thu, 17 Dec 2020 02:48:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Merge JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 11bd7a81
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11bd7a81
Stats:     882 lines in 41 files changed: 659 ins; 30 del; 193 mod

Merge

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

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

From hchao at openjdk.java.net  Thu Dec 17 20:13:56 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 17 Dec 2020 20:13:56 GMT
Subject: Integrated: 8246005: KeyStoreSpi::engineStore(LoadStoreParameter)
 spec mismatch to its behavior
In-Reply-To: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
References: <l1w0T0E0Sl-dWQRp3XDlRQH3vcNMqGm61-ZrmimuXFY=.12a930c2-b668-4dc5-8b1f-658c6d90bd61@github.com>
Message-ID: <mDFNCulFsA3hJ8FKr1E25l_tOHuIW5Sx0gZlMvofrP0=.4326320d-76d8-4a52-ad13-eeb6ab750812@github.com>

On Tue, 8 Dec 2020 17:52:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This is a spec change with noreg-doc label.

This pull request has now been integrated.

Changeset: b0b70df4
Author:    Hai-May Chao <hchao at openjdk.org>
Committer: Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0b70df4
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec mismatch to its behavior

Reviewed-by: xuelei

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

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

From rhalade at openjdk.java.net  Thu Dec 17 20:16:04 2020
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 17 Dec 2020 20:16:04 GMT
Subject: RFR: 8225072,
 8258630: Add expiry exception for LuxTrust and QuoVadis root
 certificates
Message-ID: <ga0FgDvS8Dhh3i1zZvep4bst-cY8782dhXvwbZLAlr4=.df3082e3-37dc-4fc3-a1a1-f9f08d0e0e42@github.com>

? certificates

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

Commit messages:
 - 8225072, 8258630: Add expiry exception for LuxTrust and QuoVadis root certificates

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

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

From ascarpino at openjdk.java.net  Thu Dec 17 20:30:54 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 17 Dec 2020 20:30:54 GMT
Subject: RFR: 8225072: Add LuxTrust certificate that is expiring in March
 2021 to list of allowed but expired certs
In-Reply-To: <ga0FgDvS8Dhh3i1zZvep4bst-cY8782dhXvwbZLAlr4=.df3082e3-37dc-4fc3-a1a1-f9f08d0e0e42@github.com>
References: <ga0FgDvS8Dhh3i1zZvep4bst-cY8782dhXvwbZLAlr4=.df3082e3-37dc-4fc3-a1a1-f9f08d0e0e42@github.com>
Message-ID: <Cs0X4LgD3slRuVBArtrxKKR-Q3n1o4lDRtD18GD2fGA=.94c0fcd8-9c60-488b-b89a-7f8fb26ff1a6@github.com>

On Thu, 17 Dec 2020 20:11:47 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> ? certificates

Marked as reviewed by ascarpino (Reviewer).

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

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

From rhalade at openjdk.java.net  Thu Dec 17 20:30:55 2020
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 17 Dec 2020 20:30:55 GMT
Subject: Integrated: 8225072: Add LuxTrust certificate that is expiring in
 March 2021 to list of allowed but expired certs
In-Reply-To: <ga0FgDvS8Dhh3i1zZvep4bst-cY8782dhXvwbZLAlr4=.df3082e3-37dc-4fc3-a1a1-f9f08d0e0e42@github.com>
References: <ga0FgDvS8Dhh3i1zZvep4bst-cY8782dhXvwbZLAlr4=.df3082e3-37dc-4fc3-a1a1-f9f08d0e0e42@github.com>
Message-ID: <aCWA_tW2bsKOdUvfnDLjeIO5gsc4bb-UJYo4SUzUPvw=.7a90f353-1cd2-4953-b41e-db507b24604c@github.com>

On Thu, 17 Dec 2020 20:11:47 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> ? certificates

This pull request has now been integrated.

Changeset: 666e6c40
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/666e6c40
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs
8258630: Add expiry exception for QuoVadis root certificate

Reviewed-by: ascarpino

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

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

From rriggs at openjdk.java.net  Thu Dec 17 20:51:05 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 17 Dec 2020 20:51:05 GMT
Subject: RFR: 8250255: Use java.util.HexFormat in java.security
Message-ID: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>

The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes.

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

Commit messages:
 - 8250255: Use java.util.HexFormat in java.security

Changes: https://git.openjdk.java.net/jdk/pull/1828/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1828&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250255
  Stats: 247 lines in 14 files changed: 13 ins; 183 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1828.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1828/head:pull/1828

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

From rriggs at openjdk.java.net  Thu Dec 17 21:03:13 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 17 Dec 2020 21:03:13 GMT
Subject: RFR: 8252055: Use java.util.HexFormat in java.security [v2]
In-Reply-To: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>
References: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>
Message-ID: <SO41DpykI5t-T6ATspAF34HTR-JYWIyP87j079GMMBU=.54c56048-96c6-423f-ad3b-abf53d0119bd@github.com>

> The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes.

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

  Update copyrights to 2020

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1828/files
  - new: https://git.openjdk.java.net/jdk/pull/1828/files/40888c41..7c125a88

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

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1828.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1828/head:pull/1828

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

From xuelei at openjdk.java.net  Thu Dec 17 21:20:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 17 Dec 2020 21:20:58 GMT
Subject: RFR: 8252055: Use java.util.HexFormat in java.security [v2]
In-Reply-To: <SO41DpykI5t-T6ATspAF34HTR-JYWIyP87j079GMMBU=.54c56048-96c6-423f-ad3b-abf53d0119bd@github.com>
References: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>
 <SO41DpykI5t-T6ATspAF34HTR-JYWIyP87j079GMMBU=.54c56048-96c6-423f-ad3b-abf53d0119bd@github.com>
Message-ID: <B5QiU2M4vvl-1nK6YWxUbCfCoEIgZmOWGvC8HSA7N_U=.9653e93b-c24f-4b7b-b452-b4532a969f88@github.com>

On Thu, 17 Dec 2020 21:03:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights to 2020

Looks good to me.  Thanks for the update.

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

Marked as reviewed by xuelei (Reviewer).

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

From rhalade at openjdk.java.net  Thu Dec 17 22:06:01 2020
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 17 Dec 2020 22:06:01 GMT
Subject: [jdk16] RFR: 8225072: Add LuxTrust certificate that is expiring in
 March 2021 to list of allowed but expired certs
Message-ID: <NPc6SWuUtEV_KV9zofy6MI07KhFoP6QabJFcxS7gN-E=.03e49d1a-6c8d-45e0-8334-99994109f978@github.com>

?ist of allowed but expired certs 8258630: Add expiry exception for QuoVadis root certificate

Reviewed-by: ascarpino

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

Commit messages:
 - 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs 8258630: Add expiry exception for QuoVadis root certificate

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

PR: https://git.openjdk.java.net/jdk16/pull/48

From rhalade at openjdk.java.net  Thu Dec 17 22:16:58 2020
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 17 Dec 2020 22:16:58 GMT
Subject: [jdk16] Integrated: 8225072: Add LuxTrust certificate that is
 expiring in March 2021 to list of allowed but expired certs
In-Reply-To: <NPc6SWuUtEV_KV9zofy6MI07KhFoP6QabJFcxS7gN-E=.03e49d1a-6c8d-45e0-8334-99994109f978@github.com>
References: <NPc6SWuUtEV_KV9zofy6MI07KhFoP6QabJFcxS7gN-E=.03e49d1a-6c8d-45e0-8334-99994109f978@github.com>
Message-ID: <Alfh1RskHdaTYZjf89xW_fThuRYcCXP4reqbkLEowdo=.4942fe71-13c5-480b-8024-b7de948eb1ef@github.com>

On Thu, 17 Dec 2020 22:00:12 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> ?ist of allowed but expired certs 8258630: Add expiry exception for QuoVadis root certificate
> 
> Reviewed-by: ascarpino

This pull request has now been integrated.

Changeset: 9fdfc6df
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/9fdfc6df
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs
8258630: Add expiry exception for QuoVadis root certificate

Backport-of: 666e6c4033762e4e1a8997819de1518616cc0fa8

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

PR: https://git.openjdk.java.net/jdk16/pull/48

From xuelei at openjdk.java.net  Fri Dec 18 04:46:04 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Dec 2020 04:46:04 GMT
Subject: RFR: 8169086: DTLS tests fail intermittently with too much loops or
 timeout
Message-ID: <m7zD2A-2UksH_yWv3ejUW-klIk-WgWvtW0qNRDCcM10=.c51b4c33-23d0-4004-bf96-4788a3e220fd@github.com>

There are a few intermittent timeout in the DTLS regression test in JDK.  In the DTLS implementation, invalid record is not discarded in the ByteBuffers.  So, the next unwrap() will repeat the reading and thus there is a potential dead loop.  The DTLS test failure cannot reproduced, and I'm not very sure if this is the root cause.  Let see if the intermittent failure could be fixed or not with this update.

No new regression, the existing javax/net/ssl/DTLS/PacketLossRetransmission.java test will be used instead.

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

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

Commit messages:
 - Remove problem listed tests
 - 8169086: DTLS tests fail intermittently with too much loops or timeout

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

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

From xuelei at openjdk.java.net  Fri Dec 18 06:01:02 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Dec 2020 06:01:02 GMT
Subject: RFR: 8258661: Inner class ResponseCacheEntry could be static
Message-ID: <yLuMeWV5o0BFhl_9c60HAvKPBosqT7A4skquh8ZQ3wk=.1417636d-731e-4941-97ca-eec16cb96e70@github.com>

The inner class StatusResponseManager#ResponseCacheEntry could be static, for better performance.

Code cleanup, no new regression test.

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

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

Commit messages:
 - 8258661: Inner class ResponseCacheEntry could be static

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

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

From jnimeh at openjdk.java.net  Fri Dec 18 06:25:55 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 18 Dec 2020 06:25:55 GMT
Subject: RFR: 8258661: Inner class ResponseCacheEntry could be static
In-Reply-To: <yLuMeWV5o0BFhl_9c60HAvKPBosqT7A4skquh8ZQ3wk=.1417636d-731e-4941-97ca-eec16cb96e70@github.com>
References: <yLuMeWV5o0BFhl_9c60HAvKPBosqT7A4skquh8ZQ3wk=.1417636d-731e-4941-97ca-eec16cb96e70@github.com>
Message-ID: <_6yOtQP-1pHr9ji5x1EiUggpAU7Uasl7Ha6SymE1jak=.fcace174-60be-4c89-945a-40e8dc981661@github.com>

On Fri, 18 Dec 2020 05:55:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The inner class StatusResponseManager#ResponseCacheEntry could be static, for better performance.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258661

Looks fine.  Based on the comment it probably was supposed to be static from the get-go.  Not sure why I didn't add that keyword originally.

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

Marked as reviewed by jnimeh (Reviewer).

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

From github.com+7693005+jarviscraft at openjdk.java.net  Fri Dec 18 16:04:18 2020
From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis)
Date: Fri, 18 Dec 2020 16:04:18 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be
 cached [v3]
In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
Message-ID: <rRz3WhNlbP8N36suq1OK9kBUcID82URDFwAi45CBp5Q=.f6e8c676-54fb-4056-873c-f65e5c83a51e@github.com>

> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class.

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

 - 8258588: add Md5MessageDigestLookup benchmark
 - 8258588: make UUID#Md5Digest thread-safe using ThreadLocal

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1821/files
  - new: https://git.openjdk.java.net/jdk/pull/1821/files/37db4c56..1abb7cfe

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

  Stats: 87 lines in 2 files changed: 77 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1821.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821

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

From github.com+7693005+jarviscraft at openjdk.java.net  Fri Dec 18 16:04:18 2020
From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis)
Date: Fri, 18 Dec 2020 16:04:18 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <xn6pJezUOCZM_xjGO2JoSiOxXozR_25s2hLn7KPbMK4=.25bf2ad9-b29a-4b07-920a-bb8f34e410de@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <OoyERGtuNNq5hsj2XEBBAQslaP0JRsiH1s_WG-UluKQ=.ede729ec-bb5d-4e1b-ab0b-0c4a96a03fea@github.com>
 <gAmsyAy23HXCD2qXq79DOLBgf2h2D-FT6_gWpCPwDmI=.6d60125a-c025-4544-8e79-8658840274ee@github.com>
 <Lfc3JjOMSXukSER_whFD3KowSIMITuCJDlz
 UdV4z5NI=.baa4b3ac-9710-48fc-80b8-fe138f8c3d5f@github.com>
 <xn6pJezUOCZM_xjGO2JoSiOxXozR_25s2hLn7KPbMK4=.25bf2ad9-b29a-4b07-920a-bb8f34e410de@github.com>
Message-ID: <uVtQSlENv-sB0KmF-bUqD6uChLtsmBUA_KGPytcugRY=.88d45a16-9ae1-4f0b-97e7-363a32de2581@github.com>

On Fri, 18 Dec 2020 15:48:52 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft at openjdk.org> wrote:

>> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner).
>
>> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner).
> 
> I've thought about using `ThreadLocal` at holder level and my naive benchmark shows significant improvement in speed compared to current implementation: https://gist.github.com/JarvisCraft/61cd45f83aea7f33cba9510e523a5c4e
> 
> As of the state from single thread's perspective, it seems to be safe to reuse `MessageDigest` in this case:
> 
>> The `digest` method can be called once for a given number of updates. After `digest` has been called, the MessageDigest object is reset to its initialized state.

I've pushed the change utilizing `ThreadLocal` and my benchmark to correspond to the discussion.

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

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

From rriggs at openjdk.java.net  Fri Dec 18 16:38:56 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 18 Dec 2020 16:38:56 GMT
Subject: Integrated: 8252055: Use java.util.HexFormat in java.security
In-Reply-To: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>
References: <zJs8w9EJ8S7Km7tLLKbv4BedUbWx4F-zU9WatX-Mt80=.6ee180af-7c48-41a4-ab20-cf9517cd9837@github.com>
Message-ID: <i4xxpX0hgBmsF-cYDehKsKneR6opk7_qyf7nOJDKg8Y=.3b1e8de2-6a4d-4469-a521-354b69702b9e@github.com>

On Thu, 17 Dec 2020 20:45:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes.

This pull request has now been integrated.

Changeset: 68f2acbf
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68f2acbf
Stats:     254 lines in 15 files changed: 13 ins; 183 del; 58 mod

8252055: Use java.util.HexFormat in java.security

Reviewed-by: xuelei

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

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

From ascarpino at openjdk.java.net  Fri Dec 18 17:26:54 2020
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 18 Dec 2020 17:26:54 GMT
Subject: RFR: 8169086: DTLS tests fail intermittently with too much loops
 or timeout
In-Reply-To: <m7zD2A-2UksH_yWv3ejUW-klIk-WgWvtW0qNRDCcM10=.c51b4c33-23d0-4004-bf96-4788a3e220fd@github.com>
References: <m7zD2A-2UksH_yWv3ejUW-klIk-WgWvtW0qNRDCcM10=.c51b4c33-23d0-4004-bf96-4788a3e220fd@github.com>
Message-ID: <CsA2mkBmk9J-YeatYLKLX9jznWGPWvQiFvVDO08CsOE=.4455a494-3f4f-4650-9f59-976a5c041cbd@github.com>

On Fri, 18 Dec 2020 01:05:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> There are a few intermittent timeout in the DTLS regression test in JDK.  In the DTLS implementation, invalid record is not discarded in the ByteBuffers.  So, the next unwrap() will repeat the reading and thus there is a potential dead loop.  The DTLS test failure cannot reproduced, and I'm not very sure if this is the root cause.  Let see if the intermittent failure could be fixed or not with this update.
> 
> No new regression, the existing javax/net/ssl/DTLS/PacketLossRetransmission.java test will be used instead.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169086

Change looks reasonable and a minimal risk attempt

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

Marked as reviewed by ascarpino (Reviewer).

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

From xuelei at openjdk.java.net  Fri Dec 18 18:55:55 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Dec 2020 18:55:55 GMT
Subject: Integrated: 8169086: DTLS tests fail intermittently with too much
 loops or timeout
In-Reply-To: <m7zD2A-2UksH_yWv3ejUW-klIk-WgWvtW0qNRDCcM10=.c51b4c33-23d0-4004-bf96-4788a3e220fd@github.com>
References: <m7zD2A-2UksH_yWv3ejUW-klIk-WgWvtW0qNRDCcM10=.c51b4c33-23d0-4004-bf96-4788a3e220fd@github.com>
Message-ID: <o7SZ80Uciw1Ma9Q22Jeg0loYP1Q3-Vh9IVrL_5DhLeg=.9d27fcac-3f2b-4b50-aeab-c000e6850c96@github.com>

On Fri, 18 Dec 2020 01:05:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> There are a few intermittent timeout in the DTLS regression test in JDK.  In the DTLS implementation, invalid record is not discarded in the ByteBuffers.  So, the next unwrap() will repeat the reading and thus there is a potential dead loop.  The DTLS test failure cannot reproduced, and I'm not very sure if this is the root cause.  Let see if the intermittent failure could be fixed or not with this update.
> 
> No new regression, the existing javax/net/ssl/DTLS/PacketLossRetransmission.java test will be used instead.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169086

This pull request has now been integrated.

Changeset: 3c488199
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c488199
Stats:     10 lines in 2 files changed: 0 ins; 2 del; 8 mod

8169086: DTLS tests fail intermittently with too much loops or timeout

Reviewed-by: ascarpino

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

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

From xuelei at openjdk.java.net  Fri Dec 18 19:06:57 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Dec 2020 19:06:57 GMT
Subject: Integrated: 8258661: Inner class ResponseCacheEntry could be static
In-Reply-To: <yLuMeWV5o0BFhl_9c60HAvKPBosqT7A4skquh8ZQ3wk=.1417636d-731e-4941-97ca-eec16cb96e70@github.com>
References: <yLuMeWV5o0BFhl_9c60HAvKPBosqT7A4skquh8ZQ3wk=.1417636d-731e-4941-97ca-eec16cb96e70@github.com>
Message-ID: <3eBx7wYmB_zTVHaIPxFInPPUpGo6XgdB0qQ7Uth34PM=.762dc960-098f-4ccb-9e91-5fee41b92457@github.com>

On Fri, 18 Dec 2020 05:55:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The inner class StatusResponseManager#ResponseCacheEntry could be static, for better performance.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258661

This pull request has now been integrated.

Changeset: a4f393ca
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a4f393ca
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8258661: Inner class ResponseCacheEntry could be static

Reviewed-by: jnimeh

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

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

From mullan at openjdk.java.net  Fri Dec 18 19:06:59 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 18 Dec 2020 19:06:59 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
Message-ID: <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>

On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft at openjdk.org> wrote:

> > MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time.
> 
> In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present?

Perhaps it should throw `UnsupportedOperationException`, but I'll defer to someone who works in this area. It may also be useful to support type 5 UUIDs which use SHA-1.

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

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

From smarks at openjdk.java.net  Fri Dec 18 20:13:59 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 18 Dec 2020 20:13:59 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
Message-ID: <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>

On Fri, 18 Dec 2020 19:04:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time.
>> 
>> In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present?
>
>> > MD5 and DES were removed as SE requirements in JDK 14. See https://bugs.openjdk.java.net/browse/JDK-8214483 for more information. However, there are no plans to remove the implementations from the JDK at this time.
>> 
>> In this case, should a bug report be filled to require specifying behaviour for `UUID#nameUUIDFromBytes(byte[])` in case of MD5 not being present?
> 
> Perhaps it should throw `UnsupportedOperationException`, but I'll defer to someone who works in this area. It may also be useful to support type 5 UUIDs which use SHA-1.

I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?

I'd like to see a demonstration that fetching and allocating an MD5 MessageDigest instance on each call is indeed a performance problem (either because it's too slow, or because it takes too much memory). Based on that we might or might not want to do some optimization of some form or another. Or we might want to optimize creation in MessageDigest instead of caching instances in UUID. More fundamentally, I'd like to see an answer to the question, "What problem is this change intended to solve?"

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

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

From xuelei at openjdk.java.net  Sat Dec 19 05:53:59 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 19 Dec 2020 05:53:59 GMT
Subject: RFR: 8258736: No break in the loop
Message-ID: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>

It looks like the break is missed in the loop of the SSLCipher.createReadCipher() and createWriteCipher() methods.  See the change set.

Code cleanup, no new regression test.

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

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

Commit messages:
 - 8258736: No break in the loop

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:10:02 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:10:02 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
Message-ID: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>

8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Commit messages:
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

Changes: https://git.openjdk.java.net/jdk/pull/1853/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8080272
  Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:46:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:46:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v2]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <hY6bq5j7bf8POwY5aKS87ncspu7iRgBq-8N8PZsW6Os=.e4ecc2ff-a299-4221-92be-6f98756c933e@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in JrtPath. They compiled with java 8 language level

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455

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

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

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

From alanb at openjdk.java.net  Sun Dec 20 19:45:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:45:54 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.

We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.

One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

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

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

From alanb at openjdk.java.net  Sun Dec 20 19:51:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:51:55 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
Message-ID: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>

On Fri, 18 Dec 2020 20:11:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?

This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:09:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:09:12 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v3]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oNRktI1p1Z3VLqIBLK6yPqk-mDMFmh8EzMrRuHmtp8w=.cdd1f3fe-c7ba-4e83-8220-da2e2582004f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in ASM
  use Files.copy in sjavac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471

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

  Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:15:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:15:09 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v4]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <F5_oGJSwGgKTiBxBuzIa3DietHA6DAukNrG1tKXMwzQ=.89920e48-6c93-4ea9-b383-63dc9ba58fa9@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in MLet too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:22:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:22:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v5]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <vAvbxQL52sRM-zF5IuAEfbLXaj-8xfux8XNvlDyQTno=.f1389529-1b8c-4d5a-a335-bea8d182586f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in Win32PrintJob too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:25:52 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:25:52 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
Message-ID: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>

On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

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

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

From prr at openjdk.java.net  Sun Dec 20 20:36:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 20:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
Message-ID: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>

On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.
>> 
>> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.
>> 
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
> 
> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

So these changes are all over the place which means no one person knows how to test all of it.
Have you run the sound, swing tests, and the  printing tests on unix and windows ?
For printing for sure you'll need to do some manual testing.

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

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

From redestad at openjdk.java.net  Sun Dec 20 20:48:58 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 20 Dec 2020 20:48:58 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
 <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ
 WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
Message-ID: <n-g2_8UAHCQgcmQ6F9E83TThM6PP8-0KgbDFmJ_sXeI=.1727053a-6bc1-44ab-ac92-d6462a341504@github.com>

On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
>> 
>> I'd like to see a demonstration that fetching and allocating an MD5 MessageDigest instance on each call is indeed a performance problem (either because it's too slow, or because it takes too much memory). Based on that we might or might not want to do some optimization of some form or another. Or we might want to optimize creation in MessageDigest instead of caching instances in UUID. More fundamentally, I'd like to see an answer to the question, "What problem is this change intended to solve?"
>
>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
> 
> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options.

As Stuart argues a TL approach is likely to look better in a microbenchmark, but make things worse in other regards.

I started exploring options to this in #1855 (not logged an RFE, yet), and I think there is potential to get most of the gains seen here without the introduction of a `ThreadLocal`. The current patch also speeds up MD5.digest for small chunks (+19% for 16 bytes, but less relative impact on larger chunks, down to being lost in the noise on 16Kb). Speed-up of `UUID.nameUUIDFromBytes` is somewhat modest right now (+4%, -17% allocations), but I think it can be improved further without complicating things too much. The MD5 intrinsic added by JDK-8250902 adds some constraints on the implementation that holds back some polish. This can be fixed, but requires some coordination.

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

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

From redestad at openjdk.java.net  Sun Dec 20 21:48:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 20 Dec 2020 21:48:56 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <n-g2_8UAHCQgcmQ6F9E83TThM6PP8-0KgbDFmJ_sXeI=.1727053a-6bc1-44ab-ac92-d6462a341504@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
 <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ
 WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
 <n-g2_8UAHCQgcmQ6F9E83TThM6PP8-0KgbDFmJ_sXeI=.1727053a-6bc1-44ab-ac92-d6462a341504@github.com>
Message-ID: <N8eZuA9m479uUncwAx6O5AM_b_Cg1RSMrsybWhBFsug=.9902ce62-4faf-459c-9415-08fab90512aa@github.com>

On Sun, 20 Dec 2020 20:45:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
>> 
>> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options.
>
> As Stuart argues a TL approach is likely to look better in a microbenchmark, but make things worse in other regards.
> 
> I started exploring options to this in #1855 (not logged an RFE, yet), and I think there is potential to get most of the gains seen here without the introduction of a `ThreadLocal`. The current patch also speeds up MD5.digest for small chunks (+19% for 16 bytes, but less relative impact on larger chunks, down to being lost in the noise on 16Kb). Speed-up of `UUID.nameUUIDFromBytes` is somewhat modest right now (+4%, -17% allocations), but I think it can be improved further without complicating things too much. The MD5 intrinsic added by JDK-8250902 adds some constraints on the implementation that holds back some polish. This can be fixed, but requires some coordination.

A trick that could be used here instead of `ThreadLocal` is to store an instance of MD5 retrieved via MessageDigest.getInstance, but clone it before use. See [this commit](https://github.com/openjdk/jdk/pull/1855/commits/2f266316d62ca875c38e2f771412d02625414bf4). 

This maintains thread safety, avoids the allure of TLs, and gives a substantial speed-up on the `UUIDBench.fromType3Bytes` micro (comparing it against the other optimizations that were already in #1855):

 
Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    1.523 ?  0.066  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  408.036 ?  0.003    B/op

Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    2.186 ?  0.228  ops/us
UUIDBench.fromType3Bytes:?gc.alloc.rate.norm                20000  thrpt   12  264.023 ?  0.006    B/op

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

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

From github.com+7693005+jarviscraft at openjdk.java.net  Sun Dec 20 22:43:54 2020
From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis)
Date: Sun, 20 Dec 2020 22:43:54 GMT
Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
In-Reply-To: <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQWBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
 <RfY50ivUIozAD5-LocBW86nZG9awy4kNgGlSI3AKBH0=.8db0797b-32dd-4b1f-aad8-8921d8f37d2d@github.com>
 <EzYmzka4PzZcK7NAjq-Mw2W75Ld8Q4tDO6-9lR2HaVo=.da56add3-9039-4427-95e3-e3416a6500eb@github.com>
 <u_U1igoAzasYgZSA8ssJa2a9ShTlw_1NlzAKLu7KCSo=.a2624e81-45f1-49d6-86de-fbc3c9d63357@github.com>
 <zw4zpLGloGNrMzkXqEg1i5SQoNcdBBe6jkImTG-z8-M=.d787766a-2527-4f11-8db8-288ef18494be@github.com>
 <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com>
 <sKf-QKlrAEPFA2pKi1REBGEIOuv6xKtOFutCjSvPWwE=.86717b36-5b10-4903-aa2c-96c43bef1c1e@github.com>
 <i4bNHquF1lkB097yvKvMk_BCBDFcMYxHJBwZs1O__IE=.e2362c4a-b500-4b28-9668-0ac6741417f5@github.com>
 <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com>
 <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com>
 <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ
 WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com>
Message-ID: <zGhr7ogSfH81CE_7Jcq1ukbTc1LKnYQyYqKmjr8SF7E=.d3dd2cf9-86de-41f6-ad47-80b6758f2a52@github.com>

On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?

Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative.

Currently, I will keep this PR open but I expect this to be superseded by the latter.

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

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

From serb at openjdk.java.net  Sun Dec 20 22:50:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 20 Dec 2020 22:50:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
Message-ID: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race <prr at openjdk.org> wrote:

>>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>> 
>> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.
>
> So these changes are all over the place which means no one person knows how to test all of it.
> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
> For printing for sure you'll need to do some manual testing.

I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:52:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:52:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v6]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <egekHLmTMOf1zvpBGHF6ho4g2MWS1mY0c_g4elVAGUs=.ba8b3b7f-7b6a-4f4a-95f1-bdc73c7b74db@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711

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

  Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:58:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:58:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
Message-ID: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>

On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So these changes are all over the place which means no one person knows how to test all of it.
>> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
>> For printing for sure you'll need to do some manual testing.
>
> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

I've extracted changes in java.desktop into separate PR #1856
Reverted this changes from current PR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 08:19:08 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 08:19:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05-06

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

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

From alanb at openjdk.java.net  Mon Dec 21 08:36:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Dec 2020 08:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
 <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com>

On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.
>
> I've extracted changes in java.desktop into separate PR #1856
> Reverted this changes from current PR.

Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:16:11 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:16:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in Apache Santuario

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06-07

  Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 09:47:59 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 09:47:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main`

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:

> 2457:                 byte[] bytes = in.readAllBytes();
> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
> 2459:                         new ByteArrayInputStream(bytes));

Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:53:57 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:53:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
Message-ID: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>

On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
> 
>> 2457:                 byte[] bytes = in.readAllBytes();
>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>> 2459:                         new ByteArrayInputStream(bytes));
> 
> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

Looks like it was done intentionally by original author of the code.
Check comment above:

                // Read the full stream before feeding to X509Factory,
                // otherwise, keytool -gencrl | keytool -printcrl
                // might not work properly, since -gencrl is slow
                // and there's no data in the pipe at the beginning.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 10:06:01 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 10:06:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
 <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
Message-ID: <m7_aUO_Qf7tKkUNuihCnh8Lh83xzYp3AOANwFucPBsE=.201f4482-bd10-4936-b58c-9148b3dd18d3@github.com>

On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>> 
>>> 2457:                 byte[] bytes = in.readAllBytes();
>>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>>> 2459:                         new ByteArrayInputStream(bytes));
>> 
>> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?
>
> Looks like it was done intentionally by original author of the code.
> Check comment above:
> 
>                 // Read the full stream before feeding to X509Factory,
>                 // otherwise, keytool -gencrl | keytool -printcrl
>                 // might not work properly, since -gencrl is slow
>                 // and there's no data in the pipe at the beginning.

Let's keep it then

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

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

From wetmore at openjdk.java.net  Mon Dec 21 18:40:54 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 21 Dec 2020 18:40:54 GMT
Subject: RFR: 8258736: No break in the loop
In-Reply-To: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
References: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
Message-ID: <qMksBQHDQ5jBghrgaxAhZ195FU1GT5EP2ycSa41WEFg=.2dc4f2f1-8376-42e6-bffb-bdf2c54bb3b2@github.com>

On Sat, 19 Dec 2020 05:48:53 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It looks like the break is missed in the loop of the SSLCipher.createReadCipher() and createWriteCipher() methods.  See the change set.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258736

Approved with the condition of updating the copyright year.  

There was also a failure in the Linux Presubmit tests which is probably bogus.

Looks good otherwise.

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

Marked as reviewed by wetmore (Reviewer).

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

From xuelei at openjdk.java.net  Mon Dec 21 19:08:08 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Dec 2020 19:08:08 GMT
Subject: RFR: 8258736: No break in the loop [v2]
In-Reply-To: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
References: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
Message-ID: <7a6zhDnUz3rMA1dE4_gLrKjpCFH80C6yEqURwubyTV8=.bd131934-11ae-418b-a965-236353c62d71@github.com>

> It looks like the break is missed in the loop of the SSLCipher.createReadCipher() and createWriteCipher() methods.  See the change set.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258736

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1848/files
  - new: https://git.openjdk.java.net/jdk/pull/1848/files/3dd9fb3e..b36ba8db

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

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

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

From xuelei at openjdk.java.net  Mon Dec 21 19:08:08 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Dec 2020 19:08:08 GMT
Subject: RFR: 8258736: No break in the loop [v2]
In-Reply-To: <qMksBQHDQ5jBghrgaxAhZ195FU1GT5EP2ycSa41WEFg=.2dc4f2f1-8376-42e6-bffb-bdf2c54bb3b2@github.com>
References: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
 <qMksBQHDQ5jBghrgaxAhZ195FU1GT5EP2ycSa41WEFg=.2dc4f2f1-8376-42e6-bffb-bdf2c54bb3b2@github.com>
Message-ID: <7qxM3B7ljEDb8PiJhFbxzUEhONV4k9LEjIPyLaWnldo=.fc1d6d2f-82cb-4866-8527-ef543267bde7@github.com>

On Mon, 21 Dec 2020 18:37:46 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Approved with the condition of updating the copyright year.
> 
Good catch!

> There was also a failure in the Linux Presubmit tests which is probably bogus.
> 
I checked the failure, which is not related to this update.

> Looks good otherwise.
Thanks for the review.

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

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

From xuelei at openjdk.java.net  Mon Dec 21 19:08:09 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Dec 2020 19:08:09 GMT
Subject: Withdrawn: 8258736: No break in the loop
In-Reply-To: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
References: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
Message-ID: <dJ5hra60XFpgxfgoAtlp3iRCdoTAEu9h_XRNgOIUQT8=.68c10dc5-fed7-4ab3-affc-8d911594dedb@github.com>

On Sat, 19 Dec 2020 05:48:53 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It looks like the break is missed in the loop of the SSLCipher.createReadCipher() and createWriteCipher() methods.  See the change set.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258736

This pull request has been closed without being integrated.

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

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

From xuelei at openjdk.java.net  Mon Dec 21 19:14:55 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Dec 2020 19:14:55 GMT
Subject: Integrated: 8258736: No break in the loop
In-Reply-To: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
References: <SZpliz_V6W1Fpdz-EpMpvjhHUFiVN3_OGk0Mhey4KH8=.00097dd2-9231-419a-adca-3f4c08cbe0ed@github.com>
Message-ID: <KN9Cc_DTZWKLatFD2V2qtFGmnuCscA8VFX9hlHq3feA=.8e936c4f-9528-4070-962d-1e7fd7e631b2@github.com>

On Sat, 19 Dec 2020 05:48:53 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It looks like the break is missed in the loop of the SSLCipher.createReadCipher() and createWriteCipher() methods.  See the change set.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258736

This pull request has now been integrated.

Changeset: 12297a00
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12297a00
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8258736: No break in the loop

Reviewed-by: wetmore

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

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

From xuelei at openjdk.java.net  Tue Dec 22 00:02:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 00:02:03 GMT
Subject: RFR: 8258804: Collection.toArray() should use empty array
Message-ID: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>

Comparing to Collection.toArray(new T[size)), he Collection.toArray(new T[0]) seems faster, safer and contractually cleaner.  In the update, the use of Collection.toArray(new T[size)) in the SunJSSE provider implementation is replaced with Collection.toArray(new T[0]).

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

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

Commit messages:
 - 8258804: Collection.toArray() should use empty array

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

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

From coffeys at openjdk.java.net  Tue Dec 22 15:40:22 2020
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Dec 2020 15:40:22 GMT
Subject: RFR: 8253368: TLS connection always receives close_notify
 exception [v2]
In-Reply-To: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
Message-ID: <seZtqWu3lguDPHTH62Z6Tu3XAe4J7rZZnc_Y1EdZ4nA=.826489b3-ce10-4668-8790-a3ce1840e19f@github.com>

> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.

Sean Coffey 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:

 - version 2 redesign
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253368
 - 8253368: TLS connection always receives close_notify exception

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1205/files
  - new: https://git.openjdk.java.net/jdk/pull/1205/files/85d41030..86d9dac5

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

  Stats: 284235 lines in 2912 files changed: 188350 ins; 66757 del; 29128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1205.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1205/head:pull/1205

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

From coffeys at openjdk.java.net  Tue Dec 22 15:42:56 2020
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Dec 2020 15:42:56 GMT
Subject: RFR: 8253368: TLS connection always receives close_notify
 exception
In-Reply-To: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
Message-ID: <4A0b3NLIJAsA9yY67ym0OFhrW4nHarEpBOPTFy-P33s=.8b9c02ca-e53e-43f2-9d28-e934d0e57a32@github.com>

On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.

@XueleiFan I went ahead with your advice and chose to keep the check in the code. Since JDK 11, this code path would have thrown an SSLException. I've chosen to keep that instead of introduce another Exception(UnsupportedOperationException) -- which  would be new for some application stacks. I've looked at the apache core-http stack and know that it catches and ignores SSLException in these cases.

The important change here is that the exception is not fatal and the session remains valid. Socket is closed out in a finally block. test case updated also.

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

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

From weijun at openjdk.java.net  Tue Dec 22 15:51:05 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Dec 2020 15:51:05 GMT
Subject: RFR: 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()
Message-ID: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>

The method is useless now since the related TLS cipher suite was removed long ago.

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

Commit messages:
 - 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()

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

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

From weijun at openjdk.java.net  Tue Dec 22 16:35:58 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Dec 2020 16:35:58 GMT
Subject: RFR: 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()
In-Reply-To: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
References: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
Message-ID: <J2z_ZP4X6NEMACLERa2cPsj58zTuEYM8TAzVFdpJ0dM=.5d9be431-a951-4634-9dae-4b04cc189809@github.com>

On Tue, 22 Dec 2020 15:47:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The method is useless now since the related TLS cipher suite was removed long ago.

> /label remove core-libs

Oops, https://github.com/openjdk/skara/pull/980 filed.

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

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

From xuelei at openjdk.java.net  Tue Dec 22 16:37:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 16:37:03 GMT
Subject: RFR: 8253368: TLS connection always receives close_notify
 exception [v2]
In-Reply-To: <seZtqWu3lguDPHTH62Z6Tu3XAe4J7rZZnc_Y1EdZ4nA=.826489b3-ce10-4668-8790-a3ce1840e19f@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
 <seZtqWu3lguDPHTH62Z6Tu3XAe4J7rZZnc_Y1EdZ4nA=.826489b3-ce10-4668-8790-a3ce1840e19f@github.com>
Message-ID: <wS-FG0eB7ZDmWV52tr2CS4W2XeXTN20swIKLgG8vv_4=.f3e44e74-1ae1-4d5d-b65b-25866e5bc58f@github.com>

On Tue, 22 Dec 2020 15:40:22 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.
>
> Sean Coffey 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:
> 
>  - version 2 redesign
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253368
>  - 8253368: TLS connection always receives close_notify exception

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.java.net  Tue Dec 22 16:37:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 16:37:03 GMT
Subject: RFR: 8253368: TLS connection always receives close_notify
 exception
In-Reply-To: <4A0b3NLIJAsA9yY67ym0OFhrW4nHarEpBOPTFy-P33s=.8b9c02ca-e53e-43f2-9d28-e934d0e57a32@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
 <4A0b3NLIJAsA9yY67ym0OFhrW4nHarEpBOPTFy-P33s=.8b9c02ca-e53e-43f2-9d28-e934d0e57a32@github.com>
Message-ID: <F8WQpTVsCygHf7UT6SyMMiI29aOgiFrqKT4jdosgpKc=.4e4e3756-3aef-406f-8836-e1ba6fc816c4@github.com>

On Tue, 22 Dec 2020 15:40:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> @XueleiFan I went ahead with your advice and chose to keep the check in the code. Since JDK 11, this code path would have thrown an SSLException. I've chosen to keep that instead of introduce another Exception(UnsupportedOperationException) -- which would be new for some application stacks. I've looked at the apache core-http stack and know that it catches and ignores SSLException in these cases.
> 
> The important change here is that the exception is not fatal and the session remains valid. Socket is closed out in a finally block. test case updated also.

OK. Thanks for the update.

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

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

From xuelei at openjdk.java.net  Tue Dec 22 16:38:54 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 16:38:54 GMT
Subject: RFR: 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()
In-Reply-To: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
References: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
Message-ID: <OTZUOnV5bzJevkvn-jGmq28TGTr0Y_XlKLs2rikPUJg=.e81f82ed-fdd8-4fcb-b2cf-d8eae659527b@github.com>

On Tue, 22 Dec 2020 15:47:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The method is useless now since the related TLS cipher suite was removed long ago.

Marked as reviewed by xuelei (Reviewer).

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

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

From xuelei at openjdk.java.net  Tue Dec 22 16:38:55 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 16:38:55 GMT
Subject: RFR: 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()
In-Reply-To: <OTZUOnV5bzJevkvn-jGmq28TGTr0Y_XlKLs2rikPUJg=.e81f82ed-fdd8-4fcb-b2cf-d8eae659527b@github.com>
References: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
 <OTZUOnV5bzJevkvn-jGmq28TGTr0Y_XlKLs2rikPUJg=.e81f82ed-fdd8-4fcb-b2cf-d8eae659527b@github.com>
Message-ID: <bh6AB_PDwuKGFySoebKQ70FkjGWeWcrzvhQ7uWJjXbY=.10155e20-780f-4e80-b5af-717239a313d7@github.com>

On Tue, 22 Dec 2020 16:36:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> The method is useless now since the related TLS cipher suite was removed long ago.
>
> Marked as reviewed by xuelei (Reviewer).

Looks good to me.

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

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

From weijun at openjdk.java.net  Tue Dec 22 16:43:57 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Dec 2020 16:43:57 GMT
Subject: Integrated: 8258631: Remove
 sun.security.jgss.krb5.Krb5Util.getSubject()
In-Reply-To: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
References: <vjN8krB5MJcJkWrHb58JRyS1a8niX1Fop_U86pKahF8=.773d1437-9760-413f-a43b-8cd4373f7d73@github.com>
Message-ID: <zeLIpnto9m-vFTLZJHzARW_B-J8HWFmRNUzFHN3m2zI=.30f7b01f-c60c-4d99-959c-52a47f4aa407@github.com>

On Tue, 22 Dec 2020 15:47:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The method is useless now since the related TLS cipher suite was removed long ago.

This pull request has now been integrated.

Changeset: 9e463d1a
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e463d1a
Stats:     25 lines in 1 file changed: 0 ins; 24 del; 1 mod

8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()

Reviewed-by: xuelei

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

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

From xuelei at openjdk.java.net  Tue Dec 22 17:21:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 17:21:03 GMT
Subject: RFR: 8258828: The method local variable is not really used
Message-ID: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>

The local variable "knownSignatureSchemes" in the CRSignatureSchemesConsumer.consume() method is assigned, but it is not really queried. It is safe to remove the local variable and the related code.

Code cleanup, no new regression test.

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

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

Commit messages:
 - 8258828: The method local variable is not really used

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

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

From jnimeh at openjdk.java.net  Tue Dec 22 17:34:56 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 22 Dec 2020 17:34:56 GMT
Subject: RFR: 8258828: The method local variable is not really used
In-Reply-To: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
References: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
Message-ID: <uyJZt39g52V3uLieMKbyySuOZllPUHOH3JorL-GGXb0=.20f8a0af-a2e3-4b80-95f6-a7cc4a34b3ee@github.com>

On Tue, 22 Dec 2020 17:16:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The local variable "knownSignatureSchemes" in the CRSignatureSchemesConsumer.consume() method is assigned, but it is not really queried. It is safe to remove the local variable and the related code.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258828

Looks fine.

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

Marked as reviewed by jnimeh (Reviewer).

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

From mullan at openjdk.java.net  Tue Dec 22 18:03:54 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 22 Dec 2020 18:03:54 GMT
Subject: RFR: 8258804: Collection.toArray() should use empty array
In-Reply-To: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
References: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
Message-ID: <GRUz4gM8UOn5RVU3h6TnA5QzJtnRnPsaXradHF5SIq0=.4cd8cd3e-d533-4306-a571-c04d3f764fb8@github.com>

On Mon, 21 Dec 2020 23:58:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Comparing to Collection.toArray(new T[size)), he Collection.toArray(new T[0]) seems faster, safer and contractually cleaner.  In the update, the use of Collection.toArray(new T[size)) in the SunJSSE provider implementation is replaced with Collection.toArray(new T[0]).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258804

Looks fine to me.

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

Marked as reviewed by mullan (Reviewer).

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

From github.com+124581+dmlloyd at openjdk.java.net  Tue Dec 22 18:03:56 2020
From: github.com+124581+dmlloyd at openjdk.java.net (David M.Lloyd)
Date: Tue, 22 Dec 2020 18:03:56 GMT
Subject: RFR: 8258804: Collection.toArray() should use empty array
In-Reply-To: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
References: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
Message-ID: <T_jFqQkL_mpezv6rg8W0siP6_bqmZVN4RHlHin1YMys=.74482590-e879-4498-8607-cfe17709c1a5@github.com>

On Mon, 21 Dec 2020 23:58:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Comparing to Collection.toArray(new T[size)), he Collection.toArray(new T[0]) seems faster, safer and contractually cleaner.  In the update, the use of Collection.toArray(new T[size)) in the SunJSSE provider implementation is replaced with Collection.toArray(new T[0]).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258804

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 854:

> 852:                 // Use the customized TLS protocols.
> 853:                 candidates =
> 854:                     refactored.toArray(new ProtocolVersion[0]);

If this level of performance improvement is justified, then would it not be better to use a constant empty array instead of constructing a new one each time?

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

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

From wetmore at openjdk.java.net  Tue Dec 22 18:13:57 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 22 Dec 2020 18:13:57 GMT
Subject: RFR: 8258828: The method local variable is not really used
In-Reply-To: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
References: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
Message-ID: <TYS4l8Vykq_yrGVf26p07POcJvNKxZ8EkeTV6n2Fxao=.9e94d0f0-28a3-4a12-90bf-0cf270e3d23c@github.com>

On Tue, 22 Dec 2020 17:16:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The local variable "knownSignatureSchemes" in the CRSignatureSchemesConsumer.consume() method is assigned, but it is not really queried. It is safe to remove the local variable and the related code.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258828

Looks ok as long as you don't need this in chc.peerRequestedSignatureSchemes.

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

Marked as reviewed by wetmore (Reviewer).

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

From xuelei at openjdk.java.net  Tue Dec 22 18:15:57 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 18:15:57 GMT
Subject: RFR: 8258804: Collection.toArray() should use empty array
In-Reply-To: <T_jFqQkL_mpezv6rg8W0siP6_bqmZVN4RHlHin1YMys=.74482590-e879-4498-8607-cfe17709c1a5@github.com>
References: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
 <T_jFqQkL_mpezv6rg8W0siP6_bqmZVN4RHlHin1YMys=.74482590-e879-4498-8607-cfe17709c1a5@github.com>
Message-ID: <ZQkZpNOEhkR7y1IDDWU5rPRCQGTZnxTC_1JQIujgUHA=.4aa6b56e-4748-463a-b577-555e51e5ea25@github.com>

On Tue, 22 Dec 2020 12:39:23 GMT, David M. Lloyd <github.com+124581+dmlloyd at openjdk.org> wrote:

>> Comparing to Collection.toArray(new T[size)), the Collection.toArray(new T[0]) seems faster, safer and contractually cleaner.  In the update, the use of Collection.toArray(new T[size)) in the SunJSSE provider implementation is replaced with Collection.toArray(new T[0]).
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8258804
>
> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 854:
> 
>> 852:                 // Use the customized TLS protocols.
>> 853:                 candidates =
>> 854:                     refactored.toArray(new ProtocolVersion[0]);
> 
> If this level of performance improvement is justified, then would it not be better to use a constant empty array instead of constructing a new one each time?

I think empty array construction could be optimized in the compiler layer.

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

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

From xuelei at openjdk.java.net  Tue Dec 22 18:15:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 18:15:58 GMT
Subject: Integrated: 8258804: Collection.toArray() should use empty array
In-Reply-To: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
References: <K3HSxj8TWDQoAn-Rtt17OxHG9vYXcANdxsptte7x2no=.770c7a78-2006-4829-a869-2c1407319d80@github.com>
Message-ID: <ReQnTnUMLCtPpNE30SFOmAZecKARgZqKM-4cIIxpvYc=.e755fd11-37bb-47bb-9e52-d341a9f6e048@github.com>

On Mon, 21 Dec 2020 23:58:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Comparing to Collection.toArray(new T[size)), the Collection.toArray(new T[0]) seems faster, safer and contractually cleaner.  In the update, the use of Collection.toArray(new T[size)) in the SunJSSE provider implementation is replaced with Collection.toArray(new T[0]).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258804

This pull request has now been integrated.

Changeset: 39e03a0b
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39e03a0b
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8258804: Collection.toArray() should use empty array

Reviewed-by: mullan

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

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

From xuelei at openjdk.java.net  Tue Dec 22 18:19:57 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 18:19:57 GMT
Subject: RFR: 8258828: The method local variable is not really used
In-Reply-To: <TYS4l8Vykq_yrGVf26p07POcJvNKxZ8EkeTV6n2Fxao=.9e94d0f0-28a3-4a12-90bf-0cf270e3d23c@github.com>
References: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
 <TYS4l8Vykq_yrGVf26p07POcJvNKxZ8EkeTV6n2Fxao=.9e94d0f0-28a3-4a12-90bf-0cf270e3d23c@github.com>
Message-ID: <gwWLM2P-hj01cs8PU4M58N4udpOacG6-ht7Yd04C4IE=.67e150d8-4959-4a7b-be18-e99a1b93e5b1@github.com>

On Tue, 22 Dec 2020 18:11:23 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Looks ok as long as you don't need this in chc.peerRequestedSignatureSchemes.

No, the chc.peerRequestedSignatureSchemes will be set in the update consumer later on.

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

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

From xuelei at openjdk.java.net  Tue Dec 22 19:46:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Dec 2020 19:46:58 GMT
Subject: Integrated: 8258828: The method local variable is not really used
In-Reply-To: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
References: <v4hb45NWkcH8qUO8nwpky0G2D-lLNQpO9luDfuiG7Io=.ea82191c-cb9d-45bd-950c-888a2f8f2ccb@github.com>
Message-ID: <J-JS7W1QtMobLQw2YVjmNPSbgbIOE_VA5APX1MdeDUw=.972575bc-b3fc-4584-a7dd-3e4130a0dfaf@github.com>

On Tue, 22 Dec 2020 17:16:15 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The local variable "knownSignatureSchemes" in the CRSignatureSchemesConsumer.consume() method is assigned, but it is not really queried. It is safe to remove the local variable and the related code.
> 
> Code cleanup, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258828

This pull request has now been integrated.

Changeset: 47c9b437
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47c9b437
Stats:     11 lines in 1 file changed: 2 ins; 8 del; 1 mod

8258828: The method local variable is not really used

Reviewed-by: jnimeh, wetmore

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

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

From xuelei at openjdk.java.net  Wed Dec 23 01:01:06 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Dec 2020 01:01:06 GMT
Subject: RFR: 8258852: Arrays.asList() for single item could be replaced with
 Collections.singletonList()
Message-ID: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>

If there is only one item, the call to Arrays.asList() could be replaced with Collections.singletonList() for less memory occupation.  This update also includes some other code cleanup, like redundant variables in the related files.

Code cleanup only, no new regression test.

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

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

Commit messages:
 - 8258852: Arrays.asList() for single item could be replaced with Collections.singletonList()

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

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

From valeriep at openjdk.java.net  Wed Dec 23 02:18:04 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 02:18:04 GMT
Subject: RFR: 8258186: Replace use of JNI_COMMIT mode with mode 0
Message-ID: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>

Could someone please help review this trivial change - just replace JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.

Thanks,
Valerie

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

Commit messages:
 - 8258186: Replace use of JNI_COMMIT mode with mode 0

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

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

From xuelei at openjdk.java.net  Wed Dec 23 04:38:01 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Dec 2020 04:38:01 GMT
Subject: RFR: 8258186: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
References: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
Message-ID: <dySNuhCehbVKvE9_BAXYVnocgWGveepC-K3xBt0mbZI=.39e34248-080b-40a6-8891-a50abc4b8a00@github.com>

On Wed, 23 Dec 2020 02:13:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this trivial change - just replace JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
> 
> Thanks,
> Valerie

It looks a safe update to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From alanb at openjdk.java.net  Wed Dec 23 12:01:59 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Dec 2020 12:01:59 GMT
Subject: RFR: 8258186: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
References: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
Message-ID: <SFo2EP53a9IVh4vdFEw0N26r6tRz19Fli78E5tRuD4M=.e2ae47a2-cb8c-4272-bdc0-c53fff1c78bc@github.com>

On Wed, 23 Dec 2020 02:13:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this trivial change - just replace JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
> 
> Thanks,
> Valerie

Marked as reviewed by alanb (Reviewer).

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

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

From coffeys at openjdk.java.net  Wed Dec 23 12:29:56 2020
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 23 Dec 2020 12:29:56 GMT
Subject: Integrated: 8253368: TLS connection always receives close_notify
 exception
In-Reply-To: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
References: <ivIvmluoHdlh08-HypbrweQmce4veF_s30Lj7gKG890=.f8e637df-d359-44b1-bf98-a408e975dc6c@github.com>
Message-ID: <bUOYZZJTzLevVMATI0uuJieQ9VDi974IINLHqHZ0qGM=.cf6322f4-23d9-4368-a13d-6463d75419dc@github.com>

On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end.

This pull request has now been integrated.

Changeset: a4e082e9
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a4e082e9
Stats:     37 lines in 2 files changed: 25 ins; 0 del; 12 mod

8253368: TLS connection always receives close_notify exception

Reviewed-by: xuelei

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 23 13:25:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Dec 2020 13:25:09 GMT
Subject: RFR: 8253821: Improve ByteBuffer performance with GCM [v6]
In-Reply-To: <4ahM8RttKuOnFWEgKagrpajFm3Wi2uq_G6BTWDuAo4Y=.48fea738-627f-4b3e-9ce4-1b0cba8dea1c@github.com>
References: <aus4qy8fxZt5gicnDhWSxbr2PI7zegoUb0GFaG1g7iU=.b48e484e-c435-4a17-8e10-e7cee89d5673@github.com>
 <4ahM8RttKuOnFWEgKagrpajFm3Wi2uq_G6BTWDuAo4Y=.48fea738-627f-4b3e-9ce4-1b0cba8dea1c@github.com>
Message-ID: <XB1qoP9QaLFSemngRbG6OpehLcXn4hQYLjlJxiCQY1Q=.3e41a434-2b90-4c3e-8053-22385a58f97d@github.com>

On Wed, 2 Dec 2020 05:01:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 8253821: Improve ByteBuffer performance with GCM
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments v4

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

> 973:             if (!src.isReadOnly()) {
> 974:                 // If using the heap, check underlying byte[] address.
> 975:                 if (!src.array().equals(dst.array()) ) {

It looks a bit confusing to me to compare arrays with `equals` method call.
Perhaps its worth to use `==` instead to avoid mistreating and make code more readable.

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

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

From valeriep at openjdk.java.net  Wed Dec 23 19:20:08 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 19:20:08 GMT
Subject: RFR: 8258851: Mismatch in SunPKCS11 provider registration properties
 and actual implementation
Message-ID: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>

Max, can you help taking a look? This trivial change fixes the inconsistent registration properties to match the actual implementation.

In addition to the DH->EC KeyFactory inconsistency, the new test finds another MAC->Mac typo.
Mach5 run is clean.
Thanks,
Valerie

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

Commit messages:
 - 8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation

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

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

From valeriep at openjdk.java.net  Wed Dec 23 20:50:56 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 20:50:56 GMT
Subject: RFR: 8258186: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <SFo2EP53a9IVh4vdFEw0N26r6tRz19Fli78E5tRuD4M=.e2ae47a2-cb8c-4272-bdc0-c53fff1c78bc@github.com>
References: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
 <SFo2EP53a9IVh4vdFEw0N26r6tRz19Fli78E5tRuD4M=.e2ae47a2-cb8c-4272-bdc0-c53fff1c78bc@github.com>
Message-ID: <Iz4-C6sUZjpp4MLo7EFlO_wM9Wh7nShbqkkHzx7Hw7o=.90ea4c6f-3e86-4a98-bd35-488c33e258bc@github.com>

On Wed, 23 Dec 2020 11:58:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could someone please help review this trivial change - just replace JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
>> 
>> Thanks,
>> Valerie
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review.

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

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

From valeriep at openjdk.java.net  Wed Dec 23 20:50:57 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 20:50:57 GMT
Subject: Integrated: 8258186: Replace use of JNI_COMMIT mode with mode 0
In-Reply-To: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
References: <suQetr-1R8QaWZvApYRXs4U67rZpMs-7XW1fRCFMk3Q=.2c6c70e3-2eb0-4f90-890c-3544231a3a95@github.com>
Message-ID: <d3y4Do_PLOekMyKVX0n5GcDafwPZEAsTqi1Dfuxz3s8=.640d7ce4-03a5-477e-adcb-06ac93ed86fe@github.com>

On Wed, 23 Dec 2020 02:13:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this trivial change - just replace JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: cd94606c
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd94606c
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8258186: Replace use of JNI_COMMIT mode with mode 0

Reviewed-by: xuelei, alanb

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

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

From weijun at openjdk.java.net  Wed Dec 23 22:39:58 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 23 Dec 2020 22:39:58 GMT
Subject: RFR: 8258851: Mismatch in SunPKCS11 provider registration
 properties and actual implementation
In-Reply-To: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>
References: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>
Message-ID: <CoF9_3pBNp90O9q8jYqH5BwGBWJz7XKhdMq--PSG2as=.db46bf7c-187c-48f1-98a4-c8519b39d6e2@github.com>

On Wed, 23 Dec 2020 19:15:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Max, can you help taking a look? This trivial change fixes the inconsistent registration properties to match the actual implementation.
> 
> In addition to the DH->EC KeyFactory inconsistency, the new test finds another MAC->Mac typo.
> Mach5 run is clean.
> Thanks,
> Valerie

Looks good.

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

Marked as reviewed by weijun (Reviewer).

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

From valeriep at openjdk.java.net  Wed Dec 23 22:39:59 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 22:39:59 GMT
Subject: RFR: 8258851: Mismatch in SunPKCS11 provider registration
 properties and actual implementation
In-Reply-To: <CoF9_3pBNp90O9q8jYqH5BwGBWJz7XKhdMq--PSG2as=.db46bf7c-187c-48f1-98a4-c8519b39d6e2@github.com>
References: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>
 <CoF9_3pBNp90O9q8jYqH5BwGBWJz7XKhdMq--PSG2as=.db46bf7c-187c-48f1-98a4-c8519b39d6e2@github.com>
Message-ID: <WrX5F19o8OojZtmzhB4ujBRkxtUa0ecCFtFDHTXdOjs=.961ab8d1-a661-45cc-ab33-b660879cc505@github.com>

On Wed, 23 Dec 2020 22:35:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Max, can you help taking a look? This trivial change fixes the inconsistent registration properties to match the actual implementation.
>> 
>> In addition to the DH->EC KeyFactory inconsistency, the new test finds another MAC->Mac typo.
>> Mach5 run is clean.
>> Thanks,
>> Valerie
>
> Looks good.

Thanks for review.

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

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

From valeriep at openjdk.java.net  Wed Dec 23 22:40:01 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Dec 2020 22:40:01 GMT
Subject: Integrated: 8258851: Mismatch in SunPKCS11 provider registration
 properties and actual implementation
In-Reply-To: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>
References: <YSLLZUNdG2Fers-UaibOIVg5Lg3JAmRZnDNvmYX64OU=.5fa77ffe-73e8-439b-8544-4fd0f1aa8863@github.com>
Message-ID: <fFklg35b26H3AsN-7PjWr8fjjyOOC6DOQ6c75CVUwMc=.8b8b37dd-f16b-4644-83c2-3ef726e240c1@github.com>

On Wed, 23 Dec 2020 19:15:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Max, can you help taking a look? This trivial change fixes the inconsistent registration properties to match the actual implementation.
> 
> In addition to the DH->EC KeyFactory inconsistency, the new test finds another MAC->Mac typo.
> Mach5 run is clean.
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 78c9fb92
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/78c9fb92
Stats:     83 lines in 2 files changed: 67 ins; 0 del; 16 mod

8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation

Reviewed-by: weijun

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

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

From mullan at openjdk.java.net  Thu Dec 24 15:02:56 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 24 Dec 2020 15:02:56 GMT
Subject: RFR: 8258852: Arrays.asList() for single item could be replaced
 with Collections.singletonList()
In-Reply-To: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>
References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>
Message-ID: <iwztcJqOwWNQcFB4UBvSv5-zqxqpQ0rnZD5SBubCjMM=.fb79a953-b362-44f3-b559-9bb44abb8965@github.com>

On Wed, 23 Dec 2020 00:56:25 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> If there is only one item, the call to Arrays.asList() could be replaced with Collections.singletonList() for less memory occupation.  This update also includes some other code cleanup, like redundant variables in the related files.
> 
> Code cleanup only, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258852

What about using List.of() instead?

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

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

From xuelei at openjdk.java.net  Thu Dec 24 17:33:56 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 24 Dec 2020 17:33:56 GMT
Subject: RFR: 8258852: Arrays.asList() for single item could be replaced
 with Collections.singletonList()
In-Reply-To: <iwztcJqOwWNQcFB4UBvSv5-zqxqpQ0rnZD5SBubCjMM=.fb79a953-b362-44f3-b559-9bb44abb8965@github.com>
References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>
 <iwztcJqOwWNQcFB4UBvSv5-zqxqpQ0rnZD5SBubCjMM=.fb79a953-b362-44f3-b559-9bb44abb8965@github.com>
Message-ID: <LLf7llbSDn-UvPPMrJuSab8rLbTlhpurnu4An-VbVK0=.85af70f2-acd1-47dc-a5c9-9067e30e1458@github.com>

On Thu, 24 Dec 2020 15:00:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> What about using List.of() instead?

For now, the Collections.singletonList() is more compact, which uses one class variable.  While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables.

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

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

From xuelei at openjdk.java.net  Thu Dec 24 22:00:03 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 24 Dec 2020 22:00:03 GMT
Subject: RFR: 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed out
Message-ID: <yR2x5JVN_6rl1XNwpMfxqSs6-erHvN2PxDHnbHt9S00=.f5f251ad-486a-4ea2-8ecc-489ce7855ec3@github.com>

The test javax/net/ssl/DTLS/RespondToRetransmit.java timed out intermittently.  This is a request to add "intermittent" tag to the test.

Test update, no new regression test.

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

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

Commit messages:
 - 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed out

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

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

From wetmore at openjdk.java.net  Thu Dec 24 22:34:53 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 24 Dec 2020 22:34:53 GMT
Subject: RFR: 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed
 out
In-Reply-To: <yR2x5JVN_6rl1XNwpMfxqSs6-erHvN2PxDHnbHt9S00=.f5f251ad-486a-4ea2-8ecc-489ce7855ec3@github.com>
References: <yR2x5JVN_6rl1XNwpMfxqSs6-erHvN2PxDHnbHt9S00=.f5f251ad-486a-4ea2-8ecc-489ce7855ec3@github.com>
Message-ID: <xvvLLOo8LDM5dcNvmQbvx1u030oV-7XnsCdEQffheJQ=.611a6c3d-2702-41b9-a71e-d9f859e672a8@github.com>

On Thu, 24 Dec 2020 21:55:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The test javax/net/ssl/DTLS/RespondToRetransmit.java timed out intermittently.  This is a request to add "intermittent" tag to the test.
> 
> Test update, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258914

Marked as reviewed by wetmore (Reviewer).

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

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

From xuelei at openjdk.java.net  Fri Dec 25 04:29:57 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 25 Dec 2020 04:29:57 GMT
Subject: Integrated: 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java
 timed out
In-Reply-To: <yR2x5JVN_6rl1XNwpMfxqSs6-erHvN2PxDHnbHt9S00=.f5f251ad-486a-4ea2-8ecc-489ce7855ec3@github.com>
References: <yR2x5JVN_6rl1XNwpMfxqSs6-erHvN2PxDHnbHt9S00=.f5f251ad-486a-4ea2-8ecc-489ce7855ec3@github.com>
Message-ID: <FZ7rJilf9C2h5H8aIzgoM2CPvdIUXxsWrQnN3IS6s3I=.3983a912-000f-4779-9fa6-b9f696c416ce@github.com>

On Thu, 24 Dec 2020 21:55:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The test javax/net/ssl/DTLS/RespondToRetransmit.java timed out intermittently.  This is a request to add "intermittent" tag to the test.
> 
> Test update, no new regression test.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258914

This pull request has now been integrated.

Changeset: b575dd80
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b575dd80
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed out

Reviewed-by: wetmore

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

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

From mbalao at openjdk.java.net  Mon Dec 28 16:30:07 2020
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 28 Dec 2020 16:30:07 GMT
Subject: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after
 failures
Message-ID: <PzX_1lG6n34oQg9tPPDnP2PED-XDfaAAJRbrqzJzets=.b33e5361-5e9d-492f-ad31-5c731a97e192@github.com>

When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an invalid block size), we now cancel the operation before returning the underlying Session to the Session Manager. This allows to use the returned Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error would be raised from the PKCS#11 library.

The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is introduced as part of this PR.

No regressions found in jdk/sun/security/pkcs11.

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

Commit messages:
 - Test for 8258833.
 - 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures

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

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

From thomas.fox at seitenbau.com  Sun Dec 27 09:54:58 2020
From: thomas.fox at seitenbau.com (Thomas Fox)
Date: Sun, 27 Dec 2020 10:54:58 +0100 (CET)
Subject: Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias method
Message-ID: <1224305522.1833518.1609062898520.JavaMail.zimbra@seitenbau.com>

Hello,

I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authentication and the client wants to choose which one of the available keys is used for the authentication.
The question is whether the SSL code should pass all possible key types in the argument keyType, or should it pass only one (probably the favoured key type???) in the argument keyType?
The javadoc of the argument says "keyType - the key algorithm type name(s), ordered with the most-preferred key type first.", which leaves a little room to interpretation (is it "all acceptable key algorithm type name(s)" or "a subset of all allowed key algorithm type name(s)"?).

Background is that the argument keyType passed by the SSL code is different between (A) openjdk 8u272 TLSv1.2 on the one hand and (B) openjdk 8u272 TLSv1.1, openjdk 8u265 TLSv1.1 and openjdk 8u265 TLSv1.2 on the other hand. In the former case (A), ["EC"] is passed as keyType, whereas in the latter case (B), ["RSA", "DSA", "EC"] is passed as key type, with no other changes except from JDK and TLS version. Note that in all cases, at least the key type "RSA" is acceptable as a key type. 
The question is if the behavior (A) is a bug (see [1]), because it does not contain the acceptable key type "RSA" (did not check whether DSA keys are also acceptable).

One implementation (Apache HttpClient 4.5.13 org.apache.http.conn.ssl.SSLContextBuilder.KeyManagerDelegate, [2]) uses the passed key types to find matching keys (it iterates over the passed key types and asks a delegate KeyManger for aliases for that key type). In case (1) this strategy fails if the keystore only contains a RSA key because RSA keys are never queried, although the RSA key can be used to authenticate to the server.
If (A) were correct, how could the implementation guess that it can also return a RSA key?

    Thanks,
        
            Thomas Fox

[1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200
[2] https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/conn/ssl/SSLContextBuilder.html#L221
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5461 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201227/9d31b6bc/smime.p7s>

From bradford.wetmore at oracle.com  Mon Dec 28 18:42:50 2020
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 28 Dec 2020 10:42:50 -0800
Subject: Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias
 method
In-Reply-To: <1224305522.1833518.1609062898520.JavaMail.zimbra@seitenbau.com>
References: <1224305522.1833518.1609062898520.JavaMail.zimbra@seitenbau.com>
Message-ID: <5476a1ca-a1fa-308c-8c7e-877235c586d9@oracle.com>

I haven't been following what OpenJDK has been doing recently, but IIRC, 
the original call includes all of the server's requested key types, 
copied directly from the CertificateRequest message.  See:

https://tools.ietf.org/rfcmarkup?doc=2246#section-7.4.4

Have a look at the current code:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CertificateRequest.java

See the T10CertificateRequestMessage(line 
182)/T10CertificateRequestConsumer(346) where the message is read off 
the wire, then is passed to chooseClientAlias(369) after checking for 
duplicates() and whether the algorithm is available.

It's similar but more involved for TLS12.

Brad




On 12/27/2020 1:54 AM, Thomas Fox wrote:
> Hello,
> 
> I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authentication and the client wants to choose which one of the available keys is used for the authentication.
> The question is whether the SSL code should pass all possible key types in the argument keyType, or should it pass only one (probably the favoured key type???) in the argument keyType?
> The javadoc of the argument says "keyType - the key algorithm type name(s), ordered with the most-preferred key type first.", which leaves a little room to interpretation (is it "all acceptable key algorithm type name(s)" or "a subset of all allowed key algorithm type name(s)"?).
> 
> Background is that the argument keyType passed by the SSL code is different between (A) openjdk 8u272 TLSv1.2 on the one hand and (B) openjdk 8u272 TLSv1.1, openjdk 8u265 TLSv1.1 and openjdk 8u265 TLSv1.2 on the other hand. In the former case (A), ["EC"] is passed as keyType, whereas in the latter case (B), ["RSA", "DSA", "EC"] is passed as key type, with no other changes except from JDK and TLS version. Note that in all cases, at least the key type "RSA" is acceptable as a key type.
> The question is if the behavior (A) is a bug (see [1]), because it does not contain the acceptable key type "RSA" (did not check whether DSA keys are also acceptable).
> 
> One implementation (Apache HttpClient 4.5.13 org.apache.http.conn.ssl.SSLContextBuilder.KeyManagerDelegate, [2]) uses the passed key types to find matching keys (it iterates over the passed key types and asks a delegate KeyManger for aliases for that key type). In case (1) this strategy fails if the keystore only contains a RSA key because RSA keys are never queried, although the RSA key can be used to authenticate to the server.
> If (A) were correct, how could the implementation guess that it can also return a RSA key?
> 
>      Thanks,
>          
>              Thomas Fox
> 
> [1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200
> [2] https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/conn/ssl/SSLContextBuilder.html#L221
> 

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 28 21:28:56 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 28 Dec 2020 21:28:56 GMT
Subject: RFR: 8258852: Arrays.asList() for single item could be replaced
 with Collections.singletonList()
In-Reply-To: <LLf7llbSDn-UvPPMrJuSab8rLbTlhpurnu4An-VbVK0=.85af70f2-acd1-47dc-a5c9-9067e30e1458@github.com>
References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>
 <iwztcJqOwWNQcFB4UBvSv5-zqxqpQ0rnZD5SBubCjMM=.fb79a953-b362-44f3-b559-9bb44abb8965@github.com>
 <LLf7llbSDn-UvPPMrJuSab8rLbTlhpurnu4An-VbVK0=.85af70f2-acd1-47dc-a5c9-9067e30e1458@github.com>
Message-ID: <5QV6qJNyyXaKCU4Vsd3AGriw-0YCj1rdPkcDps7znHY=.0ed64da5-6dc2-4eea-a0b9-987fe5afd0ca@github.com>

On Thu, 24 Dec 2020 17:30:41 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > What about using List.of() instead?
> 
> For now, the Collections.singletonList() is more compact, which uses one class variable. While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables.

There's one more issue about it: `List.of()` throws NPE when argument is `null` while `Collections.singletonList()` returns a list with `null` inside.

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

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

From redestad at openjdk.java.net  Tue Dec 29 01:20:55 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 29 Dec 2020 01:20:55 GMT
Subject: RFR: 8258852: Arrays.asList() for single item could be replaced
 with Collections.singletonList()
In-Reply-To: <5QV6qJNyyXaKCU4Vsd3AGriw-0YCj1rdPkcDps7znHY=.0ed64da5-6dc2-4eea-a0b9-987fe5afd0ca@github.com>
References: <9HNkwLLhSBbGa3uvGucoyQjk1B_fpJ1r-oDDL_-vxCc=.82753136-3464-4bf0-9813-61a290c57932@github.com>
 <iwztcJqOwWNQcFB4UBvSv5-zqxqpQ0rnZD5SBubCjMM=.fb79a953-b362-44f3-b559-9bb44abb8965@github.com>
 <LLf7llbSDn-UvPPMrJuSab8rLbTlhpurnu4An-VbVK0=.85af70f2-acd1-47dc-a5c9-9067e30e1458@github.com>
 <5QV6qJNyyXaKCU4Vsd3AGriw-0YCj1rdPkcDps7znHY=.0ed64da5-6dc2-4eea-a0b9-987fe5afd0ca@github.com>
Message-ID: <jPNiLLiyj0rZ5KadDD4MrSEk4p0FlB_XSM-GWfGgQXw=.13012153-ea69-4b8f-a45a-0b3251ad124d@github.com>

On Mon, 28 Dec 2020 21:25:57 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>>> What about using List.of() instead?
>> 
>> For now, the Collections.singletonList() is more compact, which uses one class variable.  While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables.
>
>> > What about using List.of() instead?
>> 
>> For now, the Collections.singletonList() is more compact, which uses one class variable. While List.of(T) shares the internal implementation with List.of(T t1, T t2), which uses two class variables.
> 
> There's one more issue about it: `List.of()` throws NPE when argument is `null` while `Collections.singletonList()` returns a list with `null` inside.

As @stsypanov points out the null-hostile behavior of the collection returned from `List.of()` can pose a compatibility issue: you'd have to guard against null inputs, and if the lists leak through public API then observable behavior might change in ways that are prohibitive. For the code in question it seem the lists are only created and passed around temporarily, mainly iterating over them. And it appears surrounding could would already throw NPEs if the values wrapped were ever null. So using `List.of` should be fine here.

As for the impl class for a single element `List.of()` having two fields then that should be footprint neutral since the second field will fit into an alignment gap. There should be no footprint advantage of using `Collections.singletonList`, which was verified by JOL[0] and by checking allocation pressure in microbenchmarks. IIRC this was the case on both on 64-bit and 32-bit VMs.

I favor `List.of` over `Collections` variants for making code more readable first. They _also_ make it easier to refactor (adding/removing items) without risking worse performance, which can more easily happen when mixing  `Collections.unmodifiable`, `.empty` and `singleton` (see: bi- and megamorphic call sites).

The code changes in this PR probably might make some difference from removing the need for a varargs array. But if the goal is to reduce allocation pressure of the methods involved there seem to be bigger fish to fry - such as the use of `LinkedList` in `KeyShareExtension`, and the nested for loops in `SSLConfiguration.getEnabledExtensions`. Are there any targeted microbenchmarks for these operations or do these operations have some weight in any of the existing micros?

[0] https://github.com/openjdk/jol

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

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

From thomas.fox at seitenbau.com  Wed Dec 30 09:56:20 2020
From: thomas.fox at seitenbau.com (Thomas Fox)
Date: Wed, 30 Dec 2020 10:56:20 +0100 (CET)
Subject: Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias
 method
In-Reply-To: <5476a1ca-a1fa-308c-8c7e-877235c586d9@oracle.com>
References: <1224305522.1833518.1609062898520.JavaMail.zimbra@seitenbau.com>
 <5476a1ca-a1fa-308c-8c7e-877235c586d9@oracle.com>
Message-ID: <1851426289.1909354.1609322180757.JavaMail.zimbra@seitenbau.com>

Thanks, Brad, for your answer.

I have looked at the source code and think I understand the TLS 1.0 code, but not the TLS 1.2 code
As my understanding of HTTPS is not firm, I put your answer in the observed context to make sure I understood correctly:

The client logs the following Certificate Request message (for TLS 1.2):
javax.net.ssl|FINE|01|main|2020-12-30 08:49:18.944 CET|Logger.java:765|Consuming CertificateRequest handshake message (
"CertificateRequest": {
  "certificate types": [rsa_sign, dss_sign, ecdsa_sign]
  "supported signature algorithms": [ecdsa_secp521r1_sha512, rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, rsa_pkcs1_sha384, ecdsa_secp256r1_sha256, rsa_pkcs1_sha256, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
  "certificate authorities": [CN=localhost, O=Seitenbau GmbH, L=Konstanz, ST=BW, C=DE]
}
)

Then, later in the code, the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket) is called on the Client's key manager to return the certificate to authenticate with.
As I understand it, the client JDK should pass ["RSA", "DSA", "EC"] as parameter keyType to the key manager.
Passing just ["EC"] as parameter keyType to the key manager, as observed in openjdk 8u272 is then a bug, as I understand it?
(As an aside, if the keyMananger is programmed such that it ignores the passed keyTypes["EC"] and presents a RSA key anyway, a successful SSL connection is established)

Thanks for bearing with my questions, I just want to make sure I do not miss anything and that [1] can be confirmed as a bug.

    Thomas 

[1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200

----- Urspr?ngliche Mail -----
Von: "Bradford Wetmore" <bradford.wetmore at oracle.com>
An: "Thomas Fox" <thomas.fox at seitenbau.com>, "security-dev" <security-dev at openjdk.java.net>
Gesendet: Montag, 28. Dezember 2020 19:42:50
Betreff: Re: Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias method

I haven't been following what OpenJDK has been doing recently, but IIRC, 
the original call includes all of the server's requested key types, 
copied directly from the CertificateRequest message.  See:

https://tools.ietf.org/rfcmarkup?doc=2246#section-7.4.4

Have a look at the current code:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/CertificateRequest.java

See the T10CertificateRequestMessage(line 
182)/T10CertificateRequestConsumer(346) where the message is read off 
the wire, then is passed to chooseClientAlias(369) after checking for 
duplicates() and whether the algorithm is available.

It's similar but more involved for TLS12.

Brad




On 12/27/2020 1:54 AM, Thomas Fox wrote:
> Hello,
> 
> I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authentication and the client wants to choose which one of the available keys is used for the authentication.
> The question is whether the SSL code should pass all possible key types in the argument keyType, or should it pass only one (probably the favoured key type???) in the argument keyType?
> The javadoc of the argument says "keyType - the key algorithm type name(s), ordered with the most-preferred key type first.", which leaves a little room to interpretation (is it "all acceptable key algorithm type name(s)" or "a subset of all allowed key algorithm type name(s)"?).
> 
> Background is that the argument keyType passed by the SSL code is different between (A) openjdk 8u272 TLSv1.2 on the one hand and (B) openjdk 8u272 TLSv1.1, openjdk 8u265 TLSv1.1 and openjdk 8u265 TLSv1.2 on the other hand. In the former case (A), ["EC"] is passed as keyType, whereas in the latter case (B), ["RSA", "DSA", "EC"] is passed as key type, with no other changes except from JDK and TLS version. Note that in all cases, at least the key type "RSA" is acceptable as a key type.
> The question is if the behavior (A) is a bug (see [1]), because it does not contain the acceptable key type "RSA" (did not check whether DSA keys are also acceptable).
> 
> One implementation (Apache HttpClient 4.5.13 org.apache.http.conn.ssl.SSLContextBuilder.KeyManagerDelegate, [2]) uses the passed key types to find matching keys (it iterates over the passed key types and asks a delegate KeyManger for aliases for that key type). In case (1) this strategy fails if the keystore only contains a RSA key because RSA keys are never queried, although the RSA key can be used to authenticate to the server.
> If (A) were correct, how could the implementation guess that it can also return a RSA key?
> 
>      Thanks,
>          
>              Thomas Fox
> 
> [1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200
> [2] https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/conn/ssl/SSLContextBuilder.html#L221
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5461 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20201230/a593580a/smime.p7s>

From jnimeh at openjdk.java.net  Wed Dec 30 23:33:14 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 30 Dec 2020 23:33:14 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
Message-ID: <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>

> This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.

Jamil Nimeh 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:

 - Merge
 - Change IO to use readExactlyNBytes method
 - Merge
 - 8179503: Java should support GET OCSP calls

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1760/files
  - new: https://git.openjdk.java.net/jdk/pull/1760/files/32a09875..d63cb0c8

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

  Stats: 19823 lines in 712 files changed: 13707 ins; 3342 del; 2774 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1760/head:pull/1760

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

From xuelei at openjdk.java.net  Thu Dec 31 05:10:00 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 31 Dec 2020 05:10:00 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
Message-ID: <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>

On Wed, 30 Dec 2020 23:33:14 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.
>
> Jamil Nimeh 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:
> 
>  - Merge
>  - Change IO to use readExactlyNBytes method
>  - Merge
>  - 8179503: Java should support GET OCSP calls

src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 235:

> 233: 
> 234:         URL url;
> 235:         HttpURLConnection con;

I was just wondering, if the new httpclient APIs could be used here?  Maybe it is a out of the scope of this update.

src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 237:

> 235:         HttpURLConnection con;
> 236:         String encodedGetReq = responderURI.toString() + "/" +
> 237:                 URLEncoder.encode(Base64.getMimeEncoder(0, new byte[0]).

I did not get the point to use MIME encoder.  Is the basic base64 encoder sufficient here?

src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 240:

> 238:                         encodeToString(bytes), "UTF-8");
> 239: 
> 240:         if (encodedGetReq.length() <= 255) {

If the request less than 256, the GET method will be used.  RFC 6960 declare this as a "MAY" feature ("To enable HTTP caching, small requests ... MAY be submitted using GET").  Although RFC 5019 declare it as a "MUST" feature  ("When sending requests that are less than or equal to 255 bytes ... clients MUST use the GET method"), but RFC 5109 is released before RFC 6960.  I'm not very sure if there is interop issues that a server may not accept the "Get" method for some reasons.  I don't worry about it too much, but just for sure you have considered the cases.

src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 275:

> 273:             contentLength = Integer.MAX_VALUE;
> 274:         }
> 275: 

Is there a leak if the URL connection is not closed?

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

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

From jnimeh at openjdk.java.net  Thu Dec 31 05:24:06 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 05:24:06 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
 <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
Message-ID: <EEQpqiXhwQkw4UqVtkSJMXLEypo2r-kGKyMoLh7xbd8=.e097eda0-9523-4e89-9f67-2fcd1137bc22@github.com>

On Thu, 31 Dec 2020 04:58:50 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Jamil Nimeh 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:
>> 
>>  - Merge
>>  - Change IO to use readExactlyNBytes method
>>  - Merge
>>  - 8179503: Java should support GET OCSP calls
>
> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 240:
> 
>> 238:                         encodeToString(bytes), "UTF-8");
>> 239: 
>> 240:         if (encodedGetReq.length() <= 255) {
> 
> If the request less than 256, the GET method will be used.  RFC 6960 declare this as a "MAY" feature ("To enable HTTP caching, small requests ... MAY be submitted using GET").  Although RFC 5019 declare it as a "MUST" feature  ("When sending requests that are less than or equal to 255 bytes ... clients MUST use the GET method"), but RFC 5109 is released before RFC 6960.  I'm not very sure if there is interop issues that a server may not accept the "Get" method for some reasons.  I don't worry about it too much, but just for sure you have considered the cases.

I've tried the GET code with various public OCSP responders as well as a few things like OpenSSL's ocsp command (1.1.1d) and Dogtag 10.  There is the potential for some compatibility issues, but I think it's pretty small.  For instance, OpenSSL's 1.0.2 and earlier's ocsp command running in daemon mode does not accept GET requests at all.  But with 1.1.0 and onward, GET is fully supported.  I don't think that specifically would be an issue in any large scale deployment - I doubt those large-scale implementations use something like openssl ocsp.  There are some clients like the OCSP stapling subsystem in Nginx that will use GETs for small requests also, so I would hope that server-side support would be pretty widespread by now (HTTP GET was even in RFC 2560).

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

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

From jnimeh at openjdk.java.net  Thu Dec 31 05:28:05 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 05:28:05 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
 <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
Message-ID: <a0C9BUVTFkCNd1BxxByLLwWmiHGW-pO5sSSEc6qYrEY=.2a97092c-de80-44a3-ab63-0f3e4a1f1727@github.com>

On Thu, 31 Dec 2020 05:06:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Jamil Nimeh 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:
>> 
>>  - Merge
>>  - Change IO to use readExactlyNBytes method
>>  - Merge
>>  - 8179503: Java should support GET OCSP calls
>
> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 275:
> 
>> 273:             contentLength = Integer.MAX_VALUE;
>> 274:         }
>> 275: 
> 
> Is there a leak if the URL connection is not closed?

>From looking at the javadoc for URLConnection, I think the close has to happen on the Input/OutputStreams.  I have the OutputStream inside a try-with-resources block.  But I think I need to do the same with the InputStream so both are closed at the end of the transaction.

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

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

From jnimeh at openjdk.java.net  Thu Dec 31 05:33:59 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 05:33:59 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
 <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
Message-ID: <mU4xfXoH1AP8fgft8bf1GxBKrNqi-dCw5TOjwzFLcik=.1088f6f2-baee-4beb-a652-5ca766c7a1cf@github.com>

On Thu, 31 Dec 2020 04:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Jamil Nimeh 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:
>> 
>>  - Merge
>>  - Change IO to use readExactlyNBytes method
>>  - Merge
>>  - 8179503: Java should support GET OCSP calls
>
> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 237:
> 
>> 235:         HttpURLConnection con;
>> 236:         String encodedGetReq = responderURI.toString() + "/" +
>> 237:                 URLEncoder.encode(Base64.getMimeEncoder(0, new byte[0]).
> 
> I did not get the point to use MIME encoder.  Is the basic base64 encoder sufficient here?

Force of habit.  I'm so used to using getMimeEncoder for other structures that need line breaks so I just stuck with it.  From the docs it looks like the basic one might work just fine.  The encoder returned by Base64.getUrlEncoder() definitely doesn't give me the encoding I want, which is why I went with the MIME encoder and then pushed it through URLEncoder.encode() to get the proper HTTP path string value.  I'll try it with the Basic base64 encoder, since that will simplify the code a bit.

> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 235:
> 
>> 233: 
>> 234:         URL url;
>> 235:         HttpURLConnection con;
> 
> I was just wondering, if the new httpclient APIs could be used here?  Maybe it is a out of the scope of this update.

It probably could be done, but HttpURLConnection has been working fine so I didn't see the need to change it.

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

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

From xuelei at openjdk.java.net  Thu Dec 31 06:06:56 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 31 Dec 2020 06:06:56 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <mU4xfXoH1AP8fgft8bf1GxBKrNqi-dCw5TOjwzFLcik=.1088f6f2-baee-4beb-a652-5ca766c7a1cf@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
 <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
 <mU4xfXoH1AP8fgft8bf1GxBKrNqi-dCw5TOjwzFLcik=.1088f6f2-baee-4beb-a652-5ca766c7a1cf@github.com>
Message-ID: <qmNWTkFXUCp0ZgoZ0Z2INxO4v4apO_9gqLPHorerCuE=.09c52388-ba6a-4fca-a08f-1b8f4ab1562d@github.com>

On Thu, 31 Dec 2020 05:31:21 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 235:
>> 
>>> 233: 
>>> 234:         URL url;
>>> 235:         HttpURLConnection con;
>> 
>> I was just wondering, if the new httpclient APIs could be used here?  Maybe it is a out of the scope of this update.
>
> It probably could be done, but HttpURLConnection has been working fine so I didn't see the need to change it.

HttpURLConnection run in block mode, which could be a problem for high volume environment.  But definitely, it is not the purpose of this update.

>> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 240:
>> 
>>> 238:                         encodeToString(bytes), "UTF-8");
>>> 239: 
>>> 240:         if (encodedGetReq.length() <= 255) {
>> 
>> If the request less than 256, the GET method will be used.  RFC 6960 declare this as a "MAY" feature ("To enable HTTP caching, small requests ... MAY be submitted using GET").  Although RFC 5019 declare it as a "MUST" feature  ("When sending requests that are less than or equal to 255 bytes ... clients MUST use the GET method"), but RFC 5109 is released before RFC 6960.  I'm not very sure if there is interop issues that a server may not accept the "Get" method for some reasons.  I don't worry about it too much, but just for sure you have considered the cases.
>
> I've tried the GET code with various public OCSP responders as well as a few things like OpenSSL's ocsp command (1.1.1d) and Dogtag 10.  There is the potential for some compatibility issues, but I think it's pretty small.  For instance, OpenSSL's 1.0.2 and earlier's ocsp command running in daemon mode does not accept GET requests at all.  But with 1.1.0 and onward, GET is fully supported.  I don't think that specifically would be an issue in any large scale deployment - I doubt those large-scale implementations use something like openssl ocsp.  There are some clients like the OCSP stapling subsystem in Nginx that will use GETs for small requests also, so I would hope that server-side support would be pretty widespread by now (HTTP GET was even in RFC 2560).

Hm, let's see if there is an interop issue in practice, before we think about a workaround.  Thank you!

>> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 275:
>> 
>>> 273:             contentLength = Integer.MAX_VALUE;
>>> 274:         }
>>> 275: 
>> 
>> Is there a leak if the URL connection is not closed?
>
> From looking at the javadoc for URLConnection, I think the close has to happen on the Input/OutputStreams.  I have the OutputStream inside a try-with-resources block.  But I think I need to do the same with the InputStream so both are closed at the end of the transaction.

I general consider to use HttpURLConnection.disconnect() and I/O close.  Per the  HttpURLConnection class specification, "Each HttpURLConnection instance is used to make a single request but the underlying network connection to the HTTP server may be transparently shared by other instances. Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection. Calling the disconnect() method may close the underlying socket if a persistent connection is otherwise idle at that time.".

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

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

From jnimeh at openjdk.java.net  Thu Dec 31 06:14:01 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 06:14:01 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v2]
In-Reply-To: <qmNWTkFXUCp0ZgoZ0Z2INxO4v4apO_9gqLPHorerCuE=.09c52388-ba6a-4fca-a08f-1b8f4ab1562d@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <kc30i1A0Xf3Cs5iw_nJQ_xfQBEcovLbUxVR8Jkvsg7g=.584d11e5-04f6-493e-8086-8c763e3a0141@github.com>
 <60wqwnpxeQRQ_cLcfn5TtAqa0HhllKUn_WUOEpAx3Ng=.191fd3ad-7b7a-4c29-aee1-10e33b62d496@github.com>
 <mU4xfXoH1AP8fgft8bf1GxBKrNqi-dCw5TOjwzFLcik=.1088f6f2-baee-4beb-a652-5ca766c7a1cf@github.com>
 <qmNWTkFXUCp0ZgoZ0Z2INxO4v4apO_9gqLPHorerCuE=.09c52388-ba6a-4fca-a08f-1b8f4ab1562d@github.com>
Message-ID: <qNcKP-s31o21-fZQAfRFlETpu28nO9pNvKJMR-nT5eY=.8fa6af06-2e36-4d0c-87d7-8f5dba958c70@github.com>

On Thu, 31 Dec 2020 06:03:26 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> From looking at the javadoc for URLConnection, I think the close has to happen on the Input/OutputStreams.  I have the OutputStream inside a try-with-resources block.  But I think I need to do the same with the InputStream so both are closed at the end of the transaction.
>
> I general consider to use HttpURLConnection.disconnect() and I/O close.  Per the  HttpURLConnection class specification, "Each HttpURLConnection instance is used to make a single request but the underlying network connection to the HTTP server may be transparently shared by other instances. Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection. Calling the disconnect() method may close the underlying socket if a persistent connection is otherwise idle at that time.".

In this case I don't think there's a shared persistent connection going on.  The URLConnection object's entire lifecycle is within this one method and for one connection only.  But I do see your point here.  Maybe a try-finally with the disconnect inside the finally might be cleaner instead of try-with-resources around each stream.  I'll give that a spin and see what happens.

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

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

From jnimeh at openjdk.java.net  Thu Dec 31 06:54:07 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 06:54:07 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v3]
In-Reply-To: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
Message-ID: <8RNUYgasYF9MuA0OFi02-xVvOXzm8Nx_P-ZXvW7QKgU=.46dab7f4-fd49-4ca5-8695-a2428745320e@github.com>

> This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.

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

  Use basic Base64 encoder and use HttpUrlConnection.disconnect to close resources

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1760/files
  - new: https://git.openjdk.java.net/jdk/pull/1760/files/d63cb0c8..8f0cfeb0

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

  Stats: 42 lines in 1 file changed: 7 ins; 1 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1760/head:pull/1760

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

From plevart at openjdk.java.net  Thu Dec 31 10:07:05 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 31 Dec 2020 10:07:05 GMT
Subject: RFR: 8259021 avoid double racy reads from non-volatile fields of
 SharedSecrets
Message-ID: <VkaRcc6Rsal_pvBfNP-rtC-VWd8MJ9eH7PHlkW0pSj4=.20a3f97b-f1be-422f-adc6-854ce9cf1519@github.com>

See: https://bugs.openjdk.java.net/browse/JDK-8259021
See also discussion in thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html

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

Commit messages:
 - 8259021 avoid double racy reads from non-volatile fields of SharedSecrets

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

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

From xuelei at openjdk.java.net  Thu Dec 31 17:36:02 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 31 Dec 2020 17:36:02 GMT
Subject: RFR: 8179503: Java should support GET OCSP calls [v3]
In-Reply-To: <8RNUYgasYF9MuA0OFi02-xVvOXzm8Nx_P-ZXvW7QKgU=.46dab7f4-fd49-4ca5-8695-a2428745320e@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
 <8RNUYgasYF9MuA0OFi02-xVvOXzm8Nx_P-ZXvW7QKgU=.46dab7f4-fd49-4ca5-8695-a2428745320e@github.com>
Message-ID: <kgJPqEvSyzjg_6jD0oCA8T0-Us5bCWjHDz0h1Ch70ms=.7f259311-7805-4e51-9090-d647f01d32e4@github.com>

On Thu, 31 Dec 2020 06:54:07 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use basic Base64 encoder and use HttpUrlConnection.disconnect to close resources

Looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From jnimeh at openjdk.java.net  Thu Dec 31 18:06:58 2020
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 31 Dec 2020 18:06:58 GMT
Subject: Integrated: 8179503: Java should support GET OCSP calls
In-Reply-To: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
References: <uhOvBVHpFMXM474TYSkTGF5w_Ll2qq_hEzn2Xe4b4XA=.d71ad106-fb59-4d2b-9bfc-7a8d93e27732@github.com>
Message-ID: <EXiYVAd8UKqDm17f11AlLdOPJxiovoS7jTgO0HT1Tes=.7649c4a9-d6d6-43ac-9942-9df75887ed0a@github.com>

On Sun, 13 Dec 2020 19:18:42 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This enhancement allows the underlying OCSP subsystem to submit OCSP requests using HTTP GET when the request is less than or equal to 255 bytes as documented in RFC 6960 and clarified in RFC 5019.

This pull request has now been integrated.

Changeset: f5ee3565
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5ee3565
Stats:     372 lines in 3 files changed: 318 ins; 39 del; 15 mod

8179503: Java should support GET OCSP calls

Reviewed-by: xuelei

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

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