From dfuchs at openjdk.org  Thu May  1 08:47:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 May 2025 08:47:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v4]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <pKoH3nSdX5785wl9WluGHMfUinFx1sRF9EcFMt_7iaE=.5b3fb398-b66d-43c9-88a0-463973bbee74@github.com>

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 412 commits:

 - merge latest changes from master branch
 - merge latest changes from master branch
 - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
 - merge latest changes from master branch
 - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - ... and 402 more: https://git.openjdk.org/jdk/compare/526951db...9156a51e

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=03
  Stats: 102846 lines in 472 files changed: 100217 ins; 1120 del; 1509 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From weijun at openjdk.org  Thu May  1 15:21:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 May 2025 15:21:46 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
Message-ID: <KjjDJEdE-DFjvgIv7T9KRv6Cg0_SqUWPTo8KYwPhVcE=.8fc20d8d-a09d-43ad-873a-92fb514474f2@github.com>

On Wed, 30 Apr 2025 23:38:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved too fast

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691:

> 1689:                 // ...now the final expand.
> 1690:                 SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length,
> 1691:                         "label");

Are you using "label" as the algorithm name for the output?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070397219

From abarashev at openjdk.org  Thu May  1 18:28:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 1 May 2025 18:28:47 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
Message-ID: <vWUO5wBIC57RcUPcb8sV6qagH1z13nmG8hSszkEO-_Y=.48f4fb0c-e70a-4d4a-ba41-e85b6a3086ca@github.com>

On Wed, 30 Apr 2025 23:38:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved too fast

test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 277:

> 275:     private static void runExporterTests(
> 276:             ExtendedSSLSession cessls,
> 277:             ExtendedSSLSession sessls) throws Exception {

Replace with `clientSession` and `serverSession` for readability?

test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 296:

> 294:         // Inputs exactly equal.  Use exportKeyMaterialKey()
> 295:         clientBytes = cessls.exportKeyMaterialKey("hello",
> 296:                 bytes, 128).getEncoded();

Should we add tests with EKM material length other than 128?

test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 324:

> 322:         serverBytes = sessls.exportKeyMaterialData("goodbye",
> 323:                 bytes, 128);
> 324:         if (Arrays.equals(clientBytes, serverBytes)) {

Replace with `assertEquals/assertNotEquals` this and other test cases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070621428
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070623132
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070624936

From wetmore at openjdk.org  Thu May  1 19:34:45 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 1 May 2025 19:34:45 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <KjjDJEdE-DFjvgIv7T9KRv6Cg0_SqUWPTo8KYwPhVcE=.8fc20d8d-a09d-43ad-873a-92fb514474f2@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
 <KjjDJEdE-DFjvgIv7T9KRv6Cg0_SqUWPTo8KYwPhVcE=.8fc20d8d-a09d-43ad-873a-92fb514474f2@github.com>
Message-ID: <iI5Yqfjh9xF_i7cyz-YpmLpqPxPLhHzU1iKHM-AFFmY=.71d8fea3-ae61-47b5-a607-5d1814afdd5b@github.com>

On Thu, 1 May 2025 15:18:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved too fast
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691:
> 
>> 1689:                 // ...now the final expand.
>> 1690:                 SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length,
>> 1691:                         "label");
> 
> Are you using "label" as the algorithm name for the output?

Egads...should be the label variable.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070703242

From wetmore at openjdk.org  Thu May  1 19:39:45 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 1 May 2025 19:39:45 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <vWUO5wBIC57RcUPcb8sV6qagH1z13nmG8hSszkEO-_Y=.48f4fb0c-e70a-4d4a-ba41-e85b6a3086ca@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
 <vWUO5wBIC57RcUPcb8sV6qagH1z13nmG8hSszkEO-_Y=.48f4fb0c-e70a-4d4a-ba41-e85b6a3086ca@github.com>
Message-ID: <uTxYn8gZFe39qCbX0ttL1b0TURTPBRKUQdzriuDnRWw=.a59a325e-28cb-46b8-8add-9adb276409d7@github.com>

On Thu, 1 May 2025 18:24:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved too fast
>
> test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 296:
> 
>> 294:         // Inputs exactly equal.  Use exportKeyMaterialKey()
>> 295:         clientBytes = cessls.exportKeyMaterialKey("hello",
>> 296:                 bytes, 128).getEncoded();
> 
> Should we add tests with EKM material length other than 128?

I have a difference test with 127 vs 128, but can add another equal key size for matching.  Say 40?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070707740

From wetmore at openjdk.org  Thu May  1 20:04:46 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 1 May 2025 20:04:46 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <vWUO5wBIC57RcUPcb8sV6qagH1z13nmG8hSszkEO-_Y=.48f4fb0c-e70a-4d4a-ba41-e85b6a3086ca@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
 <vWUO5wBIC57RcUPcb8sV6qagH1z13nmG8hSszkEO-_Y=.48f4fb0c-e70a-4d4a-ba41-e85b6a3086ca@github.com>
Message-ID: <hZGXy0pZFEBFyf7hx_1CRHPOdjD91KEg3PiCbal2da0=.ae2afa89-cb96-4ed8-bf09-7cd25db9b24c@github.com>

On Thu, 1 May 2025 18:26:03 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved too fast
>
> test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 324:
> 
>> 322:         serverBytes = sessls.exportKeyMaterialData("goodbye",
>> 323:                 bytes, 128);
>> 324:         if (Arrays.equals(clientBytes, serverBytes)) {
> 
> Replace with `assertEquals/assertNotEquals` this and other test cases?

I am used to writing standalone tests (old days before `test/lib`), but this is not a bad idea.  I used `assertEqualsByteArray`/`assertNotEqualsByteArray` for `byte[]` and `assertEquals` for `ints`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070734034

From wetmore at openjdk.org  Thu May  1 20:18:28 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 1 May 2025 20:18:28 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v4]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <JBgB9wRxxkbY02fmXrDUEpo8tQ4iEUDk8ZMvncXAUpI=.4a8e868d-c7f2-42d0-a3e3-6a1ba502df10@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Codereview comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/a0332f8e..bdd16052

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

  Stats: 70 lines in 2 files changed: 9 ins; 14 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From weijun at openjdk.org  Thu May  1 21:33:47 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 May 2025 21:33:47 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <iI5Yqfjh9xF_i7cyz-YpmLpqPxPLhHzU1iKHM-AFFmY=.71d8fea3-ae61-47b5-a607-5d1814afdd5b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>
 <KjjDJEdE-DFjvgIv7T9KRv6Cg0_SqUWPTo8KYwPhVcE=.8fc20d8d-a09d-43ad-873a-92fb514474f2@github.com>
 <iI5Yqfjh9xF_i7cyz-YpmLpqPxPLhHzU1iKHM-AFFmY=.71d8fea3-ae61-47b5-a607-5d1814afdd5b@github.com>
Message-ID: <orxsaGpqOKcpijbL8Jn67YfAhzKWVkFsw9tHbjAbPYs=.b2338a33-5a07-4af3-90fd-f6ba173035e4@github.com>

On Thu, 1 May 2025 19:32:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691:
>> 
>>> 1689:                 // ...now the final expand.
>>> 1690:                 SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length,
>>> 1691:                         "label");
>> 
>> Are you using "label" as the algorithm name for the output?
>
> Egads...should be the label variable.  Thanks.

I don't know whether label is always a legal algorithm name. PKCS #11 is especially picky at new names. The KDF `deriveKey` method contains the algorithm as an argument.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070833436

From vyazici at openjdk.org  Fri May  2 08:33:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 2 May 2025 08:33:33 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting based on
 "os.name" property value
Message-ID: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>

Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.

Note that `os.name` checks are replaced with `os.family` instead.

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

Commit messages:
 - Replace in-test `os.name` checks with `@requires`

Changes: https://git.openjdk.org/jdk/pull/24997/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355578
  Stats: 72 lines in 6 files changed: 9 ins; 55 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24997/head:pull/24997

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

From dfuchs at openjdk.org  Fri May  2 08:50:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 May 2025 08:50:45 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value
In-Reply-To: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
Message-ID: <Vfxxch8m26rwcBBO4Iaz_LnXVHk3xNenpbk9U-m0jho=.4167965e-ed52-48e9-a149-d4661b1ac4c0@github.com>

On Fri, 2 May 2025 08:26:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
> 
> Note that `os.name` checks are replaced with `os.family` instead.

test/jdk/java/net/MulticastSocket/PromiscuousIPv6.java line 27:

> 25:  * @test
> 26:  * @bug 8215294
> 27:  * @requires os.family == "linux" & !(os.version ~= "3\\.10\\.0.*")

Suggestion:

 * @requires os.family == "linux" & !(os.version ~= "3\.10\.0.*")
 * @comment This test should only be run on Linux.
 *          The behavior under test is known NOT to work on Linux 3.10.0* kernels.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24997#discussion_r2071295887

From vyazici at openjdk.org  Fri May  2 09:15:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 2 May 2025 09:15:24 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value [v2]
In-Reply-To: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
Message-ID: <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>

> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
> 
> Note that `os.name` checks are replaced with `os.family` instead.

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

  Document `@requires` rationale with `@comment`
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24997/files
  - new: https://git.openjdk.org/jdk/pull/24997/files/f468738c..242f0787

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

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

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

From mark.reinhold at oracle.com  Fri May  2 15:21:58 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Fri, 2 May 2025 15:21:58 +0000
Subject: New candidate JEP: 517: HTTP/3 for the HTTP Client API
Message-ID: <20250502152157.7141D813BFB@eggemoggin.niobe.net>

https://openjdk.org/jeps/517

  Summary: Update the HTTP Client API to support the HTTP/3 protocol, so
  that libraries and applications can interact with HTTP/3 servers with
  minimal code change.

- Mark

From swen at openjdk.org  Fri May  2 19:03:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 19:03:54 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v12]
In-Reply-To: <LAgWwvYwL1-tXHAjg59HnbyUSDTNRZKDPimciOGuy80=.5221050f-d18c-4d0b-8817-3146c178fa1c@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <LAgWwvYwL1-tXHAjg59HnbyUSDTNRZKDPimciOGuy80=.5221050f-d18c-4d0b-8817-3146c178fa1c@github.com>
Message-ID: <vgpSukzgjdo189bj55OCwhK5hM7c8ZrZvvY4eWB7oJQ=.4e44344e-867e-46be-95d0-4ddf03a73171@github.com>

On Fri, 25 Apr 2025 18:56:36 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move URL construction out of assertThrows

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 53:

> 51:     // by default and can be re-enabled by setting a system property
> 52:     private static boolean FTP_FALLBACK_ENABLED =
> 53:             Boolean.getBoolean("jdk.net.file.ftpfallback");

Suggestion:

    private static final boolean FTP_FALLBACK_ENABLED =
            Boolean.getBoolean("jdk.net.file.ftpfallback");

Add final here

test/jdk/sun/net/www/protocol/file/NonLocalFtpFallback.java line 182:

> 180:     @Test
> 181:     public void verifyFtpUnknownHost() throws IOException {
> 182:         URL url  = new URL("file://nonexistinghost/not-exist.txt");

Suggestion:

        URL url = new URL("file://nonexistinghost/not-exist.txt");

One more space

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2072029391
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2072031757

From eirbjo at openjdk.org  Fri May  2 20:00:17 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 2 May 2025 20:00:17 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v13]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <ie20B5Q0GsGGFz99Z6ThmPRBeYa7bemALzKYhsmhk9E=.6ea0df2e-45c9-4480-b5fe-d31755e8b16a@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Documents the new property in `net-properties.html` 
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update FileURLConnection.java
  
  Add final modifier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/8eac2ffd..58d14616

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=11-12

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

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

From eirbjo at openjdk.org  Fri May  2 20:32:27 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 2 May 2025 20:32:27 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v14]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Documents the new property in `net-properties.html` 
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra space
  
  Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/58d14616..451acdb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=12-13

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

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

From djelinski at openjdk.org  Mon May  5 05:31:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 May 2025 05:31:58 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v7]
In-Reply-To: <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
Message-ID: <hZx8JMbU5bM5N8_2HXxv_nAPEvUtEEcgUbIkQUTTMdA=.713e103e-6e50-4eca-9f0e-87b60be0ec73@github.com>

On Wed, 30 Apr 2025 09:30:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove localhost usage

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24569#issuecomment-2849949699

From djelinski at openjdk.org  Mon May  5 05:31:59 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 May 2025 05:31:59 GMT
Subject: Integrated: 8354276: Strict HTTP header validation
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <jvOCFIhGJeGfbqdPWi8UPSuYTNrMmuqoimA6FvwSBks=.87d3ce17-9357-46e7-9d19-5b599a161b34@github.com>

On Thu, 10 Apr 2025 11:37:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: c94a7ae1
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c94a7ae11e588250cd0eb064c3280afd580530ea
Stats:     266 lines in 6 files changed: 245 ins; 2 del; 19 mod

8354276: Strict HTTP header validation

Reviewed-by: dfuchs, jpai

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

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

From djelinski at openjdk.org  Mon May  5 08:52:50 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 May 2025 08:52:50 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
Message-ID: <XXknymXk3neCdMu8umO-MDK4SKbdiWkLh5bqRno-1ZU=.46c9e278-753c-4dc7-bb63-2b22a5cb110f@github.com>

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown.

Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart.

Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else?

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2850325489

From jpai at openjdk.org  Mon May  5 10:18:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 10:18:07 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException
Message-ID: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>

Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.

As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.

I will create a CSR once we settle on these changes.

tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

Commit messages:
 - update apiNote on SocketImpl
 - 8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException

Changes: https://git.openjdk.org/jdk/pull/25031/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356154
  Stats: 156 lines in 9 files changed: 37 ins; 57 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/25031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25031/head:pull/25031

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

From jpai at openjdk.org  Mon May  5 10:22:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 10:22:48 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <GwrjdwG2LV5IZ-bed3Z0cRRSkuAMBpYgEAiJb3hPHLs=.3f34706d-b343-4315-8398-65da9bc402ab@github.com>

On Mon, 5 May 2025 10:12:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 453:

> 451:     protected void create(boolean stream) throws IOException {
> 452:         if (!stream) {
> 453:             throw new IllegalArgumentException("datagram socket creation not supported");

My initial thought was to just `assert` the `stream` value here. Then I noticed the `test/jdk/java/net/SocketImpl/BadUsages.java` test (updated as part of this PR) and thought that it might be better to do an actual check here and have it throw `IllegalArgumentException`, to allow for this behaviour to be verified.

I however don't have a strong opinion about this. So if `assert` is enough, then I'll switch this to an assert and then remove the updated test method in the `BasUsages.java`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073193218

From alanb at openjdk.org  Mon May  5 10:54:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 May 2025 10:54:46 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException
In-Reply-To: <GwrjdwG2LV5IZ-bed3Z0cRRSkuAMBpYgEAiJb3hPHLs=.3f34706d-b343-4315-8398-65da9bc402ab@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <GwrjdwG2LV5IZ-bed3Z0cRRSkuAMBpYgEAiJb3hPHLs=.3f34706d-b343-4315-8398-65da9bc402ab@github.com>
Message-ID: <SB7nkpyDErwY01ZF8HVj3ES1PVr7Lap6sTY7J-INVfA=.241b5494-8b19-43db-9638-73e973227aa5@github.com>

On Mon, 5 May 2025 10:19:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 453:
> 
>> 451:     protected void create(boolean stream) throws IOException {
>> 452:         if (!stream) {
>> 453:             throw new IllegalArgumentException("datagram socket creation not supported");
> 
> My initial thought was to just `assert` the `stream` value here. Then I noticed the `test/jdk/java/net/SocketImpl/BadUsages.java` test (updated as part of this PR) and thought that it might be better to do an actual check here and have it throw `IllegalArgumentException`, to allow for this behaviour to be verified.
> 
> I however don't have a strong opinion about this. So if `assert` is enough, then I'll switch this to an assert and then remove the updated test method in the `BasUsages.java`.

This method can only throw IOException so I think it will need to throw IOException. It should happen of course, at least not unless we have a bug in the Socket code. Can you change the exception message to start with "Datagram socket ..." so it's consistent with the other exception messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073230057

From jpai at openjdk.org  Mon May  5 11:07:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 11:07:28 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v2]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <sQ-3JMXF4kKr42OWtDlhHW5cCVByRLDUnS-X6m9unKU=.46ce53ab-3e47-456e-b6cb-8cf7410b9d80@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  review suggestion - throw IOException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/47dca9cf..5e123087

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

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

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

From jpai at openjdk.org  Mon May  5 11:07:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 11:07:28 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v2]
In-Reply-To: <SB7nkpyDErwY01ZF8HVj3ES1PVr7Lap6sTY7J-INVfA=.241b5494-8b19-43db-9638-73e973227aa5@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <GwrjdwG2LV5IZ-bed3Z0cRRSkuAMBpYgEAiJb3hPHLs=.3f34706d-b343-4315-8398-65da9bc402ab@github.com>
 <SB7nkpyDErwY01ZF8HVj3ES1PVr7Lap6sTY7J-INVfA=.241b5494-8b19-43db-9638-73e973227aa5@github.com>
Message-ID: <9FOd_T9EcyfWRxQ1cqm324Wd4kGvypAfcqxypXf__II=.edee25ec-50dd-4eb6-9a00-839ad72eb926@github.com>

On Mon, 5 May 2025 10:52:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 453:
>> 
>>> 451:     protected void create(boolean stream) throws IOException {
>>> 452:         if (!stream) {
>>> 453:             throw new IllegalArgumentException("datagram socket creation not supported");
>> 
>> My initial thought was to just `assert` the `stream` value here. Then I noticed the `test/jdk/java/net/SocketImpl/BadUsages.java` test (updated as part of this PR) and thought that it might be better to do an actual check here and have it throw `IllegalArgumentException`, to allow for this behaviour to be verified.
>> 
>> I however don't have a strong opinion about this. So if `assert` is enough, then I'll switch this to an assert and then remove the updated test method in the `BasUsages.java`.
>
> This method can only throw IOException so I think it will need to throw IOException. It should happen of course, at least not unless we have a bug in the Socket code. Can you change the exception message to start with "Datagram socket ..." so it's consistent with the other exception messages.

Done - I've updated the PR to follow these suggestions. The `BadUsages` test passes with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073244098

From eirbjo at openjdk.org  Mon May  5 12:13:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 5 May 2025 12:13:46 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v2]
In-Reply-To: <sQ-3JMXF4kKr42OWtDlhHW5cCVByRLDUnS-X6m9unKU=.46ce53ab-3e47-456e-b6cb-8cf7410b9d80@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <sQ-3JMXF4kKr42OWtDlhHW5cCVByRLDUnS-X6m9unKU=.46ce53ab-3e47-456e-b6cb-8cf7410b9d80@github.com>
Message-ID: <2uoO2GAh-FEOpe9q3w9CUiVcsK5gDQGsgedNGC_53Do=.da4913c4-6c9c-45f2-bf52-73b0dcd9dcf3@github.com>

On Mon, 5 May 2025 11:07:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review suggestion - throw IOException

src/java.base/share/classes/java/net/SocketImpl.java line 85:

> 83:      * @apiNote
> 84:      * The {@link Socket} constructors to create a datagram socket
> 85:      * are deprecated for removal and have been respecified to throw

This seems to talk about past, current and future behavior.

I thought we try to keep specifications focused on current behavior, with the exception of deprecation warnings.

Would it be possible to reword this without mentioning the past, avoiding the ?have been respecified? part?

Interested users can always use release notes to observe history..?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073324977

From jpai at openjdk.org  Mon May  5 12:27:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 12:27:27 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v3]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  reword SocketImpl.create(...) API doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/5e123087..ad880d50

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

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

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

From jpai at openjdk.org  Mon May  5 12:27:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 12:27:27 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v2]
In-Reply-To: <2uoO2GAh-FEOpe9q3w9CUiVcsK5gDQGsgedNGC_53Do=.da4913c4-6c9c-45f2-bf52-73b0dcd9dcf3@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <sQ-3JMXF4kKr42OWtDlhHW5cCVByRLDUnS-X6m9unKU=.46ce53ab-3e47-456e-b6cb-8cf7410b9d80@github.com>
 <2uoO2GAh-FEOpe9q3w9CUiVcsK5gDQGsgedNGC_53Do=.da4913c4-6c9c-45f2-bf52-73b0dcd9dcf3@github.com>
Message-ID: <hy_tJS4opwKrcDxHwWtHS4Vr0A2eREl7cSdfvJIvpAo=.dcfddbd4-d7ce-46ee-ba9c-7b06f0088185@github.com>

On Mon, 5 May 2025 12:11:16 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review suggestion - throw IOException
>
> src/java.base/share/classes/java/net/SocketImpl.java line 85:
> 
>> 83:      * @apiNote
>> 84:      * The {@link Socket} constructors to create a datagram socket
>> 85:      * are deprecated for removal and have been respecified to throw
> 
> This seems to talk about past, current and future behavior.
> 
> I thought we try to keep specifications focused on current behavior, with the exception of deprecation warnings.
> 
> Would it be possible to reword this without mentioning the past, avoiding the ?have been respecified? part?
> 
> Interested users can always use release notes to observe history..?

Hello Eirik,

> This seems to talk about past, current and future behavior.
> ...
> Would it be possible to reword this without mentioning the past, avoiding the ?have been respecified? part?

That's a good point. I've now updated the PR to reword this. Hopefully that's better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073342198

From abarashev at openjdk.org  Mon May  5 13:42:50 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 5 May 2025 13:42:50 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <XXknymXk3neCdMu8umO-MDK4SKbdiWkLh5bqRno-1ZU=.46c9e278-753c-4dc7-bb63-2b22a5cb110f@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
 <XXknymXk3neCdMu8umO-MDK4SKbdiWkLh5bqRno-1ZU=.46c9e278-753c-4dc7-bb63-2b22a5cb110f@github.com>
Message-ID: <U3jMDbiuGFEF8Z9DoUescNNYnstYYFarx_0J17ZXDoA=.b4b25ccd-7202-4c94-a4c3-624e11ad4a8b@github.com>

On Mon, 5 May 2025 08:50:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown.

Yes, good point, thanks!

> 
> Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart.

I see. But at the same time my understanding is that PKIX KeyManager's boot-up should be faster because it doesn't cache the whole KeyStore.

> 
> Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else?

Yes, we fail on the server side if we can't offer a certificate passing peer-supported algorithms in "signature_algorithms_cert" extension.

I put together a prototype of yet another KeyManager which can be a compromise solution: it's basically a `SunX509` with algorithm constraints: #25016

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2851050257

From alanb at openjdk.org  Mon May  5 14:03:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 May 2025 14:03:48 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v3]
In-Reply-To: <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>
Message-ID: <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>

On Mon, 5 May 2025 12:27:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reword SocketImpl.create(...) API doc

src/java.base/share/classes/java/net/Socket.java line 384:

> 382:      * stream socket. Only stream socket creation is allowed. If the stream
> 383:      * argument is {@code false}, then this constructor throws
> 384:      * {@code IllegalArgumentException}.

I would be tempted to drop this paragraph and just change the description of the `@param stream` to say "must be true".

src/java.base/share/classes/java/net/SocketImpl.java line 90:

> 88:      * <p>
> 89:      * This method will be re-specified in a future release to not
> 90:      * support creating datagram sockets.

I think this could do with another round of rewording. I think I would say that the "stream" parameter provided a way in early JDK releases to create a Socket that used a datagram socket. It's no longer possible to do this and therefore this method will only be called by Socket with stream == false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073493924
PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073508394

From jpai at openjdk.org  Mon May  5 14:18:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 14:18:26 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v4]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  additional changes to SocketImpl.create(...) API javadoc based on review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/ad880d50..8e329ff6

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

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

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

From jpai at openjdk.org  Mon May  5 14:18:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 14:18:26 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v3]
In-Reply-To: <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>
 <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>
Message-ID: <IW8zn5-YR5insoW_n8mLZe7Rn90rHVF3Uh3WA0WW39c=.7a648b5c-2cce-4b78-8eec-6c7a169d6f74@github.com>

On Mon, 5 May 2025 14:00:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reword SocketImpl.create(...) API doc
>
> src/java.base/share/classes/java/net/SocketImpl.java line 90:
> 
>> 88:      * <p>
>> 89:      * This method will be re-specified in a future release to not
>> 90:      * support creating datagram sockets.
> 
> I think this could do with another round of rewording. I think I would say that the "stream" parameter provided a way in early JDK releases to create a Socket that used a datagram socket. It's no longer possible to do this and therefore this method will only be called by Socket with stream == false.

I pushed a change to take these suggestions. I did some minor changes to the wording. Do you recommend any further changes to that text?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2073536109

From duke at openjdk.org  Tue May  6 04:25:26 2025
From: duke at openjdk.org (duke)
Date: Tue, 6 May 2025 04:25:26 GMT
Subject: Withdrawn: 8337143: (fc, fs) Move filesystem-related native objects
 from libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <DKSRbY-vFfCNA5WktntFIaVut3S3vBgbvBAFoWK-STg=.6706b813-923e-4f1c-b39d-9623ab6888d0@github.com>

On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue May  6 04:48:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 04:48:23 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v4]
In-Reply-To: <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>
Message-ID: <Bi3bUWQMCoBxhchgYpLods4JtIxNJPCkGLFnZqtzHxQ=.9948bafe-96fa-40b1-9c0f-4e21754d9e0e@github.com>

On Mon, 5 May 2025 14:18:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional changes to SocketImpl.create(...) API javadoc based on review suggestions

I've created a CSR https://bugs.openjdk.org/browse/JDK-8356225 and is ready for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25031#issuecomment-2853264676

From alanb at openjdk.org  Tue May  6 06:35:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 May 2025 06:35:17 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v3]
In-Reply-To: <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>
 <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>
Message-ID: <bVOHbFCLGxTKezCE1BG-lgP2usrYLZ2AY6ArVjkjzmc=.f2dddc0b-9986-46cc-8189-c69a9ceea0eb@github.com>

On Mon, 5 May 2025 13:52:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reword SocketImpl.create(...) API doc
>
> src/java.base/share/classes/java/net/Socket.java line 384:
> 
>> 382:      * stream socket. Only stream socket creation is allowed. If the stream
>> 383:      * argument is {@code false}, then this constructor throws
>> 384:      * {@code IllegalArgumentException}.
> 
> I would be tempted to drop this paragraph and just change the description of the `@param stream` to say "must be true".

I re-read this paragraph again today and I think it would be better to remove it completely from both constructors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074807828

From alanb at openjdk.org  Tue May  6 06:35:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 May 2025 06:35:18 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v4]
In-Reply-To: <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>
Message-ID: <NkfI2jAQWqWdxLu-AZS7JbhDeCCT0ZoeF4bni_ir2dc=.31c6a10d-9826-4462-8dc0-9a304f3a0cf2@github.com>

On Mon, 5 May 2025 14:18:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional changes to SocketImpl.create(...) API javadoc based on review suggestions

src/java.base/share/classes/java/net/Socket.java line 394:

> 392:      * @param      host     the host name, or {@code null} for the loopback address.
> 393:      * @param      port     the port number.
> 394:      * @param      stream   a {@code boolean} indicating whether this is

I think the parameter description has to be changed as it no longer indicates if the socket is a stream or datatgram socket. I think you can replace with something simple, like must be true, false is not allowed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074809933

From jpai at openjdk.org  Tue May  6 07:26:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 07:26:05 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v5]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <XnoqPZpcI7ABDgYsUvrwt6wS7q4uIf7tDgHuJc4NIMc=.eff16bd2-10e2-4f81-9ad0-b54585601d60@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  Alan's review suggestion - simplify Socket constructor API documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/8e329ff6..9d41bbef

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

  Stats: 58 lines in 3 files changed: 44 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25031/head:pull/25031

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

From jpai at openjdk.org  Tue May  6 07:26:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 07:26:07 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v3]
In-Reply-To: <bVOHbFCLGxTKezCE1BG-lgP2usrYLZ2AY6ArVjkjzmc=.f2dddc0b-9986-46cc-8189-c69a9ceea0eb@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <Xxw3xdcxrjeVnRO-byYdWRrYXBdepANOgBdWPnBMylc=.4aff752b-224e-44e8-bb26-0e72dd9cfa45@github.com>
 <lS0yVT5pCsqpwIo-Tg6xzS-LkXTxMiH-Amf_Gjfj5j0=.25d73c38-2f1d-49b1-85bc-7da5f217fe58@github.com>
 <bVOHbFCLGxTKezCE1BG-lgP2usrYLZ2AY6ArVjkjzmc=.f2dddc0b-9986-46cc-8189-c69a9ceea0eb@github.com>
Message-ID: <n_Wq5YNy793vTSo8H4XOCo5MgkHAMdqdRQHC4pHObIU=.e8e6c1c9-5060-4930-9a9f-7056c857e95f@github.com>

On Tue, 6 May 2025 06:30:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 384:
>> 
>>> 382:      * stream socket. Only stream socket creation is allowed. If the stream
>>> 383:      * argument is {@code false}, then this constructor throws
>>> 384:      * {@code IllegalArgumentException}.
>> 
>> I would be tempted to drop this paragraph and just change the description of the `@param stream` to say "must be true".
>
> I re-read this paragraph again today and I think it would be better to remove it completely from both constructors.

In my previous round I misread that the review comment was on SocketImpl class, so I never did apply the review changes on these `Socket` constructor. 

I've now updated the PR to drop this paragraph from both these constructors. I'll update the CSR if this and the rest changes look good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074868700

From jpai at openjdk.org  Tue May  6 07:26:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 07:26:09 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v4]
In-Reply-To: <NkfI2jAQWqWdxLu-AZS7JbhDeCCT0ZoeF4bni_ir2dc=.31c6a10d-9826-4462-8dc0-9a304f3a0cf2@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <BqaEpVq6sZ63aWKmk1Vg9AON7aSOeYRIqAD12ef8a1E=.1d06e12d-075a-474d-8c2f-84737c01c286@github.com>
 <NkfI2jAQWqWdxLu-AZS7JbhDeCCT0ZoeF4bni_ir2dc=.31c6a10d-9826-4462-8dc0-9a304f3a0cf2@github.com>
Message-ID: <q8dCyBFSYDc2uB2iX1MlRG70thzj9qEg9bNd2Q7qQBM=.d5952542-e93f-4942-90b9-8cf76ee62864@github.com>

On Tue, 6 May 2025 06:32:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional changes to SocketImpl.create(...) API javadoc based on review suggestions
>
> src/java.base/share/classes/java/net/Socket.java line 394:
> 
>> 392:      * @param      host     the host name, or {@code null} for the loopback address.
>> 393:      * @param      port     the port number.
>> 394:      * @param      stream   a {@code boolean} indicating whether this is
> 
> I think the parameter description has to be changed as it no longer indicates if the socket is a stream or datatgram socket. I think you can replace with something simple, like must be true, false is not allowed.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074865018

From alanb at openjdk.org  Tue May  6 08:07:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 May 2025 08:07:16 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v5]
In-Reply-To: <XnoqPZpcI7ABDgYsUvrwt6wS7q4uIf7tDgHuJc4NIMc=.eff16bd2-10e2-4f81-9ad0-b54585601d60@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <XnoqPZpcI7ABDgYsUvrwt6wS7q4uIf7tDgHuJc4NIMc=.eff16bd2-10e2-4f81-9ad0-b54585601d60@github.com>
Message-ID: <Uf7VVq_dVyNyop16hh15tU6zXJhPUiAHW2XCMyeNuUY=.89ebbe92-4a0a-4a06-8073-75941d48150d@github.com>

On Tue, 6 May 2025 07:26:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review suggestion - simplify Socket constructor API documentation

src/java.base/share/classes/java/net/Socket.java line 384:

> 382:      * stream socket. If the stream argument is {@code false}, it
> 383:      * creates a datagram socket.
> 384:      * <p>

One final though on the Socket changes is that maybe we should include an API note to say that the stream parameter provided a way in early JDK releases to create a Socket that used a datagram socket, this feature no longer exists.

src/java.base/share/classes/java/net/SocketImpl.java line 86:

> 84:      * The {@code stream} parameter provided a way in early JDK releases
> 85:      * to create a {@link Socket} that used a datagram socket.
> 86:      * It is no longer possible to do that and therefore this method will

"It is no longer possible to do that ...", can you try changing this to "The Socket API no longer provides a way to do this so the create method will ways to be called with a stream value of true". I think it might be a bit easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074943962
PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2074941652

From jpai at openjdk.org  Tue May  6 09:08:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 09:08:22 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v6]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <LwIfvv4lzN80R_c2pmnmkJ0mJ2ybnCtxiWUNQoonPz0=.b0fe7791-c62b-4a47-b77d-8a9d4924dd7c@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  additional updates to apiNotes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/9d41bbef..19cba4d1

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

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

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

From jpai at openjdk.org  Tue May  6 09:08:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 09:08:23 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v6]
In-Reply-To: <Uf7VVq_dVyNyop16hh15tU6zXJhPUiAHW2XCMyeNuUY=.89ebbe92-4a0a-4a06-8073-75941d48150d@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <XnoqPZpcI7ABDgYsUvrwt6wS7q4uIf7tDgHuJc4NIMc=.eff16bd2-10e2-4f81-9ad0-b54585601d60@github.com>
 <Uf7VVq_dVyNyop16hh15tU6zXJhPUiAHW2XCMyeNuUY=.89ebbe92-4a0a-4a06-8073-75941d48150d@github.com>
Message-ID: <FLcMBKeFJC5FKjys8h-iPFU2TIHNQwAmPywALOZQL88=.efa31003-0c65-4ea4-9488-1b4bbb162fe9@github.com>

On Tue, 6 May 2025 08:05:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional updates to apiNotes
>
> src/java.base/share/classes/java/net/Socket.java line 384:
> 
>> 382:      * stream socket. If the stream argument is {@code false}, it
>> 383:      * creates a datagram socket.
>> 384:      * <p>
> 
> One final though on the Socket changes is that maybe we should include an API note to say that the stream parameter provided a way in early JDK releases to create a Socket that used a datagram socket, this feature no longer exists.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075041966

From jpai at openjdk.org  Tue May  6 09:08:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 09:08:25 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v5]
In-Reply-To: <Uf7VVq_dVyNyop16hh15tU6zXJhPUiAHW2XCMyeNuUY=.89ebbe92-4a0a-4a06-8073-75941d48150d@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <XnoqPZpcI7ABDgYsUvrwt6wS7q4uIf7tDgHuJc4NIMc=.eff16bd2-10e2-4f81-9ad0-b54585601d60@github.com>
 <Uf7VVq_dVyNyop16hh15tU6zXJhPUiAHW2XCMyeNuUY=.89ebbe92-4a0a-4a06-8073-75941d48150d@github.com>
Message-ID: <8UhxkQ5mFn4EK9ytWaDQff95UwJAcUjKG1GORUPiei8=.f7e26903-e87a-44dc-8f71-574d01ed91a4@github.com>

On Tue, 6 May 2025 08:03:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's review suggestion - simplify Socket constructor API documentation
>
> src/java.base/share/classes/java/net/SocketImpl.java line 86:
> 
>> 84:      * The {@code stream} parameter provided a way in early JDK releases
>> 85:      * to create a {@link Socket} that used a datagram socket.
>> 86:      * It is no longer possible to do that and therefore this method will
> 
> "It is no longer possible to do that ...", can you try changing this to "The Socket API no longer provides a way to do this so the create method will ways to be called with a stream value of true". I think it might be a bit easier to read.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075042155

From jpai at openjdk.org  Tue May  6 09:11:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 09:11:32 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v7]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  remove unintentional file additions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/19cba4d1..ac71c8a6

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

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

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

From alanb at openjdk.org  Tue May  6 10:13:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 May 2025 10:13:14 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v7]
In-Reply-To: <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>
Message-ID: <qb1RuqG-OUgrEjxZLClpOflhETWH5qya9rnaj4D3zyE=.5dd33989-5468-4448-b50f-d718adbb79b9@github.com>

On Tue, 6 May 2025 09:11:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unintentional file additions

Spec + implementation changes looks fine, I have not spent time on the test changes.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25031#pullrequestreview-2817687955

From myankelevich at openjdk.org  Tue May  6 10:32:20 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 6 May 2025 10:32:20 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
Message-ID: <LcthEUrHxAdLU-17ezVFiwnxUA8x3b0PaDoF5Zuw7bk=.067dfcf0-b292-4911-9b1d-43f3f9170b62@github.com>

On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment changes

Still needs a security libraries approval

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2854061886

From pminborg at openjdk.org  Tue May  6 11:48:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:13 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field
 evaluations
Message-ID: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>

This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

Commit messages:
 - Address comments
 - Document field alignment assumption
 - Add unhecked call test
 - Move raw factories into inner class Raw
 - Add copyright header and revert unintended change
 - Add examples to doc and fix tests
 - Add @Stable for URI and add benchmark
 - Rename classes
 - Initial commit

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

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

From pminborg at openjdk.org  Tue May  6 11:48:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:16 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
Message-ID: <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>

On Mon, 5 May 2025 15:04:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> src/java.base/share/classes/java/lang/reflect/Method.java line 101:
> 
>> 99: 
>> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
>> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {
> 
> If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?

Do you mean for interacting with the field or computing the hash?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075052972

From liach at openjdk.org  Tue May  6 11:48:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 11:48:14 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/lang/reflect/Method.java line 101:

> 99: 
> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {

If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?

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

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2815145097
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2073631615

From pminborg at openjdk.org  Tue May  6 11:48:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:15 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <MJn1nqjbkTUI6g___10iB-FS5guVRVavCr4OR_VHavw=.3641ea1d-35df-4782-a2a6-5a705731adb9@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Benchmarks:


Benchmark                        Mode  Cnt  Score   Error  Units
StableUpdatersBenchmark.base     avgt   10  0.715 ? 0.026  ns/op
StableUpdatersBenchmark.updater  avgt   10  0.716 ? 0.079  ns/op


Which shows the updater has the same performance as imperative code which is good.

Updated benchmarks:


Benchmark                              Mode  Cnt  Score   Error  Units
StableUpdatersBenchmark.base           avgt   10  0.838 ? 0.041  ns/op
StableUpdatersBenchmark.baseStatic     avgt   10  0.759 ? 0.088  ns/op
StableUpdatersBenchmark.updater        avgt   10  0.888 ? 0.086  ns/op
StableUpdatersBenchmark.updaterStatic  avgt   10  0.753 ? 0.017  ns/op
StableUpdatersBenchmark.uri            avgt   10  0.781 ? 0.206  ns/op
StableUpdatersBenchmark.uriStatic      avgt   10  0.724 ? 0.048  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2851073331
PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2853800652

From liach at openjdk.org  Tue May  6 11:48:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 11:48:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
Message-ID: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>

On Tue, 6 May 2025 09:09:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Method.java line 101:
>> 
>>> 99: 
>>> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
>>> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {
>> 
>> If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?
>
> Do you mean for interacting with the field or computing the hash?

Calling the method that computes hash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075217957

From pminborg at openjdk.org  Tue May  6 11:48:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
Message-ID: <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>

On Tue, 6 May 2025 10:55:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do you mean for interacting with the field or computing the hash?
>
> Calling the method that computes hash.

This would require another implementation to be written. Maybe we can add that later?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075271947

From swen at openjdk.org  Tue May  6 11:48:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 11:48:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <uTpZhE_J5JG9s5UyR21V_BmrjSJVgKBJhEnV2-pOB64=.d40513ae-9fe0-40e5-9123-bbd79252ab37@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

src/java.base/share/classes/java/lang/reflect/Method.java line 105:

> 103:                 public int applyAsInt(Method method) {
> 104:                     return method.getDeclaringClass().getName().hashCode() ^ method.getName()
> 105:                             .hashCode();

Suggestion:

                    return method.getDeclaringClass().getName().hashCode() 
                                             ^ method.getName().hashCode();

code indentation alignment

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 330:

> 328:                 throw illegalField("non final fields", field);
> 329:             }
> 330:             sun.reflect.misc.ReflectUtil.ensureMemberAccess(

Why not use import here but use the full path?

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 350:

> 348:         }
> 349:         final Field[] fields = holderType.getDeclaredFields();
> 350:         for (Field f : fields) {

Suggestion:

        for (Field f : holderType.getDeclaredFields()) {

The local variable fields is only used once and can be simplified

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 132:

> 130:                     Objects.equals(this.bar, that.bar) &&
> 131:                     Objects.equals(this.baz, that.baz);
> 132:         }

Suggestion:

        public boolean equals(Object o) {
            return o instanceof Foo that
                    && Objects.equals(this.bar, that.bar)
                    && Objects.equals(this.baz, that.baz);
        }

In most cases in JDK code, the operator `&&` is placed in front.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075244737
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075229805
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075234183
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075239678

From liach at openjdk.org  Tue May  6 12:26:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 12:26:13 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
 <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
Message-ID: <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>

On Tue, 6 May 2025 11:33:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Calling the method that computes hash.
>
> This would require another implementation to be written. Maybe we can add that later?

I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075357802

From michaelm at openjdk.org  Tue May  6 13:14:29 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 6 May 2025 13:14:29 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v7]
In-Reply-To: <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>
Message-ID: <g_4oDNxXzxxe-rIFhHfAOuKFOaF1YMc7zW1M7CFYGjo=.d5126b4f-8713-4785-9093-2443075c0ca7@github.com>

On Tue, 6 May 2025 09:11:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unintentional file additions

src/java.base/share/classes/java/net/Socket.java line 390:

> 388:      * The {@code stream} parameter provided a way in early JDK releases
> 389:      * to create a {@code Socket} that used a datagram socket, this feature
> 390:      * no longer exists.

Suggestion:

     * to create a {@code Socket} that used a datagram socket. This feature
     * no longer exists.

src/java.base/share/classes/java/net/Socket.java line 422:

> 420:      * The {@code stream} parameter provided a way in early JDK releases
> 421:      * to create a {@code Socket} that used a datagram socket, this feature
> 422:      * no longer exists.

Suggestion:

     * to create a {@code Socket} that used a datagram socket. This feature
     * no longer exists.

src/java.base/share/classes/java/net/Socket.java line 455:

> 453:         if (!stream) {
> 454:             throw new IllegalArgumentException(
> 455:                     "Socket constructor does not support creation of datagram socket");

Suggestion:

                    "Socket constructor does not support creation of datagram sockets");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075440810
PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075441407
PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075443704

From jpai at openjdk.org  Tue May  6 13:24:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 13:24:55 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  Michael's review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/ac71c8a6..4cbe5178

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

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

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

From jpai at openjdk.org  Tue May  6 13:28:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 13:28:18 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v7]
In-Reply-To: <g_4oDNxXzxxe-rIFhHfAOuKFOaF1YMc7zW1M7CFYGjo=.d5126b4f-8713-4785-9093-2443075c0ca7@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <GAZFVflcT7Ju36z1itKPO0SydcvRrNSkFbFcr5_sr60=.420906c0-aa30-4831-9206-18a93a0e5fe0@github.com>
 <g_4oDNxXzxxe-rIFhHfAOuKFOaF1YMc7zW1M7CFYGjo=.d5126b4f-8713-4785-9093-2443075c0ca7@github.com>
Message-ID: <VACX4RoobUFDayASbVDxJQJtC4x9E24Hv3HTLzgUtr8=.8b011288-b70f-4f18-bae2-968281a06a17@github.com>

On Tue, 6 May 2025 13:08:46 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unintentional file additions
>
> src/java.base/share/classes/java/net/Socket.java line 455:
> 
>> 453:         if (!stream) {
>> 454:             throw new IllegalArgumentException(
>> 455:                     "Socket constructor does not support creation of datagram socket");
> 
> Suggestion:
> 
>                     "Socket constructor does not support creation of datagram sockets");

Thank you Michael, I updated the PR with all 3 suggestions. The CSR text too has been updated with this minor update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075475704

From duke at openjdk.org  Tue May  6 14:15:15 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 6 May 2025 14:15:15 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <Iknbm8JxHBTXEwLK4nfHGJto1ZICzXA-vwCGXYXT5Dg=.ab0b6189-682e-4293-88f3-bf4b169ac78e@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 214:

> 212:             }
> 213:             Objects.requireNonNull(underlying);
> 214:             return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);

This?should probably?construct `TearingStableLongFieldUpdater` on?32?bit?platforms:
Suggestion:

            if (Architecture.is64bit()) {
                // We are also relying on the fact that the VM will not place 64-bit
                // instance fields that can cross cache lines.
                return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);
            } else {
                return new TearingStableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075572314

From eirbjo at openjdk.org  Tue May  6 14:29:21 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 6 May 2025 14:29:21 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v14]
In-Reply-To: <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
Message-ID: <NwHqAmORlviWuDdJOliLe9Xx-MNCcmizsWuU4ueU6zA=.6ad5a13c-02e5-4309-8203-c80a2f46d2da@github.com>

On Fri, 2 May 2025 20:32:27 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

The CSR for this change has been approved. The Release Note has also been updated by more than one reviewer.

I don?t have any outstanding work for this PR on my side, unless there is more input from reviewers.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2854780332

From pminborg at openjdk.org  Tue May  6 14:40:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 14:40:46 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Fix raw long updater under 32-bit mode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/33e1779c..52e96c52

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

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

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

From dfuchs at openjdk.org  Tue May  6 15:25:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 May 2025 15:25:21 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
Message-ID: <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>

On Tue, 6 May 2025 13:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Michael's review suggestions

src/java.base/share/classes/java/net/Socket.java line 390:

> 388:      * The {@code stream} parameter provided a way in early JDK releases
> 389:      * to create a {@code Socket} that used a datagram socket. This feature
> 390:      * no longer exists.

Should we also re-iterate here that this constructor is deprecated? It kind of feels like this information should be in `@deprecated` instead, or that it should say that IAE is being thrown...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2075720161

From dfuchs at openjdk.org  Tue May  6 15:39:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 May 2025 15:39:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
Message-ID: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>

On Tue, 6 May 2025 14:40:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix raw long updater under 32-bit mode

src/java.base/share/classes/java/net/URI.java line 558:

> 556: 
> 557:     // Used reflectively by HASH_UPDATER
> 558:     @Stable

What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075743220

From dfuchs at openjdk.org  Tue May  6 15:42:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 May 2025 15:42:22 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v14]
In-Reply-To: <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
Message-ID: <Jo2O0EsrBlCmd_TZujBcae71aEdZ-iHqcQ48Ssbf_AQ=.5fb7e096-0a97-411a-820e-49823e03fc08@github.com>

On Fri, 2 May 2025 20:32:27 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24657#pullrequestreview-2818757472

From bpb at openjdk.org  Tue May  6 20:14:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 May 2025 20:14:05 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v13]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <EY-hJf2eWdC0OKZlwdSbYK3McMx9nH12m8jfGfXGYKc=.5969f5c1-6eca-451f-aa20-4f1065260a9f@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9477c422...da21fa69

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=12
  Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From wetmore at openjdk.org  Wed May  7 04:25:05 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 7 May 2025 04:25:05 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v5]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <4w6IRPy7N721Ygbl6G52VIhCLavhmiCeNnPrIQ8nODE=.6cd04cf5-eacf-43ee-b9be-f334b45f6fb9@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

 - More codereview/CSR comments
 - Merge branch 'master' into JDK-8341346
 - Codereview comments.
 - Moved too fast
 - Tweak API to be more KDF like in unextractable case.
 - 8341346: Add support for exporting TLS Keying Material

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/bdd16052..64d46d9a

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

  Stats: 10841 lines in 390 files changed: 7457 ins; 2245 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Wed May  7 05:08:00 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 7 May 2025 05:08:00 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v6]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <-Lq3gSKL61DrTHJMeowgZ-a_sDof776MuXk63TvswC8=.fcea32f2-002e-4390-9a97-b3e299837a79@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Add in the SharedSecrets SecretKeySpec clearing mechanism

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/64d46d9a..92f45f7f

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

  Stats: 50 lines in 1 file changed: 27 ins; 19 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Wed May  7 05:47:30 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 7 May 2025 05:47:30 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/92f45f7f..c6baa83b

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

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

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

From pminborg at openjdk.org  Wed May  7 07:46:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 07:46:45 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v3]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Add a method handle based field updater

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/52e96c52..83ce9ac1

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

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

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

From swen at openjdk.org  Wed May  7 08:00:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 08:00:23 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v3]
In-Reply-To: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>
Message-ID: <dvvQb7iTnkNcpU146Tg6Yei9pOYyAueOpdekwHkunRk=.83d69bc7-022d-4b50-b868-ee3768d90d3a@github.com>

On Wed, 7 May 2025 07:46:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a method handle based field updater

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 173:

> 171:         if (!underlying.type().parameterType(0).equals(Object.class)) {
> 172:             underlying = underlying.asType(underlying.type().changeParameterType(0, Object.class));
> 173:         }

Suggestion:

        var type = underlying.type();
        if (type.returnType() != int.class || type.parameterCount() != 1) {
            throw new IllegalArgumentException("Illegal underlying function: " + underlying);
        }
        if (!type.parameterType(0).equals(Object.class)) {
            underlying = underlying.asType(type.changeParameterType(0, Object.class));
        }

underlying.type() is used 4 times, local variables should be used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077031643

From pminborg at openjdk.org  Wed May  7 09:15:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 09:15:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
 <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>
Message-ID: <6mGpPA6jay-y2UOlU6MWj6Od8MoFs6NL9YRcImf4mf0=.eec82983-2964-47ac-b200-1defe79f4d0d@github.com>

On Tue, 6 May 2025 15:34:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix raw long updater under 32-bit mode
>
> src/java.base/share/classes/java/net/URI.java line 558:
> 
>> 556: 
>> 557:     // Used reflectively by HASH_UPDATER
>> 558:     @Stable
> 
> What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now.

Yes. I think we should remove these public changes and maybe come back in a separate PR with those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077189936

From pminborg at openjdk.org  Wed May  7 09:23:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 09:23:45 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

 - Reformat
 - Revert changes in public classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/83ce9ac1..4a42b271

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

  Stats: 62 lines in 2 files changed: 17 ins; 37 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

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

From jpai at openjdk.org  Wed May  7 10:32:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 10:32:16 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
 <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
Message-ID: <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>

On Tue, 6 May 2025 15:22:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Michael's review suggestions
>
> src/java.base/share/classes/java/net/Socket.java line 390:
> 
>> 388:      * The {@code stream} parameter provided a way in early JDK releases
>> 389:      * to create a {@code Socket} that used a datagram socket. This feature
>> 390:      * no longer exists.
> 
> Should we also re-iterate here that this constructor is deprecated? It kind of feels like this information should be in `@deprecated` instead, or that it should say that IAE is being thrown...

Hello Daniel, do you mean something like this:

-     * @apiNote
-     * The {@code stream} parameter provided a way in early JDK releases
-     * to create a {@code Socket} that used a datagram socket. This feature
-     * no longer exists.
-     *
      * @param      host     the IP address.
      * @param      port      the port number.
      * @param      stream    must be true, false is not allowed.
@@ -429,7 +424,9 @@ public Socket(String host, int port, boolean stream) throws IOException {
      *             or if the port parameter is outside the specified range of valid
      *             port values, which is between 0 and 65535, inclusive.
      * @throws     NullPointerException if {@code host} is null.
-     * @deprecated Use {@link DatagramSocket} instead for UDP transport.
+     * @deprecated The {@code stream} parameter provided a way in early JDK releases
+     *             to create a {@code Socket} that used a datagram socket. This feature
+     *             no longer exists. Use {@link DatagramSocket} instead for UDP transport.


Having that text in `@deprecated` does convey the reason for deprecation and does show up prominently in the rendered javadoc:

<img width="1097" alt="doc" src="https://github.com/user-attachments/assets/897e581e-28c4-424c-b3f9-3bce4591cb7e" />


So if you and others think we should remove the apiNote and move the text to deprecated, then I'll update the PR and the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2077324431

From alanb at openjdk.org  Wed May  7 10:37:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 10:37:15 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
 <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
 <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>
Message-ID: <pz8ebzvIh4v9XX6bvXWAn58PNGQFWgwAWDps1sY74Kk=.ce6c97d9-28b8-4c7a-9cf7-c32e2e9b2ae3@github.com>

On Wed, 7 May 2025 10:29:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 390:
>> 
>>> 388:      * The {@code stream} parameter provided a way in early JDK releases
>>> 389:      * to create a {@code Socket} that used a datagram socket. This feature
>>> 390:      * no longer exists.
>> 
>> Should we also re-iterate here that this constructor is deprecated? It kind of feels like this information should be in `@deprecated` instead, or that it should say that IAE is being thrown...
>
> Hello Daniel, do you mean something like this:
> 
> -     * @apiNote
> -     * The {@code stream} parameter provided a way in early JDK releases
> -     * to create a {@code Socket} that used a datagram socket. This feature
> -     * no longer exists.
> -     *
>       * @param      host     the IP address.
>       * @param      port      the port number.
>       * @param      stream    must be true, false is not allowed.
> @@ -429,7 +424,9 @@ public Socket(String host, int port, boolean stream) throws IOException {
>       *             or if the port parameter is outside the specified range of valid
>       *             port values, which is between 0 and 65535, inclusive.
>       * @throws     NullPointerException if {@code host} is null.
> -     * @deprecated Use {@link DatagramSocket} instead for UDP transport.
> +     * @deprecated The {@code stream} parameter provided a way in early JDK releases
> +     *             to create a {@code Socket} that used a datagram socket. This feature
> +     *             no longer exists. Use {@link DatagramSocket} instead for UDP transport.
> 
> 
> Having that text in `@deprecated` does convey the reason for deprecation and does show up prominently in the rendered javadoc:
> 
> <img width="1097" alt="doc" src="https://github.com/user-attachments/assets/897e581e-28c4-424c-b3f9-3bce4591cb7e" />
> 
> 
> So if you and others think we should remove the apiNote and move the text to deprecated, then I'll update the PR and the CSR.

Okay with me but for SocketImpl then I think it has to be an apiNote as the create method is not deprecated.

BTW: "Use DatagramSocket instead for UDP transport" switches the terminology. The first sentence uses "datagram socket" so I best to use that in the second sentence to avoid "UDP" and "transport".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2077331080

From jpai at openjdk.org  Wed May  7 10:40:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 10:40:15 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <pz8ebzvIh4v9XX6bvXWAn58PNGQFWgwAWDps1sY74Kk=.ce6c97d9-28b8-4c7a-9cf7-c32e2e9b2ae3@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
 <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
 <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>
 <pz8ebzvIh4v9XX6bvXWAn58PNGQFWgwAWDps1sY74Kk=.ce6c97d9-28b8-4c7a-9cf7-c32e2e9b2ae3@github.com>
Message-ID: <Byq-7E2Ys0Mt3MHFvLkEQ1j0Jee4Wbmc6FD9a0DbP30=.fdc5dc2d-0ef6-4929-afcd-1c1d1953f4a9@github.com>

On Wed, 7 May 2025 10:34:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay with me but for SocketImpl then I think it has to be an apiNote as the create method is not deprecated. 

Makes sense.

> BTW: "Use DatagramSocket instead for UDP transport" switches the terminology. The first sentence uses "datagram socket" so I best to use that in the second sentence to avoid "UDP" and "transport".

I agree, I'll use "datagram socket".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2077336378

From pminborg at openjdk.org  Wed May  7 11:04:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 11:04:14 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
 <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
 <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>
Message-ID: <Lg90G_jpGXNnrNxmJ3vHioiDLw6Z6aZG5EWI6NkuPcY=.79e09b7b-8b7f-4aac-94dd-5a341374d702@github.com>

On Tue, 6 May 2025 12:23:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would require another implementation to be written. Maybe we can add that later?
>
> I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility.

There is an MH variant now. The use of the zero alternative is optional, as if you put in `0`, it will have no effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077372099

From dfuchs at openjdk.org  Wed May  7 11:19:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 May 2025 11:19:16 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <Byq-7E2Ys0Mt3MHFvLkEQ1j0Jee4Wbmc6FD9a0DbP30=.fdc5dc2d-0ef6-4929-afcd-1c1d1953f4a9@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
 <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
 <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>
 <pz8ebzvIh4v9XX6bvXWAn58PNGQFWgwAWDps1sY74Kk=.ce6c97d9-28b8-4c7a-9cf7-c32e2e9b2ae3@github.com>
 <Byq-7E2Ys0Mt3MHFvLkEQ1j0Jee4Wbmc6FD9a0DbP30=.fdc5dc2d-0ef6-4929-afcd-1c1d1953f4a9@github.com>
Message-ID: <66XUrKW3cC52QrIpCV7Sn0rXMOe1nsCHub0l5mRYvts=.e91ff201-c989-4507-b5b5-d3d3a4451283@github.com>

On Wed, 7 May 2025 10:37:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Okay with me but for SocketImpl then I think it has to be an apiNote as the create method is not deprecated.
>> 
>> BTW: "Use DatagramSocket instead for UDP transport" switches the terminology. The first sentence uses "datagram socket" so I best to use that in the second sentence to avoid "UDP" and "transport".
>
>> Okay with me but for SocketImpl then I think it has to be an apiNote as the create method is not deprecated. 
> 
> Makes sense.
> 
>> BTW: "Use DatagramSocket instead for UDP transport" switches the terminology. The first sentence uses "datagram socket" so I best to use that in the second sentence to avoid "UDP" and "transport".
> 
> I agree, I'll use "datagram socket".

Thanks Jaikiran. Yes - it feels weird to add an `@apiNote` to a method or constructor that has long been deprecated: if it's deprecated you're not supposed to use it. I couldn't help feeling that using an `@apiNote` there conveyed the wrong message. I am completely OK with the `@apiNote` on the `create` method though - since that one isn't deprecated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2077398768

From dfuchs at openjdk.org  Wed May  7 11:33:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 May 2025 11:33:16 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value [v2]
In-Reply-To: <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
 <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
Message-ID: <ZrQvfC2rSVLL3pMiORqFvgK-8QJRvQ9AOH0LxJu1oxE=.f6dee221-a749-49f1-a417-42c6743ca1b4@github.com>

On Fri, 2 May 2025 09:15:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
>> 
>> Note that `os.name` checks are replaced with `os.family` instead.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document `@requires` rationale with `@comment`
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

test/jdk/java/net/MulticastSocket/PromiscuousIPv6.java line 27:

> 25:  * @test
> 26:  * @bug 8215294
> 27:  * @requires os.family == "linux" & !(os.version ~= "3\\.10\\.0.*")

Would that match 13.10.01?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24997#discussion_r2077418883

From jpai at openjdk.org  Wed May  7 11:34:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 11:34:08 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v9]
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <NqJ8CJk0N6D4gK-D1Xh9l901VvWJ9hkZMatBAbX_Un8=.a65a5465-cd71-45a0-a0b5-3fbb0f41f340@github.com>

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

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

  move apiNote text to deprecated text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25031/files
  - new: https://git.openjdk.org/jdk/pull/25031/files/4cbe5178..77a332bc

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

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

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

From jpai at openjdk.org  Wed May  7 11:34:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 11:34:08 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v8]
In-Reply-To: <66XUrKW3cC52QrIpCV7Sn0rXMOe1nsCHub0l5mRYvts=.e91ff201-c989-4507-b5b5-d3d3a4451283@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <4nkIGeJlHn2PayTM5dWiaHjXGTDcMzUQr6pRxxdUa7c=.04408905-6431-4ea3-a9b3-f92471bba2c0@github.com>
 <9VQz42tM2RIpwOmY4v3SKd0Akik3xtEvDSKl144H-mg=.53cfd557-0762-4dc4-8105-6dc373b8d184@github.com>
 <Jxa4jX6tjGeaulT9iU4bfnJopCK6h7DD9L2wgbK-pP0=.7c0192a6-bcd5-4bbb-87f8-8f28483e709a@github.com>
 <pz8ebzvIh4v9XX6bvXWAn58PNGQFWgwAWDps1sY74Kk=.ce6c97d9-28b8-4c7a-9cf7-c32e2e9b2ae3@github.com>
 <Byq-7E2Ys0Mt3MHFvLkEQ1j0Jee4Wbmc6FD9a0DbP30=.fdc5dc2d-0ef6-4929-afcd-1c1d1953f4a9@github.com>
 <66XUrKW3cC52QrIpCV7Sn0rXMOe1nsCHub0l5mRYvts=.e91ff201-c989-4507-b5b5-d3d3a4451283@github.com>
Message-ID: <BGTfKICisITocsyCrkm4ketfVs_RZFSkEiZrAWiZozQ=.582e5de9-b647-4746-b56d-5363f796b466@github.com>

On Wed, 7 May 2025 11:16:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Okay with me but for SocketImpl then I think it has to be an apiNote as the create method is not deprecated. 
>> 
>> Makes sense.
>> 
>>> BTW: "Use DatagramSocket instead for UDP transport" switches the terminology. The first sentence uses "datagram socket" so I best to use that in the second sentence to avoid "UDP" and "transport".
>> 
>> I agree, I'll use "datagram socket".
>
> Thanks Jaikiran. Yes - it feels weird to add an `@apiNote` to a method or constructor that has long been deprecated: if it's deprecated you're not supposed to use it. I couldn't help feeling that using an `@apiNote` there conveyed the wrong message. I am completely OK with the `@apiNote` on the `create` method though - since that one isn't deprecated.

I've updated the PR to move the text into `@deprecated` section for these 2 constructors. I'll update the CSR once this new text is approved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25031#discussion_r2077420523

From vyazici at openjdk.org  Wed May  7 11:52:21 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 11:52:21 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value [v2]
In-Reply-To: <ZrQvfC2rSVLL3pMiORqFvgK-8QJRvQ9AOH0LxJu1oxE=.f6dee221-a749-49f1-a417-42c6743ca1b4@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
 <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
 <ZrQvfC2rSVLL3pMiORqFvgK-8QJRvQ9AOH0LxJu1oxE=.f6dee221-a749-49f1-a417-42c6743ca1b4@github.com>
Message-ID: <ymqRHoKvJeeyE7o-UbHAR5oSNSKs1EdjSMJTi099mGw=.49916971-c80d-4011-8830-192693ee6cfe@github.com>

On Wed, 7 May 2025 11:29:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document `@requires` rationale with `@comment`
>>   
>>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> test/jdk/java/net/MulticastSocket/PromiscuousIPv6.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8215294
>> 27:  * @requires os.family == "linux" & !(os.version ~= "3\\.10\\.0.*")
> 
> Would that match 13.10.01?

No.

Adding `@requires os.family ~= "inux"` causes a test to be discarded on my (Linux) system. That is, the pattern is implicitly wrapped with `^` and `$` directives. Whereas `@requires os.family ~= "linux"` causes the test to get executed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24997#discussion_r2077450781

From eirbjo at openjdk.org  Wed May  7 11:52:28 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 7 May 2025 11:52:28 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v14]
In-Reply-To: <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <wmjSuYBAZsmwuL_V1TcqcXLhxfgGHmp1Z8npUDRAXro=.a78d56c1-6538-4920-bc4b-8cdbf7eed7f8@github.com>
Message-ID: <enG9JANe9JKtHpoPZSwkwg5myeeheiiBQsIRppR0I1Q=.5260890b-90bc-46c9-9b4e-e8b80531f095@github.com>

On Fri, 2 May 2025 20:32:27 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra space
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

Thanks for your patient help Daniel!

I?ll let this behavioral change in an ancient and dusty corner of the JDK linger for another 24h, just out of caution for any late reviewers.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2858282788

From dfuchs at openjdk.org  Wed May  7 11:56:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 May 2025 11:56:21 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value [v2]
In-Reply-To: <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
 <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
Message-ID: <BXSK71YgO0dYbbLDVHeVh7-Gz0-hc1twUqVQbQfykMw=.9da54bec-eb77-4d43-9215-b4a4697c0129@github.com>

On Fri, 2 May 2025 09:15:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
>> 
>> Note that `os.name` checks are replaced with `os.family` instead.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document `@requires` rationale with `@comment`
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24997#pullrequestreview-2821461900

From dfuchs at openjdk.org  Wed May  7 11:58:17 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 May 2025 11:58:17 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v9]
In-Reply-To: <NqJ8CJk0N6D4gK-D1Xh9l901VvWJ9hkZMatBAbX_Un8=.a65a5465-cd71-45a0-a0b5-3fbb0f41f340@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <NqJ8CJk0N6D4gK-D1Xh9l901VvWJ9hkZMatBAbX_Un8=.a65a5465-cd71-45a0-a0b5-3fbb0f41f340@github.com>
Message-ID: <5dYxWt9H_6SIIW3QzGbI7cno8HbkHahguliBgHRkHkw=.231cfb0b-28bc-4632-9956-bfc70faeb373@github.com>

On Wed, 7 May 2025 11:34:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move apiNote text to deprecated text

Thanks! I prefer the new version.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25031#pullrequestreview-2821467164

From duke at openjdk.org  Wed May  7 11:59:14 2025
From: duke at openjdk.org (duke)
Date: Wed, 7 May 2025 11:59:14 GMT
Subject: RFR: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value [v2]
In-Reply-To: <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
 <WRJ84S2cI56Khuvv9_rBp1CtyMlJhwYHpeptRxvd7Sw=.7d718ac7-d036-49ee-9236-a45b861eb8c0@github.com>
Message-ID: <FooaYqj2Zx9Vj3-MZEaOZ0lKMmV4Dvk1I36rSg_Zhuw=.49d96e19-827e-4876-a174-84b81a7e40c0@github.com>

On Fri, 2 May 2025 09:15:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
>> 
>> Note that `os.name` checks are replaced with `os.family` instead.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document `@requires` rationale with `@comment`
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

@vy 
Your change (at version 242f0787b26361e3679b57e0f5f5432dfc3a130d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24997#issuecomment-2858301209

From vyazici at openjdk.org  Wed May  7 12:10:21 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 12:10:21 GMT
Subject: Integrated: 8355578: [java.net] Use @requires tag instead of exiting
 based on "os.name" property value
In-Reply-To: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
References: <golwMiXuF73YEJnt5EEvRcreII63XrKPhZ2zOx9JqVk=.bcbc3d12-e3c9-4d79-b143-95999d680030@github.com>
Message-ID: <ja8WXlDg_HNgkQDprewb0ot1LWYbCMG_mvrl3kafta4=.42eca628-3be6-4c88-acc3-17856d7f7c4f@github.com>

On Fri, 2 May 2025 08:26:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Replaces `os.name` checks in tests with `@requires`. This prevents these tests from being run, and superficial results being generated, on unnecessary platforms.
> 
> Note that `os.name` checks are replaced with `os.family` instead.

This pull request has now been integrated.

Changeset: 60a4594b
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60a4594b9f9acd82ef3ff22fc6a2df238dd981b9
Stats:     74 lines in 6 files changed: 11 ins; 55 del; 8 mod

8355578: [java.net] Use @requires tag instead of exiting based on "os.name" property value

Reviewed-by: dfuchs

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

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

From duke at openjdk.org  Wed May  7 12:11:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 7 May 2025 12:11:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
Message-ID: <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>

On Wed, 7 May 2025 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reformat
>  - Revert changes in public classes

Starting to look nicely idiomatic. If I saw this I would however want to add a thin wrapper specific for hash codes where the "zero replacement" and generic types are more hidden.
* HashCoder.forIntField(Foo.class, "hash", ...)
* HashCoder.forLongField(...)
I like that there's an annotation on the field now though!

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 83:

> 81: 
> 82: 
> 83:     static // Intentionally in unblessed order to allow the example to look nice

Huh, not seen this before ... interesting.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117:

> 115:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
> 116:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",
> 117:                         l -> Objects.hash(l.bar, l.baz), -1);

As someone unfamiliar with this, I'm given to ask "What's the -1 for?"

I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful?

In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 149:

> 147:         private static final ToLongFunction<LazySpecifiedFoo> HASH_UPDATER =
> 148:                 StableFieldUpdater.ofLong(LazySpecifiedFoo.class, "hash",
> 149:                         l -> (l.bar == null && l.baz == null) ? 0 : Objects.hash(l.bar, l.baz), 1L << 32);

Maybe for an example, use a (private?) static method reference here `calculateHash`.
It helps visually distinguish plumbing and business logic IMO.

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

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2821463165
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457809
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457604
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077460209

From liach at openjdk.org  Wed May  7 12:57:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 12:57:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
Message-ID: <ks7Fdtyi2OSDuzk69--M7xPcxUTJr3VtRKo4VFIXRyA=.8b84dea3-9ccf-40c9-9687-89aa8d685e1a@github.com>

On Wed, 7 May 2025 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reformat
>  - Revert changes in public classes

The MH+VH form should be much more lightweight: MH and VH are just MemberName references.

I wonder if we can advertise the MH+VH version as an indy BSM:

public static CallSite lazyAccessor(Lookup lookup, String unused, MethodType callType, VarHandle field, MethodHandle computer)


The CallSite would be constant, with `StableIntFieldUpdaterVarHandle.applyAsInt` bound to the specific updater. This way, we can even defer the creation of the updater.

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

PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2858487803

From pminborg at openjdk.org  Wed May  7 13:55:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 13:55:08 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v5]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <jrFR7pUJMqqF8CIbTWKuc0kNmt61MI_oZTV6sXwPB8M=.901b586c-f66b-4a1d-abc4-5eb140cf4f97@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

 - Add low level variants
 - Merge branch 'master' into stable-updaters
 - Reformat
 - Revert changes in public classes
 - Add a method handle based field updater
 - Fix raw long updater under 32-bit mode
 - Address comments
 - Document field alignment assumption
 - Add unhecked call test
 - Move raw factories into inner class Raw
 - ... and 5 more: https://git.openjdk.org/jdk/compare/de41c1f3...6342fbd8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/4a42b271..6342fbd8

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

  Stats: 14466 lines in 388 files changed: 9105 ins; 3251 del; 2110 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

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

From pminborg at openjdk.org  Wed May  7 13:55:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 13:55:10 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
 <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>
Message-ID: <6V0vEbAOnYqONTavs8-eEVlInQI5pTcYDAo1tRYduNA=.0ff84e6a-73e6-40c3-b616-0c0753d330a3@github.com>

On Wed, 7 May 2025 11:54:09 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Reformat
>>  - Revert changes in public classes
>
> test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117:
> 
>> 115:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
>> 116:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",
>> 117:                         l -> Objects.hash(l.bar, l.baz), -1);
> 
> As someone unfamiliar with this, I'm given to ask "What's the -1 for?"
> 
> I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful?
> 
> In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero.

I've added some verbiage around this now. Let me know if it can be improved further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077688537

From duke at openjdk.org  Wed May  7 14:08:27 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 7 May 2025 14:08:27 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method
Message-ID: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>

Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.

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

Commit messages:
 - update inetaddress javadoc

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

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

From duke at openjdk.org  Wed May  7 14:35:39 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 7 May 2025 14:35:39 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is not
 specified
Message-ID: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>

Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.

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

Commit messages:
 - authenticator getRequestingURL spec update
 - update inetaddress javadoc

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

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

From duke at openjdk.org  Wed May  7 14:39:35 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 7 May 2025 14:39:35 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
Message-ID: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>

> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  revert changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25097/files
  - new: https://git.openjdk.org/jdk/pull/25097/files/4d6eb730..6f12e2b0

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

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

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

From dfuchs at openjdk.org  Wed May  7 14:46:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 May 2025 14:46:33 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method
In-Reply-To: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
Message-ID: <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>

On Wed, 7 May 2025 14:02:52 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.

src/java.base/share/classes/java/net/InterfaceAddress.java line 67:

> 65:      * <p>
> 66:      * Certain IPv4 addresses, such as the loopback address, do not support
> 67:      * broadcasting and will also result in {@code null} being returned.

Suggestion:

     * Certain network interfaces, such as the loopback interface, do not support
     * broadcasting and will also return {@code null}.


Maybe the class level API documentation should also be updated something like:


 * This class represents a Network Interface address. In short it's an
 * IP address, a subnet mask as well as a broadcast address when the address is
 * IPv4 and the interface supports broadcasting.
 * An IP address and a network prefix length in the case
 * of IPv6 address.


It would be good to have @Michael-Mc-Mahon approve the wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25095#discussion_r2077800913

From pminborg at openjdk.org  Wed May  7 14:58:33 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 14:58:33 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v6]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Add convenience methods and documentations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/6342fbd8..a01ba9ab

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

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

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

From pminborg at openjdk.org  Wed May  7 15:03:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 15:03:57 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v7]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/a01ba9ab..de8e2387

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

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

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

From liach at openjdk.org  Wed May  7 15:04:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 15:04:25 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <ub7NBpAmIMfDRrU6OpmpigQ-BvGZlGqlNTcA8DkGcFM=.50bd8226-e1d3-4ea2-990b-12cde54e7042@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

Need a small CSR to record this API specification update. You can create the CSR after the text has settled down.

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2858939201

From duke at openjdk.org  Wed May  7 15:10:16 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 May 2025 15:10:16 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v7]
In-Reply-To: <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>
Message-ID: <89tWdW-Z_osB8oN36zrb_w_BPPDjCd6mJ_pEpDjCfXQ=.9ce14d67-3867-4c37-9d72-4fe690c2e0bc@github.com>

On Wed, 7 May 2025 15:03:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat

`StableFieldUpdater?.checkAndAdapt(?)` also?performs an?implicit null?check:

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

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2822161491

From duke at openjdk.org  Wed May  7 15:10:19 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 May 2025 15:10:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v6]
In-Reply-To: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>
Message-ID: <NRYWxpUgBF_-o85c_9ZmEVHvmtGhi0WosIIPHNTT6YY=.0da6aa28-da0a-4bef-99eb-c66b7de19020@github.com>

On Wed, 7 May 2025 14:58:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add convenience methods and documentations

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 257:

> 255:         check(accessor, int.class);
> 256:         Objects.requireNonNull(underlying);
> 257:         var adaptedUnderlying = checkAndAdapt(underlying, int.class);

Suggestion:

        // Implicit null checks:
        check(accessor, int.class);
        var adaptedUnderlying = checkAndAdapt(underlying, int.class);

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 311:

> 309:         check(accessor, long.class);
> 310:         Objects.requireNonNull(underlying);
> 311:         var adaptedUnderlying = checkAndAdapt(underlying, long.class);

Suggestion:

        // Implicit null checks:
        check(accessor, long.class);
        var adaptedUnderlying = checkAndAdapt(underlying, long.class);

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 588:

> 586: 
> 587:     private static MethodHandle checkAndAdapt(MethodHandle underlying, Class<?> returnType) {
> 588:         final var underlyingType = underlying.type();

Suggestion:

        // Implicit null check
        final var underlyingType = underlying.type();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860284
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860770
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077861275

From duke at openjdk.org  Wed May  7 15:55:14 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 7 May 2025 15:55:14 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <mdFJusDyLgKvMoesfCaOPD47EQKurrTBzEsI6nmKobY=.21a7bce0-debd-4682-86db-e5d750354804@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

> /csr needed
> 
> Need a small CSR to record this API specification update. You can create the CSR after the text has settled down.

@liach I populated the previously created CSR CCC-7046003 as linked to the bug.

Would you be okay to review?

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2859135098

From liach at openjdk.org  Wed May  7 16:01:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 16:01:18 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <8ycoBUrv8GmaUDacD42ztdKEqasn3f9wSMokkw07Xhk=.df05b22f-cae6-45c1-80d4-fddf78a5c3ea@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

CCC is a legacy internal process only present for archival purposes. I think we should withdraw that CCC and remove the "csr of" link so we can create a new CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2859150050

From duke at openjdk.org  Wed May  7 16:15:13 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 7 May 2025 16:15:13 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <8ycoBUrv8GmaUDacD42ztdKEqasn3f9wSMokkw07Xhk=.df05b22f-cae6-45c1-80d4-fddf78a5c3ea@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
 <8ycoBUrv8GmaUDacD42ztdKEqasn3f9wSMokkw07Xhk=.df05b22f-cae6-45c1-80d4-fddf78a5c3ea@github.com>
Message-ID: <1_nLtv4YMq_GSX76_LIy-9LmFBnYP0hbb7sA5uHyb1s=.b757eb09-8221-48d0-bad7-761ce83aef37@github.com>

On Wed, 7 May 2025 15:58:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> CCC is a legacy internal process only present for archival purposes. I think we should withdraw that CCC and remove the "csr of" link so we can create a new CSR.

@liach - Old CSR withdrawn and new CSR created - JDK-8356410, thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2859187855

From weijun at openjdk.org  Wed May  7 16:24:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 May 2025 16:24:25 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
Message-ID: <zBkO4iZPqFZLGePpv8WXyA9u0TVmCgqxVCpgO058b0E=.2e1de419-077e-426d-92e5-191f07a1be4e@github.com>

On Wed, 7 May 2025 05:47:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169:

> 167: 
> 168:     /**
> 169:      * Generate Exported Key Material (EKM) calculated according to the

s/Key/Keying/

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1808:

> 1806:             String label, byte[] context, int length) throws SSLKeyException {
> 1807:         byte[] bytes =
> 1808:                 exportKeyingMaterialKey(label, context, length).getEncoded();

In PKCS #11, calling `deriveKey(...).getEncoded()` is not equivalent to `deriveData()`. It's quite likely that `deriveKey` returns an un-extractable key, but `deriveData` using the exact same input returns the keying material.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078023812
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078022859

From weijun at openjdk.org  Wed May  7 16:31:14 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 May 2025 16:31:14 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
Message-ID: <qQmgQf6p_bRMA1437G8ch7N9F4A3-pmdE3qMmxG4svk=.990820ee-10c1-46c1-a2ba-a476c903ed0a@github.com>

On Wed, 7 May 2025 05:47:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694:

> 1692: 
> 1693:                     // ...now the final expand.
> 1694:                     SecretKey key = hkdf.deriveKey(label,

PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078033799

From wetmore at openjdk.org  Wed May  7 21:24:12 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 7 May 2025 21:24:12 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v8]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <J-0-bQGkijjj6R6mF4QakQTKlqEJZxV5pPV3eGyxzpw=.df125e87-0213-4fd8-ab50-099117bfa405@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  More Codereview comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/c6baa83b..2e5f5342

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

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

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

From jpai at openjdk.org  Thu May  8 03:58:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 03:58:58 GMT
Subject: RFR: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException [v9]
In-Reply-To: <NqJ8CJk0N6D4gK-D1Xh9l901VvWJ9hkZMatBAbX_Un8=.a65a5465-cd71-45a0-a0b5-3fbb0f41f340@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
 <NqJ8CJk0N6D4gK-D1Xh9l901VvWJ9hkZMatBAbX_Un8=.a65a5465-cd71-45a0-a0b5-3fbb0f41f340@github.com>
Message-ID: <iH5iHKo57cAIv0nOXgDxzpweI50XjmWueRzdR5SIyxc=.cbf26fc3-98e9-4f71-b39d-835aacc8a14f@github.com>

On Wed, 7 May 2025 11:34:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
>> 
>> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
>> 
>> I will create a CSR once we settle on these changes.
>> 
>> tier1 through tier8 tests have been run with this change and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move apiNote text to deprecated text

Thank you all for the reviews, the CSR has been approved with this latest text. I'll go ahead with the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/25031#issuecomment-2861663091

From jpai at openjdk.org  Thu May  8 03:58:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 03:58:58 GMT
Subject: Integrated: 8356154: Respecify java.net.Socket constructors that allow
 creating UDP sockets to throw IllegalArgumentException
In-Reply-To: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
References: <XviYXEwcOeYvQxcpciUT8fKef0iE_bNbM5txk1Vf088=.61a8873b-6765-45f9-8b61-728cca0ecc2c@github.com>
Message-ID: <W0gCcmgHgHbmApU0u3t3X5oSo0QosEtgXqxA6ubKXMM=.ff5fc1df-965c-4fd9-bb51-b1774cc23c5e@github.com>

On Mon, 5 May 2025 10:12:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to respecify the 2 `java.net.Socket` constructors that allow construction of UDP sockets? This addresses https://bugs.openjdk.org/browse/JDK-8356154.
> 
> As noted in that JBS issue, in Java 23 we deprecated for removal the 2 `Socket` constructors that allowed UDP socket creation. The plan continues to be to remove those constructors. Before removing those, in order to allow for applications to notice this deprecation, these constructors are now being respecified to throw an `IllegalArgumentException` when the `stream` parameter is `false`.
> 
> I will create a CSR once we settle on these changes.
> 
> tier1 through tier8 tests have been run with this change and no related failures have been noticed.

This pull request has now been integrated.

Changeset: 52a5583d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52a5583d691388f833c3aeb56ce92cbfb5d61274
Stats:     172 lines in 9 files changed: 37 ins; 72 del; 63 mod

8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException

Reviewed-by: dfuchs, alanb

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

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

From rhalade at openjdk.org  Thu May  8 05:57:52 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 May 2025 05:57:52 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
Message-ID: <a1xA-NtaXvJm5MDYDuYR-z7_2ebHz_nQFa38vj-rVCU=.cb277a56-6526-4dfe-a4d4-70a66021f563@github.com>

On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment changes

I understand this is a old test and it is not in scope of this bug to update existing code. But there are few issues in this test that should be addressed, for instance, use of deprecated URL, old style threads, old code styles, typos etc. Can you please check the complete test code as if you are to rewrite?

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2861858937

From wetmore at openjdk.org  Thu May  8 06:05:52 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 8 May 2025 06:05:52 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <qQmgQf6p_bRMA1437G8ch7N9F4A3-pmdE3qMmxG4svk=.990820ee-10c1-46c1-a2ba-a476c903ed0a@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
 <qQmgQf6p_bRMA1437G8ch7N9F4A3-pmdE3qMmxG4svk=.990820ee-10c1-46c1-a2ba-a476c903ed0a@github.com>
Message-ID: <J2wTfQWzVLWaX1EqxjoxHNQ9AdB4LlYpJt_kSQBqcDo=.7fd91454-e70d-4b2e-860b-9d7f8bf0de72@github.com>

On Wed, 7 May 2025 16:28:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694:
> 
>> 1692: 
>> 1693:                     // ...now the final expand.
>> 1694:                     SecretKey key = hkdf.deriveKey(label,
> 
> PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES".

IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels 

Thus the type needs to be something generic.  The label sounded good initially, but there is no specific prohibition against non-null/empty label in the TLS Exporters, but KDF prohibits null/empty labels.

Maybe a label like "ExportKeyingMaterial"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078948256

From pminborg at openjdk.org  Thu May  8 07:16:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:16:28 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v8]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <RT7r2o2lv_UhpBrgiUStZsES4gkQiirc3n680966RfQ=.2135d46d-ddd5-4a4c-a06e-faadaae8b252@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Add lazy CallSite methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/de8e2387..e2a2d7bd

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

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

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

From pminborg at openjdk.org  Thu May  8 07:27:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:27:50 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v9]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <wRlfMNSYAZyZaS0NPCWB_gLzTR2U2qaguJou6-Avw9M=.2632b0cc-015f-402e-ab45-c6f95edfa300@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Revert changes in stable classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/e2a2d7bd..e928591a

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

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

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

From vyazici at openjdk.org  Thu May  8 09:08:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 May 2025 09:08:09 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept relative
 paths
Message-ID: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>

Allows relative paths in the content root directory passed to the `jwebserver`. Changes apply to both the `jwebserver` executable and the `java -m jdk.httpserver` execution.

### Implementation notes

Received `Path` is first passed through `.normalize().toAbsolutePath()`, and then used. The rest of the logic is untouched. This effectively implies that

1. Parts that require an absolute path (e.g., `s.n.h.s.FileServerHandler`) kept their conditions
2. Logging, failures, etc. containing the user-provided directory will now refer to the _normalized absolute_ path instead of the user-provided one (can be relative, can be not normalized, etc.)

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

Commit messages:
 - Allow relative directories in `SimpleFileServerImpl::start`

Changes: https://git.openjdk.org/jdk/pull/25113/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355360
  Stats: 126 lines in 5 files changed: 58 ins; 20 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/25113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25113/head:pull/25113

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

From alanb at openjdk.org  Thu May  8 09:24:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 09:24:53 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths
In-Reply-To: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
Message-ID: <oAyPkYbzWmmTQk3Sge8IVBidS2JdKRwSKof3lO1-EXQ=.1631e2a4-9c58-4899-aaec-7ce60d32cdd9@github.com>

On Thu, 8 May 2025 09:01:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Allows relative paths in the content root directory passed to the `jwebserver`. Changes apply to both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
> 
> ### Implementation notes
> 
> Received `Path` is first passed through `.normalize().toAbsolutePath()`, and then used. The rest of the logic is untouched. This effectively implies that
> 
> 1. Parts that require an absolute path (e.g., `s.n.h.s.FileServerHandler`) kept their conditions
> 2. Logging, failures, etc. containing the user-provided directory will now refer to the _normalized absolute_ path instead of the user-provided one (can be relative, can be not normalized, etc.)

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java line 115:

> 113:                     }
> 114:                     case "-d", "--directory" ->
> 115:                         root = Path.of(optionArg = options.next()).normalize().toAbsolutePath();

normalize removes redundant name elements and is for "user input". Are you 100% sure it make sense here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25113#discussion_r2079265013

From myankelevich at openjdk.org  Thu May  8 10:16:57 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:16:57 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: <a1xA-NtaXvJm5MDYDuYR-z7_2ebHz_nQFa38vj-rVCU=.cb277a56-6526-4dfe-a4d4-70a66021f563@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
 <a1xA-NtaXvJm5MDYDuYR-z7_2ebHz_nQFa38vj-rVCU=.cb277a56-6526-4dfe-a4d4-70a66021f563@github.com>
Message-ID: <74ZtTS-NMZ0PRMZbT46BSJtaMkeIfYvGJxtKovQ6wlU=.8d61b0aa-8819-4ba4-bc08-753912910c1d@github.com>

On Thu, 8 May 2025 05:54:58 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> I understand this is a old test and it is not in scope of this bug to update existing code. But there are few issues in this test that should be addressed, for instance, use of deprecated URL, old style threads, old code styles, typos etc. Can you please check the complete test code as if you are to rewrite?

Updated the code

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2862510391

From myankelevich at openjdk.org  Thu May  8 10:16:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:16:56 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v4]
In-Reply-To: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
Message-ID: <qFtMjv7M3GYUA6jUDafCdIfElEPGHcITqRmRfwFHkjo=.68dd6aac-3fd6-4309-a581-a2a23421d23e@github.com>

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

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

  cleanup and update of the code to the current style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23469/files
  - new: https://git.openjdk.org/jdk/pull/23469/files/68c52a37..2bff4a34

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

  Stats: 68 lines in 1 file changed: 13 ins; 5 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/23469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469

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

From vyazici at openjdk.org  Thu May  8 11:31:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 May 2025 11:31:55 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v2]
In-Reply-To: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
Message-ID: <nqVGDybuua5dPW9rFw5xMgi3AFjmZMQijtNMXD6gy9I=.f71b1fe7-49fa-4ab3-8a77-74d091ef3172@github.com>

> Allows relative paths in the content root directory passed to the `jwebserver`. Changes apply to both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
> 
> ### Implementation notes
> 
> Received `Path` is read using `toRealPath()`, and then employed. The rest of the logic is untouched. This effectively implies that
> 
> 1. Parts that require an absolute path (e.g., `s.n.h.s.FileServerHandler`) kept their conditions
> 2. Logging, failures, etc. containing the user-provided directory will now refer to the _real path_ instead of the user-provided one (can be relative, can be not normalized, etc.)

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

  Replace `normalize().toAbsolutePath()` with `toRealPath()`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25113/files
  - new: https://git.openjdk.org/jdk/pull/25113/files/8e904e96..5f9e3df8

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

  Stats: 31 lines in 3 files changed: 18 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25113/head:pull/25113

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

From vyazici at openjdk.org  Thu May  8 11:31:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 May 2025 11:31:56 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v2]
In-Reply-To: <oAyPkYbzWmmTQk3Sge8IVBidS2JdKRwSKof3lO1-EXQ=.1631e2a4-9c58-4899-aaec-7ce60d32cdd9@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <oAyPkYbzWmmTQk3Sge8IVBidS2JdKRwSKof3lO1-EXQ=.1631e2a4-9c58-4899-aaec-7ce60d32cdd9@github.com>
Message-ID: <4QZJXvihnikI0iqXV4CXNlxGP_XChAl0-72a4ueANqU=.011b7b53-d33b-4d1f-966b-5355979e344a@github.com>

On Thu, 8 May 2025 09:21:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace `normalize().toAbsolutePath()` with `toRealPath()`
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java line 115:
> 
>> 113:                     }
>> 114:                     case "-d", "--directory" ->
>> 115:                         root = Path.of(optionArg = options.next()).normalize().toAbsolutePath();
> 
> normalize removes redundant name elements and is for "user input". Are you 100% sure it make sense here?

@AlanBateman, thanks for the review. In 5f9e3df8f607d82987ca748492e6b0468462cb14, replaced `normalize().toAbsolutePath()` with `toRealPath()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25113#discussion_r2079528637

From pminborg at openjdk.org  Thu May  8 13:16:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 13:16:25 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Add composition of functions and MHs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/e928591a..1628b264

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

  Stats: 292 lines in 4 files changed: 157 ins; 45 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

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

From vyazici at openjdk.org  Thu May  8 13:45:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 May 2025 13:45:40 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v3]
In-Reply-To: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
Message-ID: <36QXZ43wAazZEY3K1acxyRFTr7IdJg1kF_9QV_r3DG4=.f14ab86f-a6cb-4ff9-9810-615444d1f0e1@github.com>

> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
> 
> ### Implementation notes
> 
> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.

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

  Revert `SimpleFileServerImpl` changes, and allow relative paths in `FileServerHandler` instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25113/files
  - new: https://git.openjdk.org/jdk/pull/25113/files/5f9e3df8..2f4620b6

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

  Stats: 53 lines in 5 files changed: 24 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25113/head:pull/25113

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

From vyazici at openjdk.org  Thu May  8 13:45:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 8 May 2025 13:45:40 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v3]
In-Reply-To: <36QXZ43wAazZEY3K1acxyRFTr7IdJg1kF_9QV_r3DG4=.f14ab86f-a6cb-4ff9-9810-615444d1f0e1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <36QXZ43wAazZEY3K1acxyRFTr7IdJg1kF_9QV_r3DG4=.f14ab86f-a6cb-4ff9-9810-615444d1f0e1@github.com>
Message-ID: <AKYlnRBWq2unlBO88UgbysXds_nVHJ3hXcjlqlW70To=.a62dd4dd-1538-45a4-9a58-6f81e9db3e55@github.com>

On Thu, 8 May 2025 13:42:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
>> 
>> ### Implementation notes
>> 
>> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert `SimpleFileServerImpl` changes, and allow relative paths in `FileServerHandler` instead

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 81:

> 79:         if (!Files.exists(root)) {
> 80:             throw new IllegalArgumentException("Path does not exist: " + root);
> 81:         }

As I tried to explain in the comment block above, without this pre-check, non-existent files are reported poorly:


$ build/linux-x64/jdk/bin/jwebserver -d no-such-file
Error: server config failed: Path is invalid: no-such-file
$ _


Note the lack of context regarding the failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25113#discussion_r2079748206

From michaelm at openjdk.org  Thu May  8 13:55:54 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 8 May 2025 13:55:54 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
Message-ID: <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>

On Tue, 22 Apr 2025 09:44:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

test/micro/org/openjdk/bench/java/net/ServerUdsChannelHolder.java line 39:

> 37: 
> 38:     private final Path socketFilePath;
> 39: 

It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file. Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this clase?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2079768594

From eirbjo at openjdk.org  Thu May  8 14:57:09 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 8 May 2025 14:57:09 GMT
Subject: Integrated: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <LQgkjsLdSR42-JoKzsEeAwa_JHtBUJO-UIhf6C6e264=.4393bd3b-b52f-4894-9faa-13f512cd3fef@github.com>

On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Documents the new property in `net-properties.html` 
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

This pull request has now been integrated.

Changeset: 2ea629f3
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ea629f3f2ae07de9cb92baac13497a789d16ec3
Stats:     166 lines in 7 files changed: 150 ins; 11 del; 5 mod

8353440: Disable FTP fallback for non-local file URLs by default

Reviewed-by: dfuchs

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

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

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From duke at openjdk.org  Thu May  8 15:31:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 8 May 2025 15:31:06 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
Message-ID: <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>

On Thu, 8 May 2025 13:16:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add composition of functions and MHs

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 120:

> 118: 
> 119:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
> 120:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",

Very clean now.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183:

> 181:     static
> 182: 
> 183:     public final class MhFoo {

I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079941869
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079953010

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:10:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:10:18 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

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

 - Merge branch 'master' into deprecate-net-perms-8353642
 - Revert changes to SocketPermission and CodeSource
 - Review feedback. Deprecate getPermission for removal.
 - Missing white spaces
 - 8353642: Deprecate networking permission classes for removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/d47a31d1..2807f3f6

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

  Stats: 268511 lines in 2569 files changed: 76630 ins; 182086 del; 9795 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

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

From dfuchs at openjdk.org  Thu May  8 16:14:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:14:54 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
Message-ID: <VwLE8omOIs2ISlQE9A_CJ1BhpPBBeDDsbk0VFuDmh-Q=.66c43f5a-b4e3-4523-b61a-16f1f7362f19@github.com>

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

After discussion with @seanjmullan we decided to revert the changes to `SocketPermission` and `CodeSource` from this PR. Deprecation of `SocketPermission` will be the object of another RFE ([JDK-8356557](https://bugs.openjdk.org/browse/JDK-8356557)) - once we have decided what to do with `CodeSource::implies`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2863592195

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From djelinski at openjdk.org  Thu May  8 18:11:56 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 8 May 2025 18:11:56 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
Message-ID: <JUB7wxFdyBgvkLoiIDonBL9tBRefZ_zmK5-tARYDRPs=.b1beb3ea-4ec4-4090-97e2-00508965c26e@github.com>

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2825963973

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From iris at openjdk.org  Thu May  8 20:28:57 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 May 2025 20:28:57 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
Message-ID: <Bok0HUCEbYKlnAU1vUEZsarZeGfNG2xJheLwnmnm98k=.02c894c1-3c96-458c-94d6-2ac0c5e7e975@github.com>

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2826287061

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From wetmore at openjdk.org  Fri May  9 05:12:30 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 9 May 2025 05:12:30 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v9]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <9IX-GFMX9JOE-brPukm4qw0mmMqg0kpCizxzVw5shUM=.ffebf952-0da5-4c37-98a7-ac6f5080317d@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/2e5f5342..598fc579

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

  Stats: 275 lines in 3 files changed: 188 ins; 19 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From pminborg at openjdk.org  Fri May  9 08:38:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 08:38:39 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg 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 24 additional commits since the last revision:

 - Revert unintended change
 - Revert unintended change
 - Remove unused factories and add comment
 - Merge branch 'master' into stable-updaters
 - Add composition of functions and MHs
 - Revert changes in stable classes
 - Add lazy CallSite methods
 - Reformat
 - Add convenience methods and documentations
 - Add low level variants
 - ... and 14 more: https://git.openjdk.org/jdk/compare/6916dfd3...9a58db6a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/1628b264..9a58db6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=09-10

  Stats: 3102 lines in 128 files changed: 2035 ins; 528 del; 539 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

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

From pminborg at openjdk.org  Fri May  9 08:38:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 08:38:39 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
 <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>
Message-ID: <3Nb4WpG8VD6QdUuloCkv5v5MClYc-LU6PAbiZ_eOs54=.2c55b650-fe76-4494-bea9-706020015ccf@github.com>

On Thu, 8 May 2025 15:28:20 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add composition of functions and MHs
>
> test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183:
> 
>> 181:     static
>> 182: 
>> 183:     public final class MhFoo {
> 
> I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)?

I have removed the unchecked factories now. I do not think we need them, and if we do, we could always add them back later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081205297

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From vklang at openjdk.org  Fri May  9 09:23:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 9 May 2025 09:23:56 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
Message-ID: <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>

On Fri, 9 May 2025 08:38:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg 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 24 additional commits since the last revision:
> 
>  - Revert unintended change
>  - Revert unintended change
>  - Remove unused factories and add comment
>  - Merge branch 'master' into stable-updaters
>  - Add composition of functions and MHs
>  - Revert changes in stable classes
>  - Add lazy CallSite methods
>  - Reformat
>  - Add convenience methods and documentations
>  - Add low level variants
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a3634a30...9a58db6a

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697:

> 695:                 return f;
> 696:             }
> 697:         }

Is there a specific reason not to use `Class::getDeclaredField(name)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081288110

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From duke at openjdk.org  Fri May  9 09:49:56 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 9 May 2025 09:49:56 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
 <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>
Message-ID: <DyOTMoXXUwxBqUavqRB8p9vycpXjExMMtBTd44mAb84=.247bf0d6-9495-4bcd-933d-02afaa49b7d8@github.com>

On Fri, 9 May 2025 09:21:14 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Per Minborg 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 24 additional commits since the last revision:
>> 
>>  - Revert unintended change
>>  - Revert unintended change
>>  - Remove unused factories and add comment
>>  - Merge branch 'master' into stable-updaters
>>  - Add composition of functions and MHs
>>  - Revert changes in stable classes
>>  - Add lazy CallSite methods
>>  - Reformat
>>  - Add convenience methods and documentations
>>  - Add low level variants
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/b9531363...9a58db6a
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697:
> 
>> 695:                 return f;
>> 696:             }
>> 697:         }
> 
> Is there a specific reason not to use `Class::getDeclaredField(name)`?

Class::getDeclaredField(name) throws NoSuchFieldException if not found.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081336037

From vyazici at openjdk.org  Fri May  9 09:53:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 09:53:08 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v4]
In-Reply-To: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
Message-ID: <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>

> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
> 
> ### Implementation notes
> 
> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.

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

 - Fix license year
 - Move path resolution back to option parsing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25113/files
  - new: https://git.openjdk.org/jdk/pull/25113/files/2f4620b6..c28a65c1

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

  Stats: 67 lines in 5 files changed: 32 ins; 24 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25113/head:pull/25113

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

From duke at openjdk.org  Fri May  9 10:05:29 2025
From: duke at openjdk.org (kieran-farrell)
Date: Fri, 9 May 2025 10:05:29 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v2]
In-Reply-To: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
Message-ID: <wUSQaGOAgKPKltnUUoECe6tJ8ylgKsTTt1SiYc259R4=.32df958a-38e4-400b-8090-2912b025bd9b@github.com>

> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/net/InterfaceAddress.java
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25095/files
  - new: https://git.openjdk.org/jdk/pull/25095/files/f6bc4122..c3915e21

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

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

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

From duke at openjdk.org  Fri May  9 10:05:30 2025
From: duke at openjdk.org (kieran-farrell)
Date: Fri, 9 May 2025 10:05:30 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v2]
In-Reply-To: <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>
Message-ID: <iVeJJvVgL3KKUcyNtcJLZVk5pSkslFbNe3tJhwrJ-PA=.86c81e1f-9a5b-4623-a90e-b8f06cafac23@github.com>

On Wed, 7 May 2025 14:41:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/net/InterfaceAddress.java
>>   
>>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/InterfaceAddress.java line 67:
> 
>> 65:      * <p>
>> 66:      * Certain IPv4 addresses, such as the loopback address, do not support
>> 67:      * broadcasting and will also result in {@code null} being returned.
> 
> Suggestion:
> 
>      * Certain network interfaces, such as the loopback interface, do not support
>      * broadcasting and will also return {@code null}.
> 
> 
> Maybe the class level API documentation should also be updated something like:
> 
> 
>  * This class represents a Network Interface address. In short it's an
>  * IP address, a subnet mask as well as a broadcast address when the address is
>  * IPv4 and the interface supports broadcasting.
>  * An IP address and a network prefix length in the case
>  * of IPv6 address.
> 
> 
> It would be good to have @Michael-Mc-Mahon approve the wording.

Thanks Daniel, I have commited the above change in wording to the get broadcast method and updated the CSR to reflect (JDK-8356002). I will await confirmation on the class level API documentation before updating.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25095#discussion_r2081360337

From vyazici at openjdk.org  Fri May  9 12:03:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 12:03:00 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
 <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>
Message-ID: <55vG2XWXwjh5RTMa-pl1IBhJCjLwY5t4W7lHO6-sNQk=.9fc9dca9-a65d-417e-9f32-b529add482ed@github.com>

On Thu, 8 May 2025 13:53:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file.

Each JMH thread needs its own socket file. If we share the socket file folder, the following operations become error-prone due to racy nature of parallel JMH execution:

1. Creation of the parent folder
2. Creation of socket files (names shouldn't conflict)
3. Deletion of the parent folder (Parent can only be deleted when all workers are finished and their associated socket files are removed.)

Following tickets were created due to such (some stable, some intermittent) errors:

- `NoSuchFileException` error reported in the ticket this PR is addressing
- [8350915: JMH: test SocketChannelConnectionSetup failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8350915)
- [8351601: JMH: test UnixSocketChannelReadWrite failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8351601)

To avoid all this, we create a dedicated socket folder for each socket of each JMH worker. The implemented nothing-shared approach renders synchronization redundant, and hence, avoids its racy pitfalls.

> Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this class?

`ServerUdsChannelHolder` simplifies the Unix domain (UD) socket termination complexity caused by *files* involved. `SocketChannelConnectionSetup` benchmark employs both IP and UD sockets. There `ServerSocketChannelHolder` is an adapter for the termination logic, delegating to `ServerUdsChannelHolder` for UD sockets. It is possible to extend `ServerUdsChannelHolder` to also accept IP sockets, but I doubt if it worth the added complexity. Would you like me to give that a try?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2081522745

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From michaelm at openjdk.org  Fri May  9 13:03:54 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 9 May 2025 13:03:54 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <55vG2XWXwjh5RTMa-pl1IBhJCjLwY5t4W7lHO6-sNQk=.9fc9dca9-a65d-417e-9f32-b529add482ed@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
 <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>
 <55vG2XWXwjh5RTMa-pl1IBhJCjLwY5t4W7lHO6-sNQk=.9fc9dca9-a65d-417e-9f32-b529add482ed@github.com>
Message-ID: <bjZTaPT0KHhFtcKMHcfa-wuXSwt_omuqhtq3HDCPLqk=.f5504792-677c-4609-8d99-281903986cef@github.com>

On Fri, 9 May 2025 11:59:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/net/ServerUdsChannelHolder.java line 39:
>> 
>>> 37: 
>>> 38:     private final Path socketFilePath;
>>> 39: 
>> 
>> It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file. Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this class?
>
>> It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file.
> 
> Each JMH thread needs its own socket file. If we share the socket file folder, the following operations become error-prone due to racy nature of parallel JMH execution:
> 
> 1. Creation of the parent folder
> 2. Creation of socket files (names shouldn't conflict)
> 3. Deletion of the parent folder (Parent can only be deleted when all workers are finished and their associated socket files are removed.)
> 
> Following tickets were created due to such (some stable, some intermittent) errors:
> 
> - `NoSuchFileException` error reported in the ticket this PR is addressing
> - [8350915: JMH: test SocketChannelConnectionSetup failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8350915)
> - [8351601: JMH: test UnixSocketChannelReadWrite failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8351601)
> 
> To avoid all this, we create a dedicated socket folder for each socket of each JMH worker. The implemented nothing-shared approach renders synchronization redundant, and hence, avoids its racy pitfalls.
> 
>> Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this class?
> 
> `ServerUdsChannelHolder` simplifies the Unix domain (UD) socket termination complexity caused by *files* involved. `SocketChannelConnectionSetup` benchmark employs both IP and UD sockets. There `ServerSocketChannelHolder` is an adapter for the termination logic, delegating to `ServerUdsChannelHolder` for UD sockets. It is possible to extend `ServerUdsChannelHolder` to also accept IP sockets, but I doubt if it worth the added complexity. Would you like me to give that a try?

What about just doing `bind(null)`? This will create all the socket files with unique names in the system temp directory. Since no sub-directory is being created, there can't be a race trying to delete it.

Or maybe this is what the test was doing originally and it ran into some other problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2081620600

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From ihse at openjdk.org  Fri May  9 14:20:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 14:20:31 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
Message-ID: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>

A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.

While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.

I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

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

Commit messages:
 - 8356644: Update encoding declaration to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356644
  Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod
  Patch: https://git.openjdk.org/jdk/pull/25148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25148/head:pull/25148

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

From dfuchs at openjdk.org  Fri May  9 14:39:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 14:39:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:

 - merge latest changes from master branch
 - Undo whitespace change
 - Remove unnecessary import
 - Merge remote-tracking branch 'origin/master' into http3
 - Fix test license
 - Remove leftover file (test was moved to parent directory)
 - Remove unnecessary import
 - Update throws clauses
 - Merge remote-tracking branch 'origin/master' into http3
 - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
 - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=04
  Stats: 103018 lines in 469 files changed: 100164 ins; 1347 del; 1507 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From dfuchs at openjdk.org  Fri May  9 15:30:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 15:30:53 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v4]
In-Reply-To: <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
Message-ID: <nV8yDyQiKS9qaL1_FAG16g6RWcxGrd2qjnxkmKcVyb8=.157a02bf-9d67-4d2e-a010-30c9cb97e65b@github.com>

On Fri, 9 May 2025 09:53:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
>> 
>> ### Implementation notes
>> 
>> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix license year
>  - Move path resolution back to option parsing

LGTM

Sorry - I have approved too fast - aren't there some man pages to update too?

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25113#pullrequestreview-2828796875
PR Comment: https://git.openjdk.org/jdk/pull/25113#issuecomment-2867002134

From dfuchs at openjdk.org  Fri May  9 16:01:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 16:01:51 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <xYLb16pp1-tzU59PSQJwkT13-nO_nm6t51FoewRQkEc=.943e14e7-46c2-4620-83c9-b5557b7480ae@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Changes to net-properties.html LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2828873053

From mullan at openjdk.org  Fri May  9 16:45:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 16:45:08 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
Message-ID: <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

src/java.base/share/classes/java/net/HttpURLConnection.java line 615:

> 613:      */
> 614:     @Deprecated(since = "25", forRemoval = true)
> 615:     @SuppressWarnings("removal")

Do you still need this annotation now that `SocketPermission` is not deprecated for removal?

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:

> 212:      */
> 213:     @Override
> 214:     @Deprecated(since = "25", forRemoval = true)

Is this annotation required or more as a reminder that the superclass method is deprecated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082086475
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082050913

From dfuchs at openjdk.org  Fri May  9 19:21:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 19:21:56 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
 <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>
Message-ID: <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>

On Fri, 9 May 2025 16:42:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into deprecate-net-perms-8353642
>>  - Revert changes to SocketPermission and CodeSource
>>  - Review feedback. Deprecate getPermission for removal.
>>  - Missing white spaces
>>  - 8353642: Deprecate networking permission classes for removal
>
> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
> 
>> 613:      */
>> 614:     @Deprecated(since = "25", forRemoval = true)
>> 615:     @SuppressWarnings("removal")
> 
> Do you still need this annotation now that `SocketPermission` is not deprecated for removal?

Ah - good point - I will double check.

> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:
> 
>> 212:      */
>> 213:     @Override
>> 214:     @Deprecated(since = "25", forRemoval = true)
> 
> Is this annotation required or more as a reminder that the superclass method is deprecated?

I think it's needed because the superclass method is deprecated for removal. Will double check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082374190
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082374078

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From prr at openjdk.org  Fri May  9 20:53:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:53:52 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <Smz6J8OkGf1azxvWU7doxgpYm42StyU8_196s8ZNmGU=.70a7da27-72e6-40dc-81b0-c57f65d4cfdc@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829627877

From wetmore at openjdk.org  Fri May  9 21:38:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 9 May 2025 21:38:07 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8341346
 - Adjustments made for JDK-8350830
 - Merge branch 'master' into JDK-8341346
 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
 - More Codereview comments
 - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
 - Add in the SharedSecrets SecretKeySpec clearing mechanism
 - More codereview/CSR comments
 - Merge branch 'master' into JDK-8341346
 - Codereview comments.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=09
  Stats: 1096 lines in 8 files changed: 1076 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From naoto at openjdk.org  Fri May  9 23:18:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 23:18:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <UqQ7Tm8xYaIcxM4GvA9ISQi7kDMs1WwuEvbC2kRo1CQ=.a38e9c07-04dd-4fba-a118-4afd33951c06@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829881137

From weijun at openjdk.org  Sat May 10 13:50:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 10 May 2025 13:50:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
Message-ID: <IXN3i7znzSlcsc2VGa3hyO7PgH6XKAk8UTtpjNBx990=.6015b538-4aea-4dc2-a3bf-4b27e99a58d3@github.com>

On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - More codereview/CSR comments
>  - Merge branch 'master' into JDK-8341346
>  - Codereview comments.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

Register your new algorithm "TlsExporterMasterSecret" at https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272.

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

PR Comment: https://git.openjdk.org/jdk/pull/24976#issuecomment-2868873399

From vyazici at openjdk.org  Mon May 12 07:24:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 07:24:33 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v3]
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <1F5ZOQTkUatrX8mI9hqmDRFwZvM74T_5vMzdCwiSP1c=.4ce38081-27fb-4012-950d-a7de7a88bac7@github.com>

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

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

  Simplify UDS clean-up logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24568/files
  - new: https://git.openjdk.org/jdk/pull/24568/files/57e7ed7d..0b33d932

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

  Stats: 120 lines in 3 files changed: 16 ins; 93 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24568/head:pull/24568

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

From vyazici at openjdk.org  Mon May 12 07:43:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 07:43:53 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <bjZTaPT0KHhFtcKMHcfa-wuXSwt_omuqhtq3HDCPLqk=.f5504792-677c-4609-8d99-281903986cef@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
 <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>
 <55vG2XWXwjh5RTMa-pl1IBhJCjLwY5t4W7lHO6-sNQk=.9fc9dca9-a65d-417e-9f32-b529add482ed@github.com>
 <bjZTaPT0KHhFtcKMHcfa-wuXSwt_omuqhtq3HDCPLqk=.f5504792-677c-4609-8d99-281903986cef@github.com>
Message-ID: <F4sVz8v3QBv-Am_tOv8NKOr5jkveOg533V5pS3XIg8o=.e3c2dd8a-715c-40de-866f-cb768d3732f5@github.com>

On Fri, 9 May 2025 13:01:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>>> It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file.
>> 
>> Each JMH thread needs its own socket file. If we share the socket file folder, the following operations become error-prone due to racy nature of parallel JMH execution:
>> 
>> 1. Creation of the parent folder
>> 2. Creation of socket files (names shouldn't conflict)
>> 3. Deletion of the parent folder (Parent can only be deleted when all workers are finished and their associated socket files are removed.)
>> 
>> Following tickets were created due to such (some stable, some intermittent) errors:
>> 
>> - `NoSuchFileException` error reported in the ticket this PR is addressing
>> - [8350915: JMH: test SocketChannelConnectionSetup failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8350915)
>> - [8351601: JMH: test UnixSocketChannelReadWrite failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8351601)
>> 
>> To avoid all this, we create a dedicated socket folder for each socket of each JMH worker. The implemented nothing-shared approach renders synchronization redundant, and hence, avoids its racy pitfalls.
>> 
>>> Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this class?
>> 
>> `ServerUdsChannelHolder` simplifies the Unix domain (UD) socket termination complexity caused by *files* involved. `SocketChannelConnectionSetup` benchmark employs both IP and UD sockets. There `ServerSocketChannelHolder` is an adapter for the termination logic, delegating to `ServerUdsChannelHolder` for UD sockets. It is possible to extend `ServerUdsChannelHolder` to also accept IP sockets, but I doubt if it worth the added complexity. Would you like me to give that a try?
>
> What about just doing `bind(null)`? This will create all the socket files with unique names in the system temp directory. Since no sub-directory is being created, there can't be a race trying to delete it.
> 
> Or maybe this is what the test was doing originally and it ran into some other problem?

I thought `bind(null)` was not an option, since all UDS-involving benchmarks were designed with explicit file paths. Though upon closer look, I don't see any reason why those can't simply be replaced with `bind(null)` ? implemented in 0b33d9321dd. Thanks to your suggestion, now this PR brings even a healthier diet:


2 files changed, 15 insertions(+), 54 deletions(-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2084028318

From vyazici at openjdk.org  Mon May 12 07:51:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 07:51:51 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v4]
In-Reply-To: <nV8yDyQiKS9qaL1_FAG16g6RWcxGrd2qjnxkmKcVyb8=.157a02bf-9d67-4d2e-a010-30c9cb97e65b@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
 <nV8yDyQiKS9qaL1_FAG16g6RWcxGrd2qjnxkmKcVyb8=.157a02bf-9d67-4d2e-a010-30c9cb97e65b@github.com>
Message-ID: <Hw6nD7P-se-YcsEQgJzfuwXQltlM8Dn4coe857TvvCg=.406796d1-d2e0-4465-ac5d-a85192dc9bf2@github.com>

On Fri, 9 May 2025 15:28:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix license year
>>  - Move path resolution back to option parsing
>
> Sorry - I have approved too fast - aren't there some man pages to update too? Ah - no - I see the man page just says:
>> -d dir or --directory dir
>>     Specifies the directory to serve. Default: current directory.
> 
> We should be good then.

@dfuch, I'd checked `jwebserver.md` and also concluded no change is needed there. In particular, I'd found the following mention of _absolute path_ of interest:

> If startup is successful, the server prints a message to `System.out`
> listing the local address and the absolute path of the directory being
> served.

We still comply with this behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/25113#issuecomment-2871267437

From vyazici at openjdk.org  Mon May 12 11:26:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 11:26:30 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v4]
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <yGOk2C5RN1Etds4PYI5Ocn4uHtgk8-3CnxJ3I6Ek8qo=.37c85d34-466b-4a34-81e5-31fe5c39dc73@github.com>

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

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

  Improve UDS file path obtain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24568/files
  - new: https://git.openjdk.org/jdk/pull/24568/files/0b33d932..ffd31a46

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

  Stats: 20 lines in 2 files changed: 13 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24568/head:pull/24568

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

From vyazici at openjdk.org  Mon May 12 11:26:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 11:26:30 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <F4sVz8v3QBv-Am_tOv8NKOr5jkveOg533V5pS3XIg8o=.e3c2dd8a-715c-40de-866f-cb768d3732f5@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
 <NX8WMmRbVbG7AQ72Olk82gHKuZvzdFLH9ra3RwcSbuY=.9e697110-a811-44fc-9164-5f04863a771b@github.com>
 <55vG2XWXwjh5RTMa-pl1IBhJCjLwY5t4W7lHO6-sNQk=.9fc9dca9-a65d-417e-9f32-b529add482ed@github.com>
 <bjZTaPT0KHhFtcKMHcfa-wuXSwt_omuqhtq3HDCPLqk=.f5504792-677c-4609-8d99-281903986cef@github.com>
 <F4sVz8v3QBv-Am_tOv8NKOr5jkveOg533V5pS3XIg8o=.e3c2dd8a-715c-40de-866f-cb768d3732f5@github.com>
Message-ID: <919BW8_cREqQ7me9Nd4Xxqe6iIoa-boorIc1b4pU67s=.5e63b787-23e3-4399-b5be-2777e05fc066@github.com>

On Mon, 12 May 2025 07:41:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> What about just doing `bind(null)`? This will create all the socket files with unique names in the system temp directory. Since no sub-directory is being created, there can't be a race trying to delete it.
>> 
>> Or maybe this is what the test was doing originally and it ran into some other problem?
>
> I thought `bind(null)` was not an option, since all UDS-involving benchmarks were designed with explicit file paths. Though upon closer look, I don't see any reason why those can't simply be replaced with `bind(null)` ? implemented in 0b33d9321dd. Thanks to your suggestion, now this PR brings even a healthier diet:
> 
> 
> 2 files changed, 15 insertions(+), 54 deletions(-)

Tipped by @dfuch that `bind(null)` was probably avoided to not pollute `/tmp`. Per his suggestion, sticked to using `bind(null)`, though improved how we obtain the UDS file path in ffd31a462e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2084462994

From mullan at openjdk.org  Mon May 12 15:09:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 15:09:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
Message-ID: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>

On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - More codereview/CSR comments
>  - Merge branch 'master' into JDK-8341346
>  - Codereview comments.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 172:

> 170:      * algorithms defined in RFCs 5705/8446.
> 171:      * <P>
> 172:      * Note RFC 5705 (for (D)TLSv1.2 and earlier) calculates different EKM

s/Note/Note that/

(or just remove "Note" - don't think it is really necessary).

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 187:

> 185:      *
> 186:      * @implSpec The default implementation throws
> 187:      *           {@code UnsupportedOperationException}

Missing period at end of sentence.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 192:

> 190:      *                {@code label} will be converted to a {@code byte[]}
> 191:      *                before the operation begins
> 192:      * @param context the context bytes used in the EKM calculation

Add something that says `null` is acceptable. i.e. ", or `null` ..."

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 195:

> 193:      * @param length  the number of bytes of EKM material needed
> 194:      *
> 195:      * @throws SSLKeyException if the key could not be generated

I prefer "cannot" (present tense).

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 204:

> 202:      *
> 203:      * @return a {@code SecretKey} that contains {@code length} bytes of the
> 204:      *         EKM material.

no period necessary.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 225:

> 223:      * character encoding.
> 224:      * <P>
> 225:      * Depending on the chosen underlying key derivation mechanism, the

This reads like it should maybe be an `@apiNote`.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:

> 252:      *
> 253:      * @return a byte array of size {@code length} that contains the EKM
> 254:      *         material, or null if the derived key material does not support

For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084853417
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084889527
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084879618
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084887858
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084891743
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084895438
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084899365

From dfuchs at openjdk.org  Mon May 12 15:18:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:18:53 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
 <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>
 <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>
Message-ID: <U2QMsL5uezCwMxcjozzvVh7KTqBNKaenQb3aYOHu-4U=.ad1ac8b5-0ddb-4be1-ae22-884cb564e1c5@github.com>

On Fri, 9 May 2025 19:18:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:
>> 
>>> 212:      */
>>> 213:     @Override
>>> 214:     @Deprecated(since = "25", forRemoval = true)
>> 
>> Is this annotation required or more as a reminder that the superclass method is deprecated?
>
> I think it's needed because the superclass method is deprecated for removal. Will double check.

Yes - it is needed. If you override a deprecated method you need to carry the deprecation annotation over. Here is what I got when I tried to remove the annotation on `HttpURLConnection::getPermission()` (the same error occurred on any subclass where I attempted to remove the annotation):

java/net/HttpURLConnection.java:615: warning: [dep-ann] deprecated item is not annotated with @Deprecated
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084915172

From dfuchs at openjdk.org  Mon May 12 15:24:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:24:52 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
 <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>
 <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>
Message-ID: <aDpBmRxc5KgwnQOFjVD7c5pCtxaRiu1KORv8hmcFLVA=.9720ebb5-a908-4d8e-aa46-deae7c29ef7d@github.com>

On Fri, 9 May 2025 19:19:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
>> 
>>> 613:      */
>>> 614:     @Deprecated(since = "25", forRemoval = true)
>>> 615:     @SuppressWarnings("removal")
>> 
>> Do you still need this annotation now that `SocketPermission` is not deprecated for removal?
>
> Ah - good point - I will double check.

Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:


src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084927109

From michaelm at openjdk.org  Mon May 12 15:28:54 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 12 May 2025 15:28:54 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v4]
In-Reply-To: <yGOk2C5RN1Etds4PYI5Ocn4uHtgk8-3CnxJ3I6Ek8qo=.37c85d34-466b-4a34-81e5-31fe5c39dc73@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <yGOk2C5RN1Etds4PYI5Ocn4uHtgk8-3CnxJ3I6Ek8qo=.37c85d34-466b-4a34-81e5-31fe5c39dc73@github.com>
Message-ID: <86jdh9ue2iWbyVyXFEtMe-gaIzHth0C-MfnK653_g8E=.88cb7355-9e04-4b69-8278-85e256b1f084@github.com>

On Mon, 12 May 2025 11:26:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve UDS file path obtain

test/micro/org/openjdk/bench/java/net/SocketChannelConnectionSetup.java line 58:

> 56: 
> 57:     @Param({"INET", "UNIX"})
> 58:     private volatile String family;

This version looks a lot simpler, which is good. This question applies regardless of your change but I'm wondering why the field `family` is volatile but the other fields such as `sscFilePath` are not? I guess if we are sure that the JMH configuration guarantees that the setup, teardown and test methods are all run by the same thread, then they don't need to be volatile. But, I'm not sure if that is the case..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2084934999

From abarashev at openjdk.org  Mon May 12 16:12:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 16:12:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are not
 being checked with default SunX509 key manager
Message-ID: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>

When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3

X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

Commit messages:
 - Add unit test
 - Code refactoring
 - Fix open unit tests
 - Adding a system property to skip the constraints checking. Remove SunX509c.
 - Fix constraints check
 - Revert SSLHandshake.java. Set SunX509c as default. Update copyright.
 - 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager
 - Address review comments
 - Skip explicit KeyPair initialization and let the provider default set it
 - Rework unit tests
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cd8adf13...75528109

Changes: https://git.openjdk.org/jdk/pull/25016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353113
  Stats: 1168 lines in 15 files changed: 769 ins; 333 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From mullan at openjdk.org  Mon May 12 16:22:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:22:59 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <aDpBmRxc5KgwnQOFjVD7c5pCtxaRiu1KORv8hmcFLVA=.9720ebb5-a908-4d8e-aa46-deae7c29ef7d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
 <giEqaWFtmWFZQ7AW3NB7P5hVGsiuCgXO1qFeTuZ9Gmc=.d87108d7-1f47-45d4-b700-1491382c87b3@github.com>
 <h0FZ4ZpvOFVxSm-oxQGwa_JQDAlSqpsVLMAyg60vk1M=.1c918b79-e467-418f-9313-eb2f9b5263b9@github.com>
 <aDpBmRxc5KgwnQOFjVD7c5pCtxaRiu1KORv8hmcFLVA=.9720ebb5-a908-4d8e-aa46-deae7c29ef7d@github.com>
Message-ID: <gcDFVgQ1t1Su1NqM2IkAMvWVchEMOyZVZqRx3oalhh8=.970549d6-0d2a-4d93-99e2-1a59598915b9@github.com>

On Mon, 12 May 2025 15:21:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Ah - good point - I will double check.
>
> Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:
> 
> 
> src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
>     public Permission getPermission() throws IOException {
>                       ^
> error: warnings found and -Werror specified

Ok, but seems redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2085033749

From mullan at openjdk.org  Mon May 12 16:27:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:27:54 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <a63N1pWvC0rA3reJPd1dCmVYmgJ0sPrP4b1nMsjVPpo=.bcbbd591-725c-4ae7-a547-2b350a0ef41d@github.com>
Message-ID: <nR_0ATcPyS2Om9kXJXXOsjiFHdkrF4x7jFVdsswi2c8=.3950443b-96a6-489e-87a1-0270a3bc2318@github.com>

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2833821389

From dfuchs at openjdk.org  Mon May 12 16:52:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 16:52:57 GMT
Subject: Integrated: 8353642: Deprecate URL::getPermission method and
 networking permission classes for removal
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <Ak2iI5CmxRHn0y3eYhaBxXroyJi2Cs93wg5CErIuUqw=.d23644e1-ee1b-4f18-a431-a0c96e282bf4@github.com>

On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

This pull request has now been integrated.

Changeset: 45dfc2c6
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45dfc2c6d6d6b2b0749347b0150bb22d49f12767
Stats:     41 lines in 11 files changed: 25 ins; 4 del; 12 mod

8353642: Deprecate URL::getPermission method and networking permission classes for removal

Reviewed-by: djelinski, iris, mullan, michaelm

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

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

From abarashev at openjdk.org  Mon May 12 18:45:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 18:45:10 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v2]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <1Gpnwbv3_IexuWpsDF0ebvnlgcVpRzY_t3NTR639sMA=.c69a02d9-8139-4068-bfba-23ba8424b5f7@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

  Add PeerConstraintsCheck unit test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/75528109..88cd4016

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

  Stats: 284 lines in 3 files changed: 277 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From vyazici at openjdk.org  Mon May 12 19:08:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:08:10 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v5]
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <XftjyvoejjHOfyTEhdpH_8XSj_5SnJS5YfqnDidXg2U=.b49ed299-13bb-4da1-877f-2dac97d28a6b@github.com>

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

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

  Remove redundant `volatile` modifier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24568/files
  - new: https://git.openjdk.org/jdk/pull/24568/files/ffd31a46..d830ec8b

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

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

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

From vyazici at openjdk.org  Mon May 12 19:08:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:08:11 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v4]
In-Reply-To: <86jdh9ue2iWbyVyXFEtMe-gaIzHth0C-MfnK653_g8E=.88cb7355-9e04-4b69-8278-85e256b1f084@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <yGOk2C5RN1Etds4PYI5Ocn4uHtgk8-3CnxJ3I6Ek8qo=.37c85d34-466b-4a34-81e5-31fe5c39dc73@github.com>
 <86jdh9ue2iWbyVyXFEtMe-gaIzHth0C-MfnK653_g8E=.88cb7355-9e04-4b69-8278-85e256b1f084@github.com>
Message-ID: <Wnqr9soEC5YnVl9pWULi80YaWWPfNoyNt-Xc2tj0K-8=.4fe25795-5757-4cf5-b9b9-206ad41c6a3e@github.com>

On Mon, 12 May 2025 15:25:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve UDS file path obtain
>
> test/micro/org/openjdk/bench/java/net/SocketChannelConnectionSetup.java line 58:
> 
>> 56: 
>> 57:     @Param({"INET", "UNIX"})
>> 58:     private volatile String family;
> 
> This version looks a lot simpler, which is good. This question applies regardless of your change but I'm wondering why the field `family` is volatile but the other fields such as `sscFilePath` are not? I guess if we are sure that the JMH configuration guarantees that the setup, teardown and test methods are all run by the same thread, then they don't need to be volatile. But, I'm not sure if that is the case..

Correct. Removed `volatile` from `family` too in d830ec8b3c9.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2085284855

From duke at openjdk.org  Mon May 12 19:09:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 12 May 2025 19:09:54 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v4]
In-Reply-To: <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
Message-ID: <Ev_hVk1SUqfR9GAZoXddibbaf1DIj897Z2Lg339AD4c=.214520f4-ce4e-4764-a5b1-476a6b56b862@github.com>

On Fri, 9 May 2025 09:53:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
>> 
>> ### Implementation notes
>> 
>> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix license year
>  - Move path resolution back to option parsing

@vy 
Your change (at version c28a65c1c4d0b6e835487a7f971ba23459840ecc) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25113#issuecomment-2873703209

From vyazici at openjdk.org  Mon May 12 19:53:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:53:35 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v6]
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <yvSF2BKFl3GqjdYk-mLiJC-Wd0OFinjr-yNtLztVReY=.b6f0235e-0506-4d4b-ba3e-a40ef8e20919@github.com>

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

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

 - Merge remote-tracking branch 'upstream/master' into jmh-unix-sock
 - Remove redundant `volatile` modifier
 - Improve UDS file path obtain
 - Simplify UDS clean-up logic
 - Fix copyright year
 - 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24568/files
  - new: https://git.openjdk.org/jdk/pull/24568/files/d830ec8b..07675a43

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

  Stats: 311949 lines in 3253 files changed: 98200 ins; 200412 del; 13337 mod
  Patch: https://git.openjdk.org/jdk/pull/24568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24568/head:pull/24568

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

From abarashev at openjdk.org  Mon May 12 20:05:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 20:05:18 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

  Make sure the exception happens during KeyManager's algorithm check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/88cd4016..5c137c14

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

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

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

From serb at openjdk.org  Tue May 13 00:13:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:13:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

src/demo/share/jfc/CodePointIM/README.html line 5:

> 3: <head>
> 4:   <title>README - CodePointIM</title>
> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">

I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2085710719

From hchao at openjdk.org  Tue May 13 03:58:53 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 13 May 2025 03:58:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
Message-ID: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>

On Mon, 12 May 2025 20:05:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure the exception happens during KeyManager's algorithm check

It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. When setting this property to true, it will disable the existing RFC compliant algorithm constraints checking even in `X509KeyManagerImpl`, and we?d want to avoid that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2874984309

From wetmore at openjdk.org  Tue May 13 04:57:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 04:57:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: <yKdi_XyyqlhhC5KXMx4pPxK7wiEUilxTCIaxEuRFsnU=.cba3819a-f9ea-45f3-8839-0ad2328897d1@github.com>

On Mon, 12 May 2025 14:45:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 172:
> 
>> 170:      * algorithms defined in RFCs 5705/8446.
>> 171:      * <P>
>> 172:      * Note RFC 5705 (for (D)TLSv1.2 and earlier) calculates different EKM
> 
> s/Note/Note that/
> 
> (or just remove "Note" - don't think it is really necessary).

Removed "Note"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085917566

From wetmore at openjdk.org  Tue May 13 04:57:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 04:57:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <IXN3i7znzSlcsc2VGa3hyO7PgH6XKAk8UTtpjNBx990=.6015b538-4aea-4dc2-a3bf-4b27e99a58d3@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <IXN3i7znzSlcsc2VGa3hyO7PgH6XKAk8UTtpjNBx990=.6015b538-4aea-4dc2-a3bf-4b27e99a58d3@github.com>
Message-ID: <kc6MPA5rKwFWfLJsOb58PIBiYx5NLYspvkB5LKT7TMU=.a083d25d-2ea7-4921-ab29-319e6f688252@github.com>

On Sat, 10 May 2025 13:48:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> Register your new algorithm "TlsExporterMasterSecret" at https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272.

@wangweij 

> Register your new algorithm "TlsExporterMasterSecret" at
> 
> https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272
> .

I registered both `TlsExporterMasterSecret` and `TlsExporterKeyingMaterial` in `P11SecretKeyFactory` and tweaked the creation call sites.  I'll test this out tomorrow with some of the PKCS11 tests in mach5.

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

PR Comment: https://git.openjdk.org/jdk/pull/24976#issuecomment-2875046444

From wetmore at openjdk.org  Tue May 13 05:06:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:06:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: <yBG6hpsg0yYpEIGpMpgx_d-WRooMz7pLwnJJV7KPfSE=.15967d19-d8cb-41a8-b98c-e6a9c5375e45@github.com>

On Mon, 12 May 2025 15:02:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 187:
> 
>> 185:      *
>> 186:      * @implSpec The default implementation throws
>> 187:      *           {@code UnsupportedOperationException}
> 
> Missing period at end of sentence.

Added.  I also readded:

     *           Classes derived from ExtendedSSLSession must implement
     *           this method.

which is also used in an earlier method (`getStatusResponses`) in this class.

> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 195:
> 
>> 193:      * @param length  the number of bytes of EKM material needed
>> 194:      *
>> 195:      * @throws SSLKeyException if the key could not be generated
> 
> I prefer "cannot" (present tense).

Done

> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 204:
> 
>> 202:      *
>> 203:      * @return a {@code SecretKey} that contains {@code length} bytes of the
>> 204:      *         EKM material.
> 
> no period necessary.

Corrected.  

Even when you look 10 times at something, you still miss something obvious like this!  ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085923797
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085924241
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085924913

From wetmore at openjdk.org  Tue May 13 05:18:08 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:18:08 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: <ASd1LeY3bzPuc28CZLC-FdAsonbMzf1QV7yEXvoW6Nk=.ead0f917-036d-4f6e-a2e3-4f0e190da565@github.com>

On Mon, 12 May 2025 15:07:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
> 
>> 252:      *
>> 253:      * @return a byte array of size {@code length} that contains the EKM
>> 254:      *         material, or null if the derived key material does not support
> 
> For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?

I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  

I could go either way on this.  I realize I need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085932412

From wetmore at openjdk.org  Tue May 13 05:18:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:18:07 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v11]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <1jREDk0Rw6H4WBRbAnFw1HtGPoddkcsYjabS9FfQAlI=.b2a5daaf-bc1f-4d70-9233-5fc0e50df0d8@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  More codereview comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/bd227aa8..b21a42d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=09-10

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

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

From wetmore at openjdk.org  Tue May 13 05:32:34 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:32:34 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Missed one review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/b21a42d0..0da8f6f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=10-11

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

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

From wetmore at openjdk.org  Tue May 13 05:32:36 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:32:36 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: <DKlg61xuY0ahjvfd7_6e3Qt9ncHt-xoRX84hxruCMiA=.c4a534c4-c76e-4802-8f34-deed57793095@github.com>

On Mon, 12 May 2025 14:58:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 192:
> 
>> 190:      *                {@code label} will be converted to a {@code byte[]}
>> 191:      *                before the operation begins
>> 192:      * @param context the context bytes used in the EKM calculation
> 
> Add something that says `null` is acceptable. i.e. ", or `null` ..."

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085945713

From michaelm at openjdk.org  Tue May 13 07:36:59 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 13 May 2025 07:36:59 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v6]
In-Reply-To: <yvSF2BKFl3GqjdYk-mLiJC-Wd0OFinjr-yNtLztVReY=.b6f0235e-0506-4d4b-ba3e-a40ef8e20919@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <yvSF2BKFl3GqjdYk-mLiJC-Wd0OFinjr-yNtLztVReY=.b6f0235e-0506-4d4b-ba3e-a40ef8e20919@github.com>
Message-ID: <QoDLoQ-kMKhOUHzn-KRIn37mrRvBhYSIgE4bW5TDrvA=.82a097dd-450e-419e-b374-c5f8d76918d0@github.com>

On Mon, 12 May 2025 19:53:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into jmh-unix-sock
>  - Remove redundant `volatile` modifier
>  - Improve UDS file path obtain
>  - Simplify UDS clean-up logic
>  - Fix copyright year
>  - 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

Looks fine to me

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24568#pullrequestreview-2835600508

From duke at openjdk.org  Tue May 13 07:44:57 2025
From: duke at openjdk.org (duke)
Date: Tue, 13 May 2025 07:44:57 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v6]
In-Reply-To: <yvSF2BKFl3GqjdYk-mLiJC-Wd0OFinjr-yNtLztVReY=.b6f0235e-0506-4d4b-ba3e-a40ef8e20919@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <yvSF2BKFl3GqjdYk-mLiJC-Wd0OFinjr-yNtLztVReY=.b6f0235e-0506-4d4b-ba3e-a40ef8e20919@github.com>
Message-ID: <AGAFTu6jzwyu7aqM4KlAMgg4xjbZwCV4xWGIgzQBhk0=.0802d89b-92b8-4397-a5d8-7cf0ebfebbfc@github.com>

On Mon, 12 May 2025 19:53:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into jmh-unix-sock
>  - Remove redundant `volatile` modifier
>  - Improve UDS file path obtain
>  - Simplify UDS clean-up logic
>  - Fix copyright year
>  - 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

@vy 
Your change (at version 07675a43a4be8d203cc51f284ce80bd6619f08f5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24568#issuecomment-2875396718

From michaelm at openjdk.org  Tue May 13 08:01:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 13 May 2025 08:01:01 GMT
Subject: RFR: 8355360: -d option of jwebserver command should accept
 relative paths [v4]
In-Reply-To: <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
 <TBJQh4bHT3CbEJHPlS-vN-Cra_Dela-Ln-htD7p708U=.d4b855eb-363a-4a1d-a82e-9dd5ff721c3a@github.com>
Message-ID: <ySyyXL5CY0cnpTsKrDAKx9W12bYqRQb0xSsqHVOYwak=.60f80363-0761-421a-ae6f-2ca5185461d1@github.com>

On Fri, 9 May 2025 09:53:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
>> 
>> ### Implementation notes
>> 
>> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix license year
>  - Move path resolution back to option parsing

Looks good also. Might benefit from a release note

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25113#pullrequestreview-2835662892

From vyazici at openjdk.org  Tue May 13 08:01:01 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 08:01:01 GMT
Subject: Integrated: 8355360: -d option of jwebserver command should accept
 relative paths
In-Reply-To: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
References: <yfUuLtzouvao_AdJ5nmL-vTCkx-2lHlWZE57oFzE_RU=.93edae93-5de0-4881-b224-526f4f897df1@github.com>
Message-ID: <9-CYsc7ORm0T9TeIbsEEeogNGH1JPH8DPPQsxCEQWWI=.df8f8a87-f825-49c6-98f0-eeea1f6e9929@github.com>

On Thu, 8 May 2025 09:01:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Allows relative paths in the content root directory passed to the `jwebserver`. Changes effect both the `jwebserver` executable and the `java -m jdk.httpserver` execution.
> 
> ### Implementation notes
> 
> Received `Path` is read using `toRealPath()`, and then employed in `s.n.h.s.FileServerHandler`, which is the only place in the web server code where an absolute path requirement is present.

This pull request has now been integrated.

Changeset: ad161a4e
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad161a4ef85e03d4b7be3df2d584356bf4f7cc80
Stats:     172 lines in 6 files changed: 96 ins; 28 del; 48 mod

8355360: -d option of jwebserver command should accept relative paths

Reviewed-by: dfuchs, michaelm

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

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

From vyazici at openjdk.org  Tue May 13 08:21:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 08:21:03 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers
Message-ID: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>

Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.

### Demonstration

Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:

**Before:**

INFO: HEADERS: RESPONSE HEADERS:
    connection: Upgrade
    upgrade: h2c
...
INFO: HEADERS: RESPONSE HEADERS:
    :status: 304
    content-length: 300


**After:** 

INFO: HEADERS: RESPONSE HEADERS:
  GET http://127.0.0.1:48497/ 101
    connection: Upgrade
    upgrade: h2c
...
INFO: HEADERS: RESPONSE HEADERS (streamid=1):
  GET http://127.0.0.1:48497/ 304
    :status: 304
    content-length: 300

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

Commit messages:
 - Improve HTTP response header logging

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

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

From michaelm at openjdk.org  Tue May 13 10:02:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 13 May 2025 10:02:01 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v2]
In-Reply-To: <iVeJJvVgL3KKUcyNtcJLZVk5pSkslFbNe3tJhwrJ-PA=.86c81e1f-9a5b-4623-a90e-b8f06cafac23@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>
 <iVeJJvVgL3KKUcyNtcJLZVk5pSkslFbNe3tJhwrJ-PA=.86c81e1f-9a5b-4623-a90e-b8f06cafac23@github.com>
Message-ID: <jv2OE1ILTzpy_kOelalptpSX-2oKCT0KcVU57Rfh9Sc=.abbce7ca-2221-459f-b61f-997fa9d6cc85@github.com>

On Fri, 9 May 2025 10:02:25 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/InterfaceAddress.java line 67:
>> 
>>> 65:      * <p>
>>> 66:      * Certain IPv4 addresses, such as the loopback address, do not support
>>> 67:      * broadcasting and will also result in {@code null} being returned.
>> 
>> Suggestion:
>> 
>>      * Certain network interfaces, such as the loopback interface, do not support
>>      * broadcasting and will also return {@code null}.
>> 
>> 
>> Maybe the class level API documentation should also be updated something like:
>> 
>> 
>>  * This class represents a Network Interface address. In short it's an
>>  * IP address, a subnet mask as well as a broadcast address when the address is
>>  * IPv4 and the interface supports broadcasting.
>>  * An IP address and a network prefix length in the case
>>  * of IPv6 address.
>> 
>> 
>> It would be good to have @Michael-Mc-Mahon approve the wording.
>
> Thanks Daniel, I have commited the above change in wording to the get broadcast method and updated the CSR to reflect (JDK-8356002). I will await confirmation on the class level API documentation before updating.

I think the original wording of the class level doc was phrased awkwardly. I'd like to suggest the following:

 * This class represents a Network Interface address. In the case of
 * IPv4, this comprises the IP address, a subnet mask, and a broadcast 
 * address if the interface supports broadcast. In the case of IPv6, 
 * it comprises the IP address and a network prefix length.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25095#discussion_r2086419179

From vyazici at openjdk.org  Tue May 13 11:10:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 11:10:59 GMT
Subject: Integrated: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <P1seGODAHIarYVIFh_TVxV2hf7_M49GpIEzzeLPp8vA=.23412a97-06a9-439d-8887-7064241f26ab@github.com>

On Thu, 10 Apr 2025 10:38:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

This pull request has now been integrated.

Changeset: 7dcc386a
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7dcc386af9831bea21def6763512c9fba13b5064
Stats:     67 lines in 2 files changed: 13 ins; 43 del; 11 mod

8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

Reviewed-by: michaelm

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

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

From mullan at openjdk.org  Tue May 13 12:32:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 12:32:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
Message-ID: <AfDAoZuNDojI7yoSF3YLac17j7sM8DHWX7P0bZSJbDo=.0d01d5c9-bdc6-41e3-b6ac-5cbabb038c1e@github.com>

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 189:

> 187:      *           {@code UnsupportedOperationException}.
> 188:      *           Classes derived from ExtendedSSLSession must implement
> 189:      *           this method.

That statement is too strong, even though `getStatusResponses` has that text, unfortunately. For one, existing provider implementations of this class are binary compatible if they upgrade to JDK 25 because they don't have to implement this method right away since it has a default implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086679927

From mullan at openjdk.org  Tue May 13 12:32:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 12:32:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <ASd1LeY3bzPuc28CZLC-FdAsonbMzf1QV7yEXvoW6Nk=.ead0f917-036d-4f6e-a2e3-4f0e190da565@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
 <ASd1LeY3bzPuc28CZLC-FdAsonbMzf1QV7yEXvoW6Nk=.ead0f917-036d-4f6e-a2e3-4f0e190da565@github.com>
Message-ID: <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>

On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
>> 
>>> 252:      *
>>> 253:      * @return a byte array of size {@code length} that contains the EKM
>>> 254:      *         material, or null if the derived key material does not support
>> 
>> For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?
>
> I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  
> 
> I could go either way on this.  I do need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086700249

From weijun at openjdk.org  Tue May 13 13:09:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:09:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
 <ASd1LeY3bzPuc28CZLC-FdAsonbMzf1QV7yEXvoW6Nk=.ead0f917-036d-4f6e-a2e3-4f0e190da565@github.com>
 <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>
Message-ID: <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com>

On Tue, 13 May 2025 12:26:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  
>> 
>> I could go either way on this.  I do need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.
>
> It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.

+1 for UOE. It's not that we got a key and found it un-extractable. It's that we asked for data but were refused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086786782

From weijun at openjdk.org  Tue May 13 13:27:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:27:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
Message-ID: <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1598:

> 1596:             //     L    length of output keying material in octets
> 1597:             //          (<= 255*HashLen)
> 1598:             if (length >= (255 * cipherSuite.hashAlg.hashLength )) {

The opposite of `<=` is `>`.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650:

> 1648:                     emptyHash = md.digest();
> 1649:                 } catch (NoSuchAlgorithmException nsae) {
> 1650:                     throw new RuntimeException(

We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086821812
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086826499

From weijun at openjdk.org  Tue May 13 13:39:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:39:57 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
Message-ID: <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682:

> 1680:                     // ...now the final expand.
> 1681:                     return (deriveKey ?
> 1682:                             hkdf.deriveKey("TlsExporterKeyingMaterial",

Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086854025

From dfuchs at openjdk.org  Tue May 13 13:56:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 May 2025 13:56:00 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers
In-Reply-To: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
Message-ID: <qWkPAN5If92yXgltmFs5qIUuMRxCyHhbNvYxv4KY-k8=.33a82898-f553-47b0-9b25-7428d2824da4@github.com>

On Tue, 13 May 2025 08:15:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
> 
> ### Demonstration
> 
> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
> 
> **Before:**
> 
> INFO: HEADERS: RESPONSE HEADERS:
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     :status: 304
>     content-length: 300
> 
> 
> **After:** 
> 
> INFO: HEADERS: RESPONSE HEADERS:
>   GET http://127.0.0.1:48497/ 101
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>   GET http://127.0.0.1:48497/ 304
>     :status: 304
>     content-length: 300

Very nice!

It would be good to add the `(streamId=<streamId>)` at line 676 too in Stream.java (Trailing Headers),  and to add the whole line (`GET <uri> <status-code>`) at line 1782 (push response headers).

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

PR Comment: https://git.openjdk.org/jdk/pull/25201#issuecomment-2876622516

From dfuchs at openjdk.org  Tue May 13 13:58:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 May 2025 13:58:53 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v2]
In-Reply-To: <jv2OE1ILTzpy_kOelalptpSX-2oKCT0KcVU57Rfh9Sc=.abbce7ca-2221-459f-b61f-997fa9d6cc85@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>
 <iVeJJvVgL3KKUcyNtcJLZVk5pSkslFbNe3tJhwrJ-PA=.86c81e1f-9a5b-4623-a90e-b8f06cafac23@github.com>
 <jv2OE1ILTzpy_kOelalptpSX-2oKCT0KcVU57Rfh9Sc=.abbce7ca-2221-459f-b61f-997fa9d6cc85@github.com>
Message-ID: <QmQcG6rOJZV6iwiUup1uZeoJ7j-bYdNCtWiyHTSlFrk=.19282326-0952-4219-a72f-ebabdb3f1bf4@github.com>

On Tue, 13 May 2025 09:59:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Thanks Daniel, I have commited the above change in wording to the get broadcast method and updated the CSR to reflect (JDK-8356002). I will await confirmation on the class level API documentation before updating.
>
> I think the original wording of the class level doc was phrased awkwardly. I'd like to suggest the following:
> 
>  * This class represents a Network Interface address. In the case of
>  * IPv4, this comprises the IP address, a subnet mask, and a broadcast 
>  * address if the interface supports broadcast. In the case of IPv6, 
>  * it comprises the IP address and a network prefix length.

Thanks Michael! I agree this would be much better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25095#discussion_r2086895781

From abarashev at openjdk.org  Tue May 13 14:03:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 14:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
Message-ID: <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>

On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).

@haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it's disabled system-wide.
Making this toggle SunX509-specific is a trivial change if we have a consensus on this.

@seanjmullan What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2876654496

From duke at openjdk.org  Tue May 13 15:08:08 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 13 May 2025 15:08:08 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v3]
In-Reply-To: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
Message-ID: <t4IDLrSSA7XzQ0hSGDoTRJXb9dE0PYwnA3kc1DNxnYI=.8b5e4be1-679b-44cb-a55f-34d7f1642afb@github.com>

> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  Update InterfaceAddress.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25095/files
  - new: https://git.openjdk.org/jdk/pull/25095/files/c3915e21..83beab73

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

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

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

From duke at openjdk.org  Tue May 13 15:20:53 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 13 May 2025 15:20:53 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v3]
In-Reply-To: <QmQcG6rOJZV6iwiUup1uZeoJ7j-bYdNCtWiyHTSlFrk=.19282326-0952-4219-a72f-ebabdb3f1bf4@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <bYt_as0G_ZZJGJ9YYuldMZZrIyDjw-Wah19gZCOunEI=.9bd38c12-de44-43c7-bba4-865507c8af67@github.com>
 <iVeJJvVgL3KKUcyNtcJLZVk5pSkslFbNe3tJhwrJ-PA=.86c81e1f-9a5b-4623-a90e-b8f06cafac23@github.com>
 <jv2OE1ILTzpy_kOelalptpSX-2oKCT0KcVU57Rfh9Sc=.abbce7ca-2221-459f-b61f-997fa9d6cc85@github.com>
 <QmQcG6rOJZV6iwiUup1uZeoJ7j-bYdNCtWiyHTSlFrk=.19282326-0952-4219-a72f-ebabdb3f1bf4@github.com>
Message-ID: <8UioKN0qlHIZ_lZna4pr2zodlIHBLiKdMG447gWGG_4=.04a9c2ac-2743-48ae-91a1-e95d709045b7@github.com>

On Tue, 13 May 2025 13:55:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think the original wording of the class level doc was phrased awkwardly. I'd like to suggest the following:
>> 
>>  * This class represents a Network Interface address. In the case of
>>  * IPv4, this comprises the IP address, a subnet mask, and a broadcast 
>>  * address if the interface supports broadcast. In the case of IPv6, 
>>  * it comprises the IP address and a network prefix length.
>
> Thanks Michael! I agree this would be much better.

Thanks both, the class level API documentation has been updated and CSR modified to reflect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25095#discussion_r2087084443

From dfuchs at openjdk.org  Tue May 13 16:02:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 May 2025 16:02:54 GMT
Subject: RFR: 8356395: Spec needs to be clarified for
 InterfaceAddress.getBroadcast() method [v3]
In-Reply-To: <t4IDLrSSA7XzQ0hSGDoTRJXb9dE0PYwnA3kc1DNxnYI=.8b5e4be1-679b-44cb-a55f-34d7f1642afb@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <t4IDLrSSA7XzQ0hSGDoTRJXb9dE0PYwnA3kc1DNxnYI=.8b5e4be1-679b-44cb-a55f-34d7f1642afb@github.com>
Message-ID: <H6VL7sbhh2E3y_WHEHcnz8h470d43WcwL9iQwEC4KIM=.c0e56f6c-e4c5-4177-be59-74213005f92d@github.com>

On Tue, 13 May 2025 15:08:08 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterfaceAddress.java

I like this new version.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25095#pullrequestreview-2837351449

From abarashev at openjdk.org  Tue May 13 17:15:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 17:15:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
Message-ID: <EZJlyGzxRtPXj7oQ9Nr9B11ZNYB3-eF8axeFzGaMyqo=.56a1127e-a0f9-40ee-bf67-9ad563c110c4@github.com>

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62:

> 60:  * produced.
> 61:  */
> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate {

What's the reason we don't use `SSLEngineTemplate` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2087293357

From josiahnoel at gmail.com  Tue May 13 17:17:06 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 13 May 2025 13:17:06 -0400
Subject: The default HttpServer Executor
Message-ID: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>

Hey Team,

Has there been any discussion about changing the default executor of the
JDK HTTP server implementation to use virtual threads?

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250513/5b2c8393/attachment.htm>

From wetmore at openjdk.org  Tue May 13 17:41:32 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 17:41:32 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <y_zck6XyZvQNLo7YrDxLu8PVlsi-ySSPe64A7VMOpys=.e2d5ceda-c5b9-41fc-ab4d-1acb4b083dc8@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into JDK-8341346
 - Missed one review comment
 - More codereview comments
 - Merge branch 'master' into JDK-8341346
 - Adjustments made for JDK-8350830
 - Merge branch 'master' into JDK-8341346
 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
 - More Codereview comments
 - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
 - Add in the SharedSecrets SecretKeySpec clearing mechanism
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=12
  Stats: 1102 lines in 9 files changed: 1082 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From daniel.fuchs at oracle.com  Tue May 13 18:28:26 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 13 May 2025 19:28:26 +0100
Subject: The default HttpServer Executor
In-Reply-To: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
References: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
Message-ID: <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>

Hi Josiah,

The HttpServer doesn't use any default
executor - it has one dispatcher thread and by default
serves requests serially from the dispatcher thread.
For backward compatibility I don't think we will ever
change that default behaviour.

An executor can however be supplied to the HttpServer
using `HttpServer.setExecutor` [1]

The HttpServer mostly uses monitors for synchronization.
With JEP 491 delivered [2], using Virtual Threads with
the HttpServer has become more friendly, and anyone wishing
to use VirtualThread with their HttpServer instance
can therefore pass a VirtualThreadPerTaskExecutor to
their instance.

Their might still be some side effect with using
virtual thread however, especially if invoking code
calling a native method that blocks, or loading a class
that blocks in its static initializers.

So using VirtualThread should be a conscious choice
from the application designers.

If you are speaking of `jwebserver` - then we deliberately
choose to not use any executor there, and I don't think we
would change that.

best regards,

-- daniel

[1] 
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#setExecutor(java.util.concurrent.Executor)
[1] https://openjdk.org/jeps/491

On 13/05/2025 18:17, Josiah Noel wrote:
> Hey Team,
> 
> Has there been any discussion about changing the default executor of the 
> JDK HTTP server implementation to use virtual threads?
> 


From josiahnoel at gmail.com  Tue May 13 19:24:57 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 13 May 2025 15:24:57 -0400
Subject: The default HttpServer Executor
In-Reply-To: <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>
References: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
 <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>
Message-ID: <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>

>
> The HttpServer doesn't use any default
> executor


I know what you mean by this, but I have to point out that the class used
is quite literally called DefaultExecutor
<https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#L200-L204>
.

For backward compatibility I don't think we will ever
> change that default behaviour.


Can you expand on this a little more? Is the backwards incompatibility that
it would be able to serve more than a single request at the same time?

An executor can however be supplied to the HttpServer
> using `HttpServer.setExecutor` [1]


After using this method for so long, I'm wondering if there is any reason
that we have to go through this ceremony to serve more than one request at
the same time. (Every time I've used it)

Their might still be some side effect with using
> virtual thread however, especially if invoking code
> calling a native method that blocks, or loading a class
> that blocks in its static initializers.


As you say, the default dispatcher currently runs serially, so if one does
any sort of blocking operation, the dispatcher thread is pinned and cannot
serve any more requests. If one were to switch to a virtual thread executor
and call native blocking methods, is there a difference in this scenario?
Either way, the server would be unable to serve requests while the thread
is pinned by the blocking operation.

On Tue, May 13, 2025 at 2:28?PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Josiah,
>
> The HttpServer doesn't use any default
> executor - it has one dispatcher thread and by default
> serves requests serially from the dispatcher thread.
> For backward compatibility I don't think we will ever
> change that default behaviour.
>
> An executor can however be supplied to the HttpServer
> using `HttpServer.setExecutor` [1]
>
> The HttpServer mostly uses monitors for synchronization.
> With JEP 491 delivered [2], using Virtual Threads with
> the HttpServer has become more friendly, and anyone wishing
> to use VirtualThread with their HttpServer instance
> can therefore pass a VirtualThreadPerTaskExecutor to
> their instance.
>
> Their might still be some side effect with using
> virtual thread however, especially if invoking code
> calling a native method that blocks, or loading a class
> that blocks in its static initializers.
>
> So using VirtualThread should be a conscious choice
> from the application designers.
>
> If you are speaking of `jwebserver` - then we deliberately
> choose to not use any executor there, and I don't think we
> would change that.
>
> best regards,
>
> -- daniel
>
> [1]
>
> https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#setExecutor(java.util.concurrent.Executor)
> [1] https://openjdk.org/jeps/491
>
> On 13/05/2025 18:17, Josiah Noel wrote:
> > Hey Team,
> >
> > Has there been any discussion about changing the default executor of the
> > JDK HTTP server implementation to use virtual threads?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250513/85c3c918/attachment.htm>

From ethan at mccue.dev  Tue May 13 19:42:31 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 13 May 2025 21:42:31 +0200
Subject: The default HttpServer Executor
In-Reply-To: <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>
References: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
 <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>
 <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>
Message-ID: <CA+NR86ihNmTJKWQW1OOMv5P5h88xBueN578Gux0AepwY2b_9OQ@mail.gmail.com>

I don't have any opinion besides best do nothing, but I will note that any
multi threaded executor will make apparent the existing bug/spec issue in
Filter that we talked about before.

On Tue, May 13, 2025, 9:27?PM Josiah Noel <josiahnoel at gmail.com> wrote:

> The HttpServer doesn't use any default
>> executor
>
>
> I know what you mean by this, but I have to point out that the class used
> is quite literally called DefaultExecutor
> <https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#L200-L204>
> .
>
> For backward compatibility I don't think we will ever
>> change that default behaviour.
>
>
> Can you expand on this a little more? Is the backwards incompatibility
> that it would be able to serve more than a single request at the same time?
>
> An executor can however be supplied to the HttpServer
>> using `HttpServer.setExecutor` [1]
>
>
> After using this method for so long, I'm wondering if there is any reason
> that we have to go through this ceremony to serve more than one request at
> the same time. (Every time I've used it)
>
> Their might still be some side effect with using
>> virtual thread however, especially if invoking code
>> calling a native method that blocks, or loading a class
>> that blocks in its static initializers.
>
>
> As you say, the default dispatcher currently runs serially, so if one does
> any sort of blocking operation, the dispatcher thread is pinned and cannot
> serve any more requests. If one were to switch to a virtual thread executor
> and call native blocking methods, is there a difference in this scenario?
> Either way, the server would be unable to serve requests while the thread
> is pinned by the blocking operation.
>
> On Tue, May 13, 2025 at 2:28?PM Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
>
>> Hi Josiah,
>>
>> The HttpServer doesn't use any default
>> executor - it has one dispatcher thread and by default
>> serves requests serially from the dispatcher thread.
>> For backward compatibility I don't think we will ever
>> change that default behaviour.
>>
>> An executor can however be supplied to the HttpServer
>> using `HttpServer.setExecutor` [1]
>>
>> The HttpServer mostly uses monitors for synchronization.
>> With JEP 491 delivered [2], using Virtual Threads with
>> the HttpServer has become more friendly, and anyone wishing
>> to use VirtualThread with their HttpServer instance
>> can therefore pass a VirtualThreadPerTaskExecutor to
>> their instance.
>>
>> Their might still be some side effect with using
>> virtual thread however, especially if invoking code
>> calling a native method that blocks, or loading a class
>> that blocks in its static initializers.
>>
>> So using VirtualThread should be a conscious choice
>> from the application designers.
>>
>> If you are speaking of `jwebserver` - then we deliberately
>> choose to not use any executor there, and I don't think we
>> would change that.
>>
>> best regards,
>>
>> -- daniel
>>
>> [1]
>>
>> https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#setExecutor(java.util.concurrent.Executor)
>> [1] https://openjdk.org/jeps/491
>>
>> On 13/05/2025 18:17, Josiah Noel wrote:
>> > Hey Team,
>> >
>> > Has there been any discussion about changing the default executor of
>> the
>> > JDK HTTP server implementation to use virtual threads?
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250513/ce286f68/attachment-0001.htm>

From abarashev at openjdk.org  Tue May 13 21:46:56 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 21:46:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: <y_zck6XyZvQNLo7YrDxLu8PVlsi-ySSPe64A7VMOpys=.e2d5ceda-c5b9-41fc-ab4d-1acb4b083dc8@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <y_zck6XyZvQNLo7YrDxLu8PVlsi-ySSPe64A7VMOpys=.e2d5ceda-c5b9-41fc-ab4d-1acb4b083dc8@github.com>
Message-ID: <bLopIDytd5OlqrzcdntxGf4Dc2Scp8B5xixikUQ0KcE=.9a532f0e-13d8-47cd-8578-0dc7a9afc35a@github.com>

On Tue, 13 May 2025 17:41:32 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Missed one review comment
>  - More codereview comments
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583:

> 1581:         // Calculations are primarily based on protocol version.
> 1582:         switch (protocolVersion) {
> 1583:         case TLS13:  // HKDF-based

Should we also handle `TLS13Plus` versions here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2087679309

From wetmore at openjdk.org  Wed May 14 00:31:13 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 14 May 2025 00:31:13 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v14]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <cWp1Q5czXrTGfPXNW4KqCocB99bJEj1qrC1_piyhiB4=.1f5f3730-f7e6-4884-8a15-3ed2db26f611@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge
 - Merge branch 'master' into JDK-8341346
 - Missed one review comment
 - More codereview comments
 - Merge branch 'master' into JDK-8341346
 - Adjustments made for JDK-8350830
 - Merge branch 'master' into JDK-8341346
 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
 - More Codereview comments
 - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
 - ... and 7 more: https://git.openjdk.org/jdk/compare/a96424b2...cc265d68

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=13
  Stats: 1094 lines in 8 files changed: 1080 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Wed May 14 04:03:44 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 14 May 2025 04:03:44 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Merged with changes for JDK-8353578

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/cc265d68..513c8032

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=13-14

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

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

From ihse at openjdk.org  Wed May 14 06:35:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:56 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
Message-ID: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>

On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>> 
>> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
>> 
>> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.
>
> src/demo/share/jfc/CodePointIM/README.html line 5:
> 
>> 3: <head>
>> 4:   <title>README - CodePointIM</title>
>> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">
> 
> I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088152886

From ihse at openjdk.org  Wed May 14 06:35:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:57 GMT
Subject: Integrated: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <1uf8Qu09x2byR-S1kMvt4zMdBu_BKZHCvx13v-uaxYc=.9e974fe5-0125-4001-99f6-acbba3ea517d@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

This pull request has now been integrated.

Changeset: dd251599
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd2515993bf76f424e4c56d529ae1541f55e3f8b
Stats:     794 lines in 53 files changed: 2 ins; 9 del; 783 mod

8356644: Update encoding declaration to UTF-8

Reviewed-by: prr, naoto

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

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

From serb at openjdk.org  Wed May 14 06:52:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 06:52:55 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
 <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
Message-ID: <IpJv8SIJ2TSeGf31v4EPP7vbfL9injugtQRKbLZy1MM=.3980df30-43fb-48a2-a48b-4cafcf7352fd@github.com>

On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

FIled: https://bugs.openjdk.org/browse/JDK-8356937

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088181402

From vyazici at openjdk.org  Wed May 14 09:31:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 14 May 2025 09:31:07 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v2]
In-Reply-To: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
Message-ID: <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>

> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
> 
> ### Demonstration
> 
> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
> 
> **Before:**
> 
> INFO: HEADERS: RESPONSE HEADERS:
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     :status: 304
>     content-length: 300
> 
> 
> **After:** 
> 
> INFO: HEADERS: RESPONSE HEADERS:
>   GET http://127.0.0.1:48497/ 101
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>   GET http://127.0.0.1:48497/ 304
>     :status: 304
>     content-length: 300

Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:

 - Match header logging in `Http1Request` with others
 - Shorten code
 - Improve header logging in more places

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25201/files
  - new: https://git.openjdk.org/jdk/pull/25201/files/dee90eba..be71467e

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

  Stats: 40 lines in 4 files changed: 8 ins; 12 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25201/head:pull/25201

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

From vyazici at openjdk.org  Wed May 14 09:38:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 14 May 2025 09:38:52 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers
In-Reply-To: <qWkPAN5If92yXgltmFs5qIUuMRxCyHhbNvYxv4KY-k8=.33a82898-f553-47b0-9b25-7428d2824da4@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <qWkPAN5If92yXgltmFs5qIUuMRxCyHhbNvYxv4KY-k8=.33a82898-f553-47b0-9b25-7428d2824da4@github.com>
Message-ID: <UQivatV7cQSoDff5XywPxHtHRK1BzZ4DqRT6dyGMruA=.b9ef32b7-b6e2-4a30-a00c-bf49d4d08e95@github.com>

On Tue, 13 May 2025 13:53:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Very nice!
> 
> It would be good to add the `(streamId=<streamId>)` at line 676 too in Stream.java (Trailing Headers),  and to add the whole line (`GET <uri> <status-code>`) at line 1782 (push response headers).

@dfuch, I've updated all usages of `Log::logHeaders`, see the updated BEFORE and AFTER snippets in the PR description. Two particular spots of importance:

1. Updated `Http1Request::logHeaders`
2. `HEADERS FRAME` logs don't contain the response code for those are outgoing

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

PR Comment: https://git.openjdk.org/jdk/pull/25201#issuecomment-2879508082

From dfuchs at openjdk.org  Wed May 14 10:57:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 May 2025 10:57:55 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v2]
In-Reply-To: <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>
Message-ID: <jxNupee-2e3SUvupU4M9zFBxdP-GB7mpxBCnitivWYE=.f8d3a1cb-0fd6-478f-865f-af8c0892f80e@github.com>

On Wed, 14 May 2025 09:31:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Match header logging in `Http1Request` with others
>  - Shorten code
>  - Improve header logging in more places

Some suggested changes. I'd rather not localize streamId and status code - so I'd prefer we use %s.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 93:

> 91:                     int protocolFieldPrefixIndex = line.lastIndexOf(' ');
> 92:                     assert protocolFieldPrefixIndex > 0;
> 93:                     sb.append("  ").append(line, 0, protocolFieldPrefixIndex).append('\n');

I'd rather print the whole line here - including HTTP/1.1.
Nice to have it indented differently though.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 227:

> 225:                 if (Log.headers()) {
> 226:                     StringBuilder sb = new StringBuilder("RESPONSE HEADERS:\n");
> 227:                     sb.append("  %s %s %d\n".formatted(request.method(), request.uri(), responseCode));

Suggestion:

                    sb.append("  %s %s %s\n".formatted(request.method(), request.uri(), responseCode));

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 1688:

> 1686:         oh.streamid(stream.streamid);
> 1687:         if (Log.headers()) {
> 1688:             StringBuilder sb = new StringBuilder("HEADERS FRAME (streamid=%d):\n".formatted(stream.streamid));

Suggestion:

            StringBuilder sb = new StringBuilder("HEADERS FRAME (streamid=%s):\n".formatted(stream.streamid));

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 666:

> 664:             if (Log.headers()) {
> 665:                 StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%d):\n".formatted(streamid));
> 666:                 sb.append("  %s %s %d\n".formatted(request.method(), request.uri(), responseCode));

Suggestion:

                sb.append("  %s %s %s\n".formatted(request.method(), request.uri(), responseCode));

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 677:

> 675:         } else {
> 676:             if (Log.headers()) {
> 677:                 StringBuilder sb = new StringBuilder("TRAILING HEADERS (streamid=%d):\n".formatted(streamid));

Suggestion:

                StringBuilder sb = new StringBuilder("TRAILING HEADERS (streamid=%s):\n".formatted(streamid));

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 678:

> 676:             if (Log.headers()) {
> 677:                 StringBuilder sb = new StringBuilder("TRAILING HEADERS (streamid=%d):\n".formatted(streamid));
> 678:                 sb.append("  %s %s %d\n".formatted(request.method(), request.uri(), responseCode));

These are trailing headers - printing URI and response code would be confusing here. Only printing streamId should be fine.

Suggestion:

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1775:

> 1773: 
> 1774:                 if (Log.headers()) {
> 1775:                     StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%d):\n".formatted(streamid));

Suggestion:

                    StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%s):\n".formatted(streamid));

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1776:

> 1774:                 if (Log.headers()) {
> 1775:                     StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%d):\n".formatted(streamid));
> 1776:                     sb.append("  %s %s %d\n".formatted(request.method(), request.uri(), responseCode));

Suggestion:

                    sb.append("  %s %s %s\n".formatted(request.method(), request.uri(), responseCode));

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1788:

> 1786:                 if (Log.headers()) {
> 1787:                     StringBuilder sb = new StringBuilder("TRAILING HEADERS (streamid=%d):\n".formatted(streamid));
> 1788:                     sb.append("  %s %s %d\n".formatted(request.method(), request.uri(), responseCode));

Suggestion:

                    StringBuilder sb = new StringBuilder("TRAILING HEADERS (streamid=%s):\n".formatted(streamid));
                    sb.append("  %s %s %s\n".formatted(request.method(), request.uri(), responseCode));

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

PR Review: https://git.openjdk.org/jdk/pull/25201#pullrequestreview-2839695414
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088643521
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088654005
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088653338
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088652653
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088651795
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088648853
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088650531
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088657325
PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2088658535

From daniel.fuchs at oracle.com  Wed May 14 11:24:39 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 14 May 2025 12:24:39 +0100
Subject: [External] : Re: The default HttpServer Executor
In-Reply-To: <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>
References: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
 <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>
 <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>
Message-ID: <da936634-c8f6-4505-bc7c-26c0ac3d54ad@oracle.com>

Hi Josiah,

On 13/05/2025 20:24, Josiah Noel wrote:
>     The HttpServer doesn't use any default
>     executor
> 
> 
> I know what you mean by this, but I have to point out that the?class 
> used is quite literally called DefaultExecutor 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java*L200-L204__;Iw!!ACWV5N9M2RV99hQ!JIfxp_rcxH9VkMOYILi4aLebtIM5Y9gOIT0jc3AgmPwkxmgz5lo2R7v9Q71TuUH5pHVtxuVS0pg5RjTkITf00A$>.> 
>     For backward compatibility I don't think we will ever
>     change that default behaviour.

Oh - right - I see what you meant too then.

> Can you expand on this a little more? Is the backwards incompatibility 
> that it would be able to serve more than a single request at the same time?

Yes. An application (handler's implementations) may depend on that.

>     An executor can however be supplied to the HttpServer
>     using `HttpServer.setExecutor` [1]
> 
> 
> After using this method for so long, I'm wondering if there is any 
> reason that we have to go through this ceremony to serve more than one 
> request at the same time. (Every time I've used it)

Probably to give control to the application over what kind
of executor it wants to use. There are many parameters there,
like should the threads be daemon? What should be the
Thread Context ClassLoader? What should be the thread names?
Should it be a pool executor, if so what should be the size
of the pool? No default choice would suit everybody.

Using a VirtualThreadPerTaskExecutor would eliminate most of
these questions, but virtual threads were not there when
the API was designed. IMO having a single thread was not an
unreasonable default, when there was an API to override
that and let the application provide the executor of its choice.


>     Their might still be some side effect with using
>     virtual thread however, especially if invoking code
>     calling a native method that blocks, or loading a class
>     that blocks in its static initializers.
> 
> 
> As you say, the default dispatcher?currently?runs serially, so if one 
> does any sort of blocking operation, the dispatcher thread is pinned and 
> cannot serve any more requests. If one were to switch to a virtual 
> thread executor and call native blocking methods, is there a difference 
> in this scenario? Either way, the server would be unable to serve 
> requests while the thread is pinned by the blocking operation.

Blocking does not mean deadlocking, but if virtual threads get
pinned it can lead to carrier thread starvation: the code that
would "unblock" everything might never get executed because all
carrier threads are pinned.

best regards,

-- daniel



From josiahnoel at gmail.com  Wed May 14 14:34:11 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Wed, 14 May 2025 10:34:11 -0400
Subject: [External] : Re: The default HttpServer Executor
In-Reply-To: <da936634-c8f6-4505-bc7c-26c0ac3d54ad@oracle.com>
References: <CAJ_t5UaJMdz_3MEJG-FTPXQyYt1_TN0Cn6MDkpCYrMXR4KT0ww@mail.gmail.com>
 <236e12a5-24d2-41ba-9337-9c913774add4@oracle.com>
 <CAJ_t5UahGdG=1BgRUoqS+DPQry9hixc5Z5ucAyzVjK-yZYvi2Q@mail.gmail.com>
 <da936634-c8f6-4505-bc7c-26c0ac3d54ad@oracle.com>
Message-ID: <CAJ_t5UbO8BW9mFY-P6hOCMUJyKOUNM=a6ezhe5fH39qqr51HkA@mail.gmail.com>

>
> Yes. An application (handler's implementations) may depend on that.


 Aside from that filter bug Ethan mentioned, have you seen such cases? I
usually see people take it as a given that the default impl can serve
multiple requests and have to tell them to use an executor. If we decide
against changing the executor, perhaps we should update the Javadoc to
better clarify that the default serves requests serially.


> Using a VirtualThreadPerTaskExecutor would eliminate most of
> these questions, but virtual threads were not there when
> the API was designed


True enough, but they're here now, so it's a golden opportunity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250514/d5c43a17/attachment-0001.htm>

From abarashev at openjdk.org  Wed May 14 18:16:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 14 May 2025 18:16:13 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

  Make the test run on TLSv1.3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/5c137c14..451e1efd

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

  Stats: 25 lines in 2 files changed: 5 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From djelinski at openjdk.org  Wed May 14 19:19:54 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 14 May 2025 19:19:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
Message-ID: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com>

On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merged with changes for JDK-8353578

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329:

> 327:      */
> 328: 
> 329:     SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException {

this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089580932

From abarashev at openjdk.org  Wed May 14 20:15:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 14 May 2025 20:15:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
Message-ID: <ueZBBE4cxYGP8tvFZolaUQhRpn3ATQCaXdqsHutNW1Y=.6b02bc41-378d-4196-853a-ec0c8092b2ed@github.com>

On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merged with changes for JDK-8353578

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1727:

> 1725: 
> 1726:             // context length must fit in 2 unsigned bytes.
> 1727:             if ((context != null) && context.length >= 65536) {

Nit: `context.length > 0xFFFF` would be more readable IMO

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089670919

From wetmore at openjdk.org  Wed May 14 21:44:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 14 May 2025 21:44:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com>
Message-ID: <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com>

On Wed, 14 May 2025 19:17:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merged with changes for JDK-8353578
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329:
> 
>> 327:      */
>> 328: 
>> 329:     SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException {
> 
> this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket?

Good catch, I am 99% convinced neither is not needed.  I'll be removing these changes.   

For TLS 1.3, the exporter is recalculated at the end of the handshake for the new session.

For 1-1.2, the Session is indeed pulled from the serialized form, but the new session's Hello Random values are used with the existing MasterSecret to load the `TlsKeyMaterialParameterSpec` and obtain all of the keying material.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089796579

From wetmore at openjdk.org  Wed May 14 23:57:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 14 May 2025 23:57:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <AfDAoZuNDojI7yoSF3YLac17j7sM8DHWX7P0bZSJbDo=.0d01d5c9-bdc6-41e3-b6ac-5cbabb038c1e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <AfDAoZuNDojI7yoSF3YLac17j7sM8DHWX7P0bZSJbDo=.0d01d5c9-bdc6-41e3-b6ac-5cbabb038c1e@github.com>
Message-ID: <TeMyOKmEwtJ2sZuNci_I0DjhR-trJlk2JIkXLaq2E2E=.e44e529f-75fd-4562-abd2-8017b1366bd4@github.com>

On Tue, 13 May 2025 12:16:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one review comment
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 189:
> 
>> 187:      *           {@code UnsupportedOperationException}.
>> 188:      *           Classes derived from ExtendedSSLSession must implement
>> 189:      *           this method.
> 
> That statement is too strong, even though `getStatusResponses` has that text, unfortunately. For one, existing provider implementations of this class are binary compatible if they upgrade to JDK 25 because they don't have to implement this method right away since it has a default implementation.

Ok, removed in both places

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089918402

From wetmore at openjdk.org  Thu May 15 00:00:58 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 00:00:58 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com>
 <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com>
Message-ID: <QqiqWSaRuUzaS7yrRIU9qf4sQaF5W86WaKbBMQynsDg=.43a69c87-6679-4210-b312-25a5fc394eee@github.com>

On Wed, 14 May 2025 21:42:06 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329:
>> 
>>> 327:      */
>>> 328: 
>>> 329:     SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException {
>> 
>> this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket?
>
> Good catch, I am 99% convinced neither is not needed.  I'll be removing these changes.   
> 
> For TLS 1.3, the exporter is recalculated at the end of the handshake for the new session.
> 
> For 1-1.2, the Session is indeed pulled from the serialized form, but the new session's Hello Random values are used with the existing MasterSecret to load the `TlsKeyMaterialParameterSpec` and obtain all of the keying material.

Update, will push soon.

Had to move the random capture locations, as they need to capture the new client/server randoms instead of when the PMS is calculated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089922075

From wetmore at openjdk.org  Thu May 15 00:29:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 00:29:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: <bLopIDytd5OlqrzcdntxGf4Dc2Scp8B5xixikUQ0KcE=.9a532f0e-13d8-47cd-8578-0dc7a9afc35a@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <y_zck6XyZvQNLo7YrDxLu8PVlsi-ySSPe64A7VMOpys=.e2d5ceda-c5b9-41fc-ab4d-1acb4b083dc8@github.com>
 <bLopIDytd5OlqrzcdntxGf4Dc2Scp8B5xixikUQ0KcE=.9a532f0e-13d8-47cd-8578-0dc7a9afc35a@github.com>
Message-ID: <G74_vsutco0aa_H-e1IjtLnjcp50PKjPOj8tZW1tod4=.0d6c7527-9fad-42c4-8733-77823943b516@github.com>

On Tue, 13 May 2025 21:44:21 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Missed one review comment
>>  - More codereview comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583:
> 
>> 1581:         // Calculations are primarily based on protocol version.
>> 1582:         switch (protocolVersion) {
>> 1583:         case TLS13:  // HKDF-based
> 
> Should we also handle `TLS13Plus` versions here?

I like the enumeration as it's possible there could be new behavior with TLS14Plus, but this might save a few minutes down the road, so I've changed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089938492

From wetmore at openjdk.org  Thu May 15 00:29:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 00:29:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>
Message-ID: <Qq9c1UL9tXq0p9XC3FVB2QCLGDPlQWru05nBFNmaBbY=.bd4a2342-2010-401c-ad67-e97ed69430a3@github.com>

On Tue, 13 May 2025 13:23:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one review comment
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1598:
> 
>> 1596:             //     L    length of output keying material in octets
>> 1597:             //          (<= 255*HashLen)
>> 1598:             if (length >= (255 * cipherSuite.hashAlg.hashLength )) {
> 
> The opposite of `<=` is `>`.

Good catch.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089940408

From wetmore at openjdk.org  Thu May 15 00:29:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 00:29:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <ueZBBE4cxYGP8tvFZolaUQhRpn3ATQCaXdqsHutNW1Y=.6b02bc41-378d-4196-853a-ec0c8092b2ed@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <ueZBBE4cxYGP8tvFZolaUQhRpn3ATQCaXdqsHutNW1Y=.6b02bc41-378d-4196-853a-ec0c8092b2ed@github.com>
Message-ID: <aa4jBmzJ-MEuiNqkUrkfczpfz8WLP50bYDy2kO8PIfw=.2078d1d0-8194-43f1-9420-1b044044b1fd@github.com>

On Wed, 14 May 2025 20:13:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merged with changes for JDK-8353578
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1727:
> 
>> 1725: 
>> 1726:             // context length must fit in 2 unsigned bytes.
>> 1727:             if ((context != null) && context.length >= 65536) {
> 
> Nit: `context.length > 0xFFFF` would be more readable IMO

Sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089941085

From abarashev at openjdk.org  Thu May 15 00:40:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 May 2025 00:40:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: <G74_vsutco0aa_H-e1IjtLnjcp50PKjPOj8tZW1tod4=.0d6c7527-9fad-42c4-8733-77823943b516@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <y_zck6XyZvQNLo7YrDxLu8PVlsi-ySSPe64A7VMOpys=.e2d5ceda-c5b9-41fc-ab4d-1acb4b083dc8@github.com>
 <bLopIDytd5OlqrzcdntxGf4Dc2Scp8B5xixikUQ0KcE=.9a532f0e-13d8-47cd-8578-0dc7a9afc35a@github.com>
 <G74_vsutco0aa_H-e1IjtLnjcp50PKjPOj8tZW1tod4=.0d6c7527-9fad-42c4-8733-77823943b516@github.com>
Message-ID: <E0VWwrcX3J2LIzj92uNwTx_JI-fK7TL37upXaUnr6dU=.e9a3cbd7-85d4-487c-b207-1f48dd97107c@github.com>

On Thu, 15 May 2025 00:23:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583:
>> 
>>> 1581:         // Calculations are primarily based on protocol version.
>>> 1582:         switch (protocolVersion) {
>>> 1583:         case TLS13:  // HKDF-based
>> 
>> Should we also handle `TLS13Plus` versions here?
>
> I like the enumeration as it's possible there could be new behavior with TLS14Plus, but this might save a few minutes down the road, so I've changed it.

Yes, the general approach in SSL code is to use `if (protocolVersion.useTLS13PlusSpec()) {} else {}`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089949997

From wetmore at openjdk.org  Thu May 15 02:03:02 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 02:03:02 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <EZJlyGzxRtPXj7oQ9Nr9B11ZNYB3-eF8axeFzGaMyqo=.56a1127e-a0f9-40ee-bf67-9ad563c110c4@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <EZJlyGzxRtPXj7oQ9Nr9B11ZNYB3-eF8axeFzGaMyqo=.56a1127e-a0f9-40ee-bf67-9ad563c110c4@github.com>
Message-ID: <WO9Lnaxb2x1UKoEYtXoAQbUeApLGJ0frwolf1zPC9zM=.9ac051d3-d00b-4933-a557-2a2b0dd45f98@github.com>

On Tue, 13 May 2025 17:13:03 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one review comment
>
> test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62:
> 
>> 60:  * produced.
>> 61:  */
>> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate {
> 
> What's the reason we don't use `SSLEngineTemplate` here?

There's a bug in `SSLEngine`/`SSLSocket` that prevents configuration callbacks from working as originally imagined.  I hate working around it.

The subclass constructor now calls `super()`, which then calls back to the `configure*()` methods, but you can't pass any parameters.  One of these days this should be fixed.  

I find it easier to just copy `SSLEngineTemplate.java` instead of `extends`.  

I've worked around it to remind myself this needs to be fixed someday.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090057949

From wetmore at openjdk.org  Thu May 15 04:24:52 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 04:24:52 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>
Message-ID: <bltBG-g0UHiKV5skHthbljRG6qB1Mw3-udKUONQp7mo=.0dad720a-1548-466f-ab3d-9241780056bd@github.com>

On Tue, 13 May 2025 13:25:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one review comment
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650:
> 
>> 1648:                     emptyHash = md.digest();
>> 1649:                 } catch (NoSuchAlgorithmException nsae) {
>> 1650:                     throw new RuntimeException(
> 
> We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm.

I can do a `ProviderException` if you like, but our JSSE code is all over the place.  Sometimes it's a `RuntimeException`, other times we wrap it into into a `SSLException`, and sometimes we directly do a `fatal()`.  I'd say we do `RuntimeException` a little more often than `ProviderException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090205280

From wetmore at openjdk.org  Thu May 15 04:28:52 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 04:28:52 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
Message-ID: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>

On Tue, 13 May 2025 13:37:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed one review comment
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682:
> 
>> 1680:                     // ...now the final expand.
>> 1681:                     return (deriveKey ?
>> 1682:                             hkdf.deriveKey("TlsExporterKeyingMaterial",
> 
> Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM?

>From a previous comment:

IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090208168

From duke at openjdk.org  Thu May 15 05:19:28 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 15 May 2025 05:19:28 GMT
Subject: RFR: 8357013: Optimize response code parsing in HttpURLConnection
Message-ID: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>

Avoid allocating a substring to parse the response code in HttpURLConnection#getResponseCode, but instead use the Integer.parseInt overload that accepts String indices.

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

Commit messages:
 - Optimize response code parsing in HttpURLConnection

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

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

From duke at openjdk.org  Thu May 15 07:19:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 07:19:52 GMT
Subject: RFR: 8356395: Spec needs to be clarified for InterfaceAddress
 class level API documentation and getBroadcast() method [v3]
In-Reply-To: <t4IDLrSSA7XzQ0hSGDoTRJXb9dE0PYwnA3kc1DNxnYI=.8b5e4be1-679b-44cb-a55f-34d7f1642afb@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
 <t4IDLrSSA7XzQ0hSGDoTRJXb9dE0PYwnA3kc1DNxnYI=.8b5e4be1-679b-44cb-a55f-34d7f1642afb@github.com>
Message-ID: <gKrqcbaxWBgfeM8DBPv5Ddl5_MAzGgbjU4ghWf24krA=.f8e2e070-a211-4ae5-a960-5985d92493e1@github.com>

On Tue, 13 May 2025 15:08:08 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterfaceAddress.java

@kieran-farrell 
Your change (at version 83beab731c8341b4f79a08dd01921159fc66c233) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25095#issuecomment-2882812317

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

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

From vyazici at openjdk.org  Thu May 15 11:29:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 11:29:33 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
Message-ID: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>

> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
> 
> ### Demonstration
> 
> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
> 
> **Before:**
> 
> INFO: HEADERS: REQUEST HEADERS:
> HEAD /transfer/ HTTP/1.1
> Content-Length: 0
> Host: 127.0.0.1:43647
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     :status: 304
>     content-length: 300
> ...
> INFO: HEADERS: HEADERS FRAME (streamid=1):
>     :authority: 127.0.0.1:50611
>     :method: GET
>     :path: /
> 
> 
> **After:** 
> 
> INFO: HEADERS: REQUEST HEADERS:
>   HEAD /transfer/ HTTP/1.1
>     Content-Length: 0
>     Host: 127.0.0.1:43647
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>   GET http://127.0.0.1:48497/ 101
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>   GET http://127.0.0.1:48497/ 304
>     :status: 304
>     content-length: 300
> ...
> INFO: HEADERS: HEADERS FRAME (streamid=1):
>   GET https://127.0.0.1:50611/
>     :authority: 127.0.0.1:50611
>     :method: GET
>     :path: /

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

 - Avoid localization
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25201/files
  - new: https://git.openjdk.org/jdk/pull/25201/files/be71467e..d0e36872

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

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

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

From vyazici at openjdk.org  Thu May 15 11:29:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 11:29:34 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers
In-Reply-To: <qWkPAN5If92yXgltmFs5qIUuMRxCyHhbNvYxv4KY-k8=.33a82898-f553-47b0-9b25-7428d2824da4@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <qWkPAN5If92yXgltmFs5qIUuMRxCyHhbNvYxv4KY-k8=.33a82898-f553-47b0-9b25-7428d2824da4@github.com>
Message-ID: <tlzr6PzBQGd5D0c1108ZWVENAeQoo5OpdWdmAVEh6kw=.e325de20-e055-4360-8b8f-a2f04082fd54@github.com>

On Tue, 13 May 2025 13:53:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Very nice!
> 
> It would be good to add the `(streamId=<streamId>)` at line 676 too in Stream.java (Trailing Headers),  and to add the whole line (`GET <uri> <status-code>`) at line 1782 (push response headers).

@dfuch, thanks for the `%d`-vs-`%s` tip, agreed with your rationale. ?

Applied requested changes and updated the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/25201#issuecomment-2883481775

From vyazici at openjdk.org  Thu May 15 11:29:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 11:29:34 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v2]
In-Reply-To: <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>
Message-ID: <CtU7ScVz9W4QOylew9VNEgC7oNZqSTbu-CiWFqOn6vY=.5d99647d-4193-4d8c-ab6c-44461b47c70c@github.com>

On Wed, 14 May 2025 09:31:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Match header logging in `Http1Request` with others
>  - Shorten code
>  - Improve header logging in more places

src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 93:

> 91:                     int protocolFieldPrefixIndex = line.lastIndexOf(' ');
> 92:                     assert protocolFieldPrefixIndex > 0;
> 93:                     sb.append("  ").append(line, 0, protocolFieldPrefixIndex).append('\n');

Suggestion:

                    sb.append("  ").append(line).append('\n');

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2090941543

From vyazici at openjdk.org  Thu May 15 11:29:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 11:29:34 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v2]
In-Reply-To: <jxNupee-2e3SUvupU4M9zFBxdP-GB7mpxBCnitivWYE=.f8d3a1cb-0fd6-478f-865f-af8c0892f80e@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <OhKM-jeO1oK9nEjxVT7QQUOkz81y92s1G8d3peJcbs8=.fd64adc1-93e8-4439-8349-2d0643a85598@github.com>
 <jxNupee-2e3SUvupU4M9zFBxdP-GB7mpxBCnitivWYE=.f8d3a1cb-0fd6-478f-865f-af8c0892f80e@github.com>
Message-ID: <yLoT9FzKuPNZsB2EVV5USqyGmePYVGr3r0Ba7eV0ABc=.0ba57322-3a80-4c41-a694-36e507895c17@github.com>

On Wed, 14 May 2025 10:44:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Match header logging in `Http1Request` with others
>>  - Shorten code
>>  - Improve header logging in more places
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 93:
> 
>> 91:                     int protocolFieldPrefixIndex = line.lastIndexOf(' ');
>> 92:                     assert protocolFieldPrefixIndex > 0;
>> 93:                     sb.append("  ").append(line, 0, protocolFieldPrefixIndex).append('\n');
> 
> I'd rather print the whole line here - including HTTP/1.1.
> Nice to have it indented differently though.

Implemented in 7b958db6f4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2090943446

From vyazici at openjdk.org  Thu May 15 11:29:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 11:29:34 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
Message-ID: <1pKcLca75_pgAtHZfA4cKyBqRkzTyagvg29DhJp0Yis=.ad402a86-bf56-4082-a49c-a32bbcf00e78@github.com>

On Thu, 15 May 2025 11:26:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Avoid localization
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 665:

> 663: 
> 664:             if (Log.headers()) {
> 665:                 StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%d):\n".formatted(streamid));

Suggestion:

                StringBuilder sb = new StringBuilder("RESPONSE HEADERS (streamid=%s):\n".formatted(streamid));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25201#discussion_r2090945160

From dfuchs at openjdk.org  Thu May 15 11:42:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 May 2025 11:42:00 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
Message-ID: <xs4Y0OXn8KoF54wb5m2v5WPEm86Uoac2QWemy8k8rLM=.81bc3884-1a8f-4d03-8c91-1946f1146737@github.com>

On Thu, 15 May 2025 11:29:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Avoid localization
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25201#pullrequestreview-2843372058

From dfuchs at openjdk.org  Thu May 15 11:49:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 May 2025 11:49:52 GMT
Subject: RFR: 8357013: Optimize response code parsing in HttpURLConnection
In-Reply-To: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
Message-ID: <H1GhzGIRe-bi14VOiJkoGoskKcFnhKA11PyRJY_sPYs=.87a02580-4714-45d9-a6a0-bddd876231d0@github.com>

On Thu, 15 May 2025 05:14:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid allocating a substring to parse the response code in HttpURLConnection#getResponseCode, but instead use the Integer.parseInt overload that accepts String indices.

Thanks for this fix. The proposed changes LGTM. Did you run tier2 tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/25245#issuecomment-2883535188

From abarashev at openjdk.org  Thu May 15 12:53:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 May 2025 12:53:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <aa4jBmzJ-MEuiNqkUrkfczpfz8WLP50bYDy2kO8PIfw=.2078d1d0-8194-43f1-9420-1b044044b1fd@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <ueZBBE4cxYGP8tvFZolaUQhRpn3ATQCaXdqsHutNW1Y=.6b02bc41-378d-4196-853a-ec0c8092b2ed@github.com>
 <aa4jBmzJ-MEuiNqkUrkfczpfz8WLP50bYDy2kO8PIfw=.2078d1d0-8194-43f1-9420-1b044044b1fd@github.com>
Message-ID: <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com>

On Thu, 15 May 2025 00:27:31 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1727:
>> 
>>> 1725: 
>>> 1726:             // context length must fit in 2 unsigned bytes.
>>> 1727:             if ((context != null) && context.length >= 65536) {
>> 
>> Nit: `context.length > 0xFFFF` would be more readable IMO
>
> Sure.

Also, the parentheses are not needed around `context != null`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091102162

From duke at openjdk.org  Thu May 15 13:47:23 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 15 May 2025 13:47:23 GMT
Subject: RFR: 8351843: change
 test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a
 manual test [v2]
In-Reply-To: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
References: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
Message-ID: <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>

> 8351843: change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

serhiysachkov 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:

 - 8351843: separating windows test and moving it to manual group
 - Merge branch 'master' into JDK-8351843
 - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24113/files
  - new: https://git.openjdk.org/jdk/pull/24113/files/7e1d5842..4f2f7a38

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

  Stats: 419768 lines in 5806 files changed: 144010 ins; 250743 del; 25015 mod
  Patch: https://git.openjdk.org/jdk/pull/24113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24113/head:pull/24113

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

From michaelm at openjdk.org  Thu May 15 13:48:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 15 May 2025 13:48:56 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
Message-ID: <CF-uARvoXHo5H2KfjfruD2ZkCzGmLxZzWa7qkVDMubw=.7ca042ec-2ab8-42cf-bd55-ab1f4e373b25@github.com>

On Thu, 15 May 2025 11:29:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Avoid localization
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Nice work

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25201#pullrequestreview-2843763371

From vyazici at openjdk.org  Thu May 15 14:03:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 14:03:58 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
Message-ID: <zUiCvHccXDfpJ9kn1w-4EK4hKfMbu8FWdZySF3wVvyA=.81f3a27d-fc81-4fa7-a9ab-cfb5f4cd989f@github.com>

On Thu, 15 May 2025 11:29:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Avoid localization
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Successful `tier1,2` results are attached to the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/25201#issuecomment-2883926274

From duke at openjdk.org  Thu May 15 14:03:59 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 14:03:59 GMT
Subject: RFR: 8351347: HttpClient Improve logging of response headers [v3]
In-Reply-To: <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
 <cHUiBmTnbjA2n1dWKlA6PcRpONszsKv8CcJweHfckz8=.45789c30-b02e-4424-a5f2-49197e8a85e9@github.com>
Message-ID: <vj9DY0G-X9sKGMgUKpJfjyF8ZS2EU9r8qodNWxBfKUg=.1a497422-ac40-4ba9-877e-6b7385b93f46@github.com>

On Thu, 15 May 2025 11:29:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
>> 
>> ### Demonstration
>> 
>> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
>> 
>> **Before:**
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>> HEAD /transfer/ HTTP/1.1
>> Content-Length: 0
>> Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>> 
>> 
>> **After:** 
>> 
>> INFO: HEADERS: REQUEST HEADERS:
>>   HEAD /transfer/ HTTP/1.1
>>     Content-Length: 0
>>     Host: 127.0.0.1:43647
>> ...
>> INFO: HEADERS: RESPONSE HEADERS:
>>   GET http://127.0.0.1:48497/ 101
>>     connection: Upgrade
>>     upgrade: h2c
>> ...
>> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>>   GET http://127.0.0.1:48497/ 304
>>     :status: 304
>>     content-length: 300
>> ...
>> INFO: HEADERS: HEADERS FRAME (streamid=1):
>>   GET https://127.0.0.1:50611/
>>     :authority: 127.0.0.1:50611
>>     :method: GET
>>     :path: /
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Avoid localization
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

@vy 
Your change (at version d0e36872cc4e16582dbb73910996a280985b04ba) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25201#issuecomment-2883927904

From dfuchs at openjdk.org  Thu May 15 14:10:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 May 2025 14:10:01 GMT
Subject: RFR: 8351843: change
 test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a
 manual test [v2]
In-Reply-To: <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
References: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
 <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
Message-ID: <6UNi4EKn9t-ei9llg5GRtu2qYdj-bKxEw7bTKPdLqrg=.43310e81-06bc-4fe0-80fe-38a9e31e5362@github.com>

On Thu, 15 May 2025 13:47:23 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test
>
> serhiysachkov 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:
> 
>  - 8351843: separating windows test and moving it to manual group
>  - Merge branch 'master' into JDK-8351843
>  - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

Looks reasonable. Please run tier1 and tier2 before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24113#pullrequestreview-2843841328

From vyazici at openjdk.org  Thu May 15 14:13:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 14:13:04 GMT
Subject: Integrated: 8351347: HttpClient Improve logging of response headers
In-Reply-To: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
References: <cx0d3miXd4Q59S05zAs69rI8SDPCRrHy1HsOrD84To4=.ea874bd2-6c9e-419d-a4b6-c091f2fd468f@github.com>
Message-ID: <XqQG7gaXS8kmyqOC29dcuIyQOL5DcZg-odXiXnE02tA=.8de17ac1-2b1b-4bb8-9f86-4f0a21ff0614@github.com>

On Tue, 13 May 2025 08:15:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client.
> 
> ### Demonstration
> 
> Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`:
> 
> **Before:**
> 
> INFO: HEADERS: REQUEST HEADERS:
> HEAD /transfer/ HTTP/1.1
> Content-Length: 0
> Host: 127.0.0.1:43647
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>     :status: 304
>     content-length: 300
> ...
> INFO: HEADERS: HEADERS FRAME (streamid=1):
>     :authority: 127.0.0.1:50611
>     :method: GET
>     :path: /
> 
> 
> **After:** 
> 
> INFO: HEADERS: REQUEST HEADERS:
>   HEAD /transfer/ HTTP/1.1
>     Content-Length: 0
>     Host: 127.0.0.1:43647
> ...
> INFO: HEADERS: RESPONSE HEADERS:
>   GET http://127.0.0.1:48497/ 101
>     connection: Upgrade
>     upgrade: h2c
> ...
> INFO: HEADERS: RESPONSE HEADERS (streamid=1):
>   GET http://127.0.0.1:48497/ 304
>     :status: 304
>     content-length: 300
> ...
> INFO: HEADERS: HEADERS FRAME (streamid=1):
>   GET https://127.0.0.1:50611/
>     :authority: 127.0.0.1:50611
>     :method: GET
>     :path: /

This pull request has now been integrated.

Changeset: 81e8e670
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81e8e670cec4e09502965110a77982f7d2f85ad9
Stats:     24 lines in 4 files changed: 7 ins; 0 del; 17 mod

8351347: HttpClient Improve logging of response headers

Reviewed-by: dfuchs, michaelm

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

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

From wetmore at openjdk.org  Thu May 15 16:56:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 15 May 2025 16:56:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <ueZBBE4cxYGP8tvFZolaUQhRpn3ATQCaXdqsHutNW1Y=.6b02bc41-378d-4196-853a-ec0c8092b2ed@github.com>
 <aa4jBmzJ-MEuiNqkUrkfczpfz8WLP50bYDy2kO8PIfw=.2078d1d0-8194-43f1-9420-1b044044b1fd@github.com>
 <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com>
Message-ID: <OmiZUX4o_Y4FDIAaZhg49XwbyAuUVDbZA6TWJ5depBM=.dc41687b-f957-4a84-a60d-cf2a2f825716@github.com>

On Thu, 15 May 2025 12:51:16 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Sure.
>
> Also, the parentheses are not needed around `context != null`

If there's one things to know about me, it's my liberal use of parens.  I want my code to match my intent.

I plan to update the "missing" parens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091610748

From abarashev at openjdk.org  Thu May 15 17:33:56 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 15 May 2025 17:33:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <WO9Lnaxb2x1UKoEYtXoAQbUeApLGJ0frwolf1zPC9zM=.9ac051d3-d00b-4933-a557-2a2b0dd45f98@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <EZJlyGzxRtPXj7oQ9Nr9B11ZNYB3-eF8axeFzGaMyqo=.56a1127e-a0f9-40ee-bf67-9ad563c110c4@github.com>
 <WO9Lnaxb2x1UKoEYtXoAQbUeApLGJ0frwolf1zPC9zM=.9ac051d3-d00b-4933-a557-2a2b0dd45f98@github.com>
Message-ID: <HtstdPOnB1fCIH6I7eOtpyb01RKGhNOHAdv3dAsj3_Y=.8904ba4c-cfe8-430a-a6ca-03d2c0a7c032@github.com>

On Thu, 15 May 2025 01:59:50 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62:
>> 
>>> 60:  * produced.
>>> 61:  */
>>> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate {
>> 
>> What's the reason we don't use `SSLEngineTemplate` here?
>
> There's a bug in `SSLEngine`/`SSLSocket` that prevents configuration callbacks from working as originally imagined.  I hate working around it.
> 
> The subclass constructor now calls `super()`, which then calls back to the `configure*()` methods, but you can't pass any parameters.  One of these days this should be fixed.  
> 
> I find it easier to just copy `SSLEngineTemplate.java` instead of `extends`.  
> 
> I've worked around it to remind myself this needs to be fixed someday.

Yes, I had this problem myself. Actually it's specific to `SSLEngineTemplate` because `SSLSocketTemplate` constructor doesn't call any configure methods. `Flexible Constructor Bodies` feature should address this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091667466

From mullan at openjdk.org  Thu May 15 19:31:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 May 2025 19:31:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
Message-ID: <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>

On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> 
> @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> 
> @seanjmullan What do you think?

Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2884859280

From weijun at openjdk.org  Thu May 15 19:43:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 15 May 2025 19:43:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
 <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>
Message-ID: <JKeXCkgS0BUuv7kT5-L99Okqt91JIyB8HORk4U0td7o=.0ffef689-556f-4dad-94cc-6e545ca1f4b0@github.com>

On Thu, 15 May 2025 04:26:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682:
>> 
>>> 1680:                     // ...now the final expand.
>>> 1681:                     return (deriveKey ?
>>> 1682:                             hkdf.deriveKey("TlsExporterKeyingMaterial",
>> 
>> Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM?
>
> From a previous comment:
> 
> IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:
> 
>     https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels

Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091851924

From mullan at openjdk.org  Thu May 15 20:45:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 May 2025 20:45:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
Message-ID: <P73eWXNcdvJ0kyV3cXpJSsQJFn6D2wB46mlpFBz-0yg=.b95c5ef4-52ff-4c9e-be2a-710e026be2e6@github.com>

On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merged with changes for JDK-8353578

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169:

> 167: 
> 168:     /**
> 169:      * Generate Exported Keying Material (EKM) calculated according to the

Suggest saying "Generates".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091930435

From mullan at openjdk.org  Thu May 15 20:55:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 May 2025 20:55:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
Message-ID: <l0BtSzp4ViOlw28Qt0R83GUP0xPCjK0YOhy-U7nN9B8=.197551b2-3795-4d2b-96a8-0d6d432e8c9a@github.com>

On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merged with changes for JDK-8353578

test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 320:

> 318:         log("Data: Equal inputs test passed");
> 319: 
> 320:         // Different labels, now use exportKeyMaterialData() for coverage

Should update the comment with new method name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091943734

From wetmore at openjdk.org  Fri May 16 01:16:13 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 01:16:13 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15]
In-Reply-To: <P73eWXNcdvJ0kyV3cXpJSsQJFn6D2wB46mlpFBz-0yg=.b95c5ef4-52ff-4c9e-be2a-710e026be2e6@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <qEp4cwRUTqXKfRap33JlarszvH9zIY-Zf1vZ96plX68=.c09ab355-ec27-4d65-b3da-07bdb1aeaf3b@github.com>
 <P73eWXNcdvJ0kyV3cXpJSsQJFn6D2wB46mlpFBz-0yg=.b95c5ef4-52ff-4c9e-be2a-710e026be2e6@github.com>
Message-ID: <NXzVXKjbtdrKf5yjnv1Rtfd3P1i5F_CFCAsBtnEeN9c=.62ce2b53-3519-4b41-871d-608fae52c79a@github.com>

On Thu, 15 May 2025 20:42:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merged with changes for JDK-8353578
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169:
> 
>> 167: 
>> 168:     /**
>> 169:      * Generate Exported Keying Material (EKM) calculated according to the
> 
> Suggest saying "Generates".

Done.

> test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 320:
> 
>> 318:         log("Data: Equal inputs test passed");
>> 319: 
>> 320:         // Different labels, now use exportKeyMaterialData() for coverage
> 
> Should update the comment with new method name.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2092166964
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2092167873

From wetmore at openjdk.org  Fri May 16 01:28:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 01:28:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v16]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <GJv5-ywZF9EXmLOdCf9S7u_ugCTQfx3QS6SCFhSzdZc=.c620f9c9-1fc6-40fa-bea5-bcd8358f5b88@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-8341346
 - Minor Codereview comments.
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview:  removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused
 - Merged with changes for JDK-8353578
 - Merge
 - Merge branch 'master' into JDK-8341346
 - Missed one review comment
 - More codereview comments
 - ... and 13 more: https://git.openjdk.org/jdk/compare/f6b0f016...e93e38e4

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=15
  Stats: 947 lines in 6 files changed: 933 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From duke at openjdk.org  Fri May 16 07:36:00 2025
From: duke at openjdk.org (kieran-farrell)
Date: Fri, 16 May 2025 07:36:00 GMT
Subject: Integrated: 8356395: Spec needs to be clarified for InterfaceAddress
 class level API documentation and getBroadcast() method
In-Reply-To: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
References: <farUvoo-W3Oo7pP1Rt41ZmsZTKBTe8yAeMtlSL4lhxY=.359d588e-d695-4d03-bc4c-dc42f362ddcf@github.com>
Message-ID: <eZ2L21_TDXTuIgn-4WIQQtSLwqPsWIrPMKlxY1tN4WA=.14a79267-4300-44fa-acf0-f6c50aba16f1@github.com>

On Wed, 7 May 2025 14:02:52 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Spec currently suggests that only IPv6 addresses can return null for InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 address such as the loopback address do not support broadcasting and can therefore also return null.

This pull request has now been integrated.

Changeset: a8d8ffa8
Author:    kieran-farrell <kieran.farrell at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8d8ffa8ad63f8f6308e2da224894fb2aded5d5c
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8356395: Spec needs to be clarified for InterfaceAddress class level API documentation and getBroadcast() method

Reviewed-by: dfuchs

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

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

From duke at openjdk.org  Fri May 16 08:06:02 2025
From: duke at openjdk.org (duke)
Date: Fri, 16 May 2025 08:06:02 GMT
Subject: RFR: 8351843: change
 test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a
 manual test [v2]
In-Reply-To: <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
References: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
 <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
Message-ID: <nZTDMldFH09e4cU_e0-sxrPgFnn2Xg32DhRFruruILg=.56da572d-98f5-4e20-981e-670af26d04b8@github.com>

On Thu, 15 May 2025 13:47:23 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test
>
> serhiysachkov 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:
> 
>  - 8351843: separating windows test and moving it to manual group
>  - Merge branch 'master' into JDK-8351843
>  - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

@serhiysachkov 
Your change (at version 4f2f7a38986ca43fa96a8ccaea9988d97c7b08fb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24113#issuecomment-2885964050

From dfuchs at openjdk.org  Fri May 16 10:45:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 May 2025 10:45:06 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
Message-ID: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
> 
>  - merge latest changes from master branch
>  - Undo whitespace change
>  - Remove unnecessary import
>  - Merge remote-tracking branch 'origin/master' into http3
>  - Fix test license
>  - Remove leftover file (test was moved to parent directory)
>  - Remove unnecessary import
>  - Update throws clauses
>  - Merge remote-tracking branch 'origin/master' into http3
>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

I spotted some inacuracy in QuicEndpoint. I will take care of these.

src/java.net.http/share/classes/jdk/internal/net/http/Http3ClientImpl.java line 158:

> 156:                     quicIdleMillis = h3Millis + 60000; // a minute more than h3 timeout
> 157:                 }
> 158:                 transportParameters.setIntParameter(max_idle_timeout, quicIdleMillis);

I understand we don't want the QUIC Idle Timeout to kill idle connections before the HTTP/3 idle timeout has expired. But on the other hand, we should not let the HTTP/3 idle timeout set a quic idle timeout that is less than the default quic  timeout.
We should take into account the value of the default quic timeout that we use in QuicConnectionImpl here.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:

> 735:         // channel, and a single selector thread, so we can do
> 736:         // the reading directly in the selector thread and offload
> 737:         // the parsing (the readLoop) to the executor.

This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:

> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
> 821:                         pauseReading();
> 822:                         readLoopScheduler.runOrSchedule(executor);

This line should not be needed: we should already have kicked the read loop at line 797.

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

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-2846207620
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092779174
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092786818
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092805633

From michaelm at openjdk.org  Fri May 16 11:42:08 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 16 May 2025 11:42:08 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=09
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From abarashev at openjdk.org  Fri May 16 14:18:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 16 May 2025 14:18:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
Message-ID: <EMJKUCvmH5GGspaxvi-i63I23SvZnC0kK0SBI00Q4Zo=.e5d81154-b673-4b8f-8f4d-3df12dd16829@github.com>

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
> 
>  - merge latest changes from master branch
>  - Undo whitespace change
>  - Remove unnecessary import
>  - Merge remote-tracking branch 'origin/master' into http3
>  - Fix test license
>  - Remove leftover file (test was moved to parent directory)
>  - Remove unnecessary import
>  - Update throws clauses
>  - Merge remote-tracking branch 'origin/master' into http3
>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

@seanjmullan @djelinski We should probably re-evaluate the priority of `TLS Certificate Compression` JEP:
https://bugs.openjdk.org/browse/JDK-8281710

Certificate compression seems to be [particularly important for QUIC performance](https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study), the work has been started already in #7599

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2886849963

From mullan at openjdk.org  Fri May 16 16:52:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 16 May 2025 16:52:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <JKeXCkgS0BUuv7kT5-L99Okqt91JIyB8HORk4U0td7o=.0ffef689-556f-4dad-94cc-6e545ca1f4b0@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
 <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>
 <JKeXCkgS0BUuv7kT5-L99Okqt91JIyB8HORk4U0td7o=.0ffef689-556f-4dad-94cc-6e545ca1f4b0@github.com>
Message-ID: <iGICQkjsTZruuQGo2Hr0i3qSivGG1T-U55shi62i734=.5100e438-e4d6-4642-933f-b8f2f6e58f68@github.com>

On Thu, 15 May 2025 19:41:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> From a previous comment:
>> 
>> IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:
>> 
>>     https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
>
> Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now.

How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093387401

From wetmore at openjdk.org  Fri May 16 17:19:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 17:19:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <iGICQkjsTZruuQGo2Hr0i3qSivGG1T-U55shi62i734=.5100e438-e4d6-4642-933f-b8f2f6e58f68@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
 <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>
 <JKeXCkgS0BUuv7kT5-L99Okqt91JIyB8HORk4U0td7o=.0ffef689-556f-4dad-94cc-6e545ca1f4b0@github.com>
 <iGICQkjsTZruuQGo2Hr0i3qSivGG1T-U55shi62i734=.5100e438-e4d6-4642-933f-b8f2f6e58f68@github.com>
Message-ID: <j0YCfXu6_PGJFNNDBanJo5p-e2qUQx521-PhUsOI294=.d7113b5d-720d-4ff4-82bb-375fee237e9d@github.com>

On Fri, 16 May 2025 16:50:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now.
>
> How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API?

As discussed with @seanjmullan / @wangweij , that is the direction I'll try.  It's not perfect, but a definite step in the right direction.  Thanks for the idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093423153

From duke at openjdk.org  Fri May 16 19:37:51 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Fri, 16 May 2025 19:37:51 GMT
Subject: RFR: 8357013: Optimize response code parsing in HttpURLConnection
In-Reply-To: <H1GhzGIRe-bi14VOiJkoGoskKcFnhKA11PyRJY_sPYs=.87a02580-4714-45d9-a6a0-bddd876231d0@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
 <H1GhzGIRe-bi14VOiJkoGoskKcFnhKA11PyRJY_sPYs=.87a02580-4714-45d9-a6a0-bddd876231d0@github.com>
Message-ID: <2zKfSnQeEa9cgreuub52YlZDAW1f2x2zBCpJfkwN2p4=.1870cc1f-c433-40c7-b82d-eb501af7c445@github.com>

On Thu, 15 May 2025 11:47:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for this fix. The proposed changes LGTM. Did you run tier2 tests?

Yes, I've run tier1 and tier2 tests. There were a few unrelated failures, but the [test ](https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/HttpURLConnection/HttpResponseCode.java)that covers this change passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25245#issuecomment-2887530008

From wetmore at openjdk.org  Fri May 16 21:34:52 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:34:52 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <xz0yOwnH5Ys3lOYAwlWY5K6A_ZDgtagD52NXMM7bDmc=.7cb567df-f4cc-44c1-a418-a547b57311f1@github.com>
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
 <ASd1LeY3bzPuc28CZLC-FdAsonbMzf1QV7yEXvoW6Nk=.ead0f917-036d-4f6e-a2e3-4f0e190da565@github.com>
 <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>
 <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com>
Message-ID: <phA9SNPEZYCXZZpP7zXznFbqSsSf5PBqHj49Wa9KZXc=.88c81132-3811-49b2-8821-c1938fff1e62@github.com>

On Tue, 13 May 2025 13:07:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.
>
> +1 for UOE. It's not that we got a key and found it un-extractable. It's that we asked for data but were refused.

I have updated to return a `UOE`.  

I'm a little concerned that `UOE` will be returned for both a non-overriden `exportKeyingMaterial*` method, and if there is a problem with the derivation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093696922

From wetmore at openjdk.org  Fri May 16 21:34:53 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:34:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <bltBG-g0UHiKV5skHthbljRG6qB1Mw3-udKUONQp7mo=.0dad720a-1548-466f-ab3d-9241780056bd@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <NpgWjl8kBa9sYJCROysOCeKT8SloK6b54p8pLf5n1uQ=.9263183a-28ff-4403-a6b4-a55ad61b0e23@github.com>
 <bltBG-g0UHiKV5skHthbljRG6qB1Mw3-udKUONQp7mo=.0dad720a-1548-466f-ab3d-9241780056bd@github.com>
Message-ID: <zpMTRIrgwylTLNcFTym3IbVsE9_QPtdQ-EscInY2Pnw=.2999dec7-1c9b-475a-89b1-713168f8f0b3@github.com>

On Thu, 15 May 2025 04:22:42 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650:
>> 
>>> 1648:                     emptyHash = md.digest();
>>> 1649:                 } catch (NoSuchAlgorithmException nsae) {
>>> 1650:                     throw new RuntimeException(
>> 
>> We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm.
>
> I can do a `ProviderException` if you like, but our JSSE code is all over the place.  Sometimes it's a `RuntimeException`, other times we wrap it into into a `SSLException`, and sometimes we directly do a `fatal()`.  I'd say we do `RuntimeException` a little more often than `ProviderException`.

Updated to to `ProviderException` since the point does fit the description of the class better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093697971

From wetmore at openjdk.org  Fri May 16 21:34:53 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:34:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: <j0YCfXu6_PGJFNNDBanJo5p-e2qUQx521-PhUsOI294=.d7113b5d-720d-4ff4-82bb-375fee237e9d@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <BDM_C91ITOs7ImsjpY7ehAIztFKyfnje0MosgIg19Ik=.720d5eb0-64f3-4b4b-8f25-5844c005a60b@github.com>
 <nP9v7isTXue72Vjy9MAkos_to_dnGzsM13UbUn7JJFA=.e8a587fe-d06a-4b7a-b392-a66214222e50@github.com>
 <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com>
 <JKeXCkgS0BUuv7kT5-L99Okqt91JIyB8HORk4U0td7o=.0ffef689-556f-4dad-94cc-6e545ca1f4b0@github.com>
 <iGICQkjsTZruuQGo2Hr0i3qSivGG1T-U55shi62i734=.5100e438-e4d6-4642-933f-b8f2f6e58f68@github.com>
 <j0YCfXu6_PGJFNNDBanJo5p-e2qUQx521-PhUsOI294=.d7113b5d-720d-4ff4-82bb-375fee237e9d@github.com>
Message-ID: <FJjQlHLGUH3_n1Gec34Ls9hqbhuihxu0hVrAJqz0eb0=.c25503ee-6aed-422f-9027-02a6516e68fe@github.com>

On Fri, 16 May 2025 17:17:04 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API?
>
> As discussed with @seanjmullan / @wangweij , that is the direction I'll try.  It's not perfect, but a definite step in the right direction.  Thanks for the idea.

Check the latest version, available after my build/test run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093698471

From wetmore at openjdk.org  Fri May 16 21:34:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:34:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <J2wTfQWzVLWaX1EqxjoxHNQ9AdB4LlYpJt_kSQBqcDo=.7fd91454-e70d-4b2e-860b-9d7f8bf0de72@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
 <qQmgQf6p_bRMA1437G8ch7N9F4A3-pmdE3qMmxG4svk=.990820ee-10c1-46c1-a2ba-a476c903ed0a@github.com>
 <J2wTfQWzVLWaX1EqxjoxHNQ9AdB4LlYpJt_kSQBqcDo=.7fd91454-e70d-4b2e-860b-9d7f8bf0de72@github.com>
Message-ID: <0Ax5kSm0HiAI-OAXzbT4AuQGxIelKTGcZLshW0hC3Sk=.32e7ca68-a6ea-41cc-93c7-d526140c0522@github.com>

On Thu, 8 May 2025 06:03:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694:
>> 
>>> 1692: 
>>> 1693:                     // ...now the final expand.
>>> 1694:                     SecretKey key = hkdf.deriveKey(label,
>> 
>> PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES".
>
> IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:
> 
>     https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels 
> 
> Thus the type needs to be something generic.  The label sounded good initially, but there is no specific prohibition against non-null/empty label in the TLS Exporters, but KDF prohibits null/empty labels.
> 
> Maybe a label like "ExportKeyingMaterial"?

I have adjusted the API to take an `algName` for the `SecretKey`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093695778

From wetmore at openjdk.org  Fri May 16 21:34:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:34:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: <zBkO4iZPqFZLGePpv8WXyA9u0TVmCgqxVCpgO058b0E=.2e1de419-077e-426d-92e5-191f07a1be4e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <vENq571AStnxmJUjwyNi_SSuBcIbbEXu1HktcYvso7g=.28a94452-94cd-452c-9506-0aded820a7c7@github.com>
 <zBkO4iZPqFZLGePpv8WXyA9u0TVmCgqxVCpgO058b0E=.2e1de419-077e-426d-92e5-191f07a1be4e@github.com>
Message-ID: <XyrPq45_5B__-6MCgNb9Q8H9bVT8eQxonpEH1BUp994=.95145a68-5611-4fa8-bbdb-640b8dac7aec@github.com>

On Wed, 7 May 2025 16:21:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1808:
> 
>> 1806:             String label, byte[] context, int length) throws SSLKeyException {
>> 1807:         byte[] bytes =
>> 1808:                 exportKeyingMaterialKey(label, context, length).getEncoded();
> 
> In PKCS #11, calling `deriveKey(...).getEncoded()` is not equivalent to `deriveData()`. It's quite likely that `deriveKey` returns an un-extractable key, but `deriveData` using the exact same input returns the keying material.

Adjusted for the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093695000

From wetmore at openjdk.org  Fri May 16 21:50:12 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 May 2025 21:50:12 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v17]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <1KpbYmAy2y-Dciswnm9jZhYIG7ITQy7mQD-2x6jm1dw=.f4560916-9395-40c2-95cf-14cfedff0e24@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into JDK-8341346
 - Updated API to include SecretKey type, and a couple minor codereview comments
 - Merge branch 'master' into JDK-8341346
 - Minor Codereview comments.
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview:  removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused
 - Merged with changes for JDK-8353578
 - Merge
 - Merge branch 'master' into JDK-8341346
 - ... and 15 more: https://git.openjdk.org/jdk/compare/10258dc5...0f08ff2c

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=16
  Stats: 1038 lines in 9 files changed: 1020 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Sat May 17 00:03:10 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 17 May 2025 00:03:10 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Updated copyright dates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/0f08ff2c..638985b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=16-17

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

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

From jpai at openjdk.org  Mon May 19 09:07:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 09:07:02 GMT
Subject: RFR: 8351843: change
 test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a
 manual test [v2]
In-Reply-To: <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
References: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
 <d1t4lIF9D8yx20m6pOPbP4ERj9eljauxFne0gK036hE=.593f00a1-59a5-494d-86b1-bc427c38f0a8@github.com>
Message-ID: <xGq_63hP-dW9KAncVBveTS8vJvUcBFF8TfPXlNNxRlU=.73195cbf-0aae-467a-9326-cb67d76bbc19@github.com>

On Thu, 15 May 2025 13:47:23 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test
>
> serhiysachkov 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:
> 
>  - 8351843: separating windows test and moving it to manual group
>  - Merge branch 'master' into JDK-8351843
>  - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

test/jdk/com/sun/net/httpserver/simpleserver/DocRootDirPermissionsWinTest.java line 34:

> 32:  */
> 33: 
> 34: public class DocRootDirPermissionsWinTest extends DocRootDirPermissionsTest{

Hello Serhiy, the test doesn't necessarily have to extend from that other test and we could probably just make `DocRootDirPermissionsTest.run(String[] args)` a static method and call that from within the main() method of this `DocRootDirPermissionsWinTest`. But I see some work was done to make those methods instance methods instead of static which means that you might have to revert that. So I think it's fine in the current form and I see Daniel has reviewed the PR and you have run this for tier1 and tier2. I'll go ahead and sponsor this now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24113#discussion_r2095226736

From duke at openjdk.org  Mon May 19 09:11:04 2025
From: duke at openjdk.org (serhiysachkov)
Date: Mon, 19 May 2025 09:11:04 GMT
Subject: Integrated: 8351843: change
 test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a
 manual test
In-Reply-To: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
References: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>
Message-ID: <dcI21NewVIS2QVDGpImalGjR_CMDDD32Km29lpkT24o=.874b4910-00b2-43c8-80c8-2ac6e9aafee9@github.com>

On Wed, 19 Mar 2025 11:38:52 GMT, serhiysachkov <duke at openjdk.org> wrote:

> change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

This pull request has now been integrated.

Changeset: effe40a2
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/effe40a24c29dc507eea5efef7b0736a33bc34a7
Stats:     618 lines in 4 files changed: 331 ins; 287 del; 0 mod

8351843: change test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

Reviewed-by: dfuchs

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

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

From jpai at openjdk.org  Mon May 19 09:45:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 09:45:52 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <eSETFAt6fHX8DfZxGatsbM5jtqMdAB6a9tfNi6xvLpI=.8e456d72-e00f-47e1-8d61-e069a44270fc@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

Hello Michael @Michael-Mc-Mahon, while at it, do you think we should also update the specification of `Authenticator.requestPasswordAuthenticationInstance(...)` method to specify that the `url` parameter to it can be null. Right now it just says:


/**
 * Ask this authenticator for a password.
 *
 * @param host The hostname of the site requesting authentication.
 * @param addr The InetAddress of the site requesting authorization,
 *             or null if not known.
 * @param port the port for the requested connection
 * @param protocol The protocol that's requesting the connection
 *          ({@link java.net.Authenticator#getRequestingProtocol()})
...
 * @param url The requesting URL that caused the authentication
... 
public PasswordAuthentication
requestPasswordAuthenticationInstance(String host,
                                      InetAddress addr,
                                      int port,
                                      String protocol,
                                      String prompt,
                                      String scheme,
                                      URL url,
                                      RequestorType reqType) {

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2890359894

From dfuchs at openjdk.org  Mon May 19 11:09:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 19 May 2025 11:09:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@github.com>
Message-ID: <U-6OnS3dKkBpFuvz-qTxnpiUp8iQbuYtI1Ihi3GXMrQ=.642ef9d0-a7d0-4d0d-9f83-512a10043465@github.com>

On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 78:

> 76:      * controlled. Consider using a unique value for the
> 77:      * SecurityProperties.includedInExceptions(String value) mechanism
> 78:      * Current values defined are "socket", "jar", "userInfo"

If I am not mistaken the "socket" info is no longer here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2095457460

From michaelm at openjdk.org  Mon May 19 13:14:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 19 May 2025 13:14:56 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <ZySr7R3rQ5EHwZ9Wa4zfY_Bb6-HDh4e4cmeGk61AzfU=.f92b64da-732e-44cf-b91e-2a123e6bfcb1@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

> Hello Michael @Michael-Mc-Mahon, while at it, do you think we should also update the specification of `Authenticator.requestPasswordAuthenticationInstance(...)` method to specify that the `url` parameter to it can be null. Right now it just says:
> 
> ```java
> /**
>  * Ask this authenticator for a password.
>  *
>  * @param host The hostname of the site requesting authentication.
>  * @param addr The InetAddress of the site requesting authorization,
>  *             or null if not known.
>  * @param port the port for the requested connection
>  * @param protocol The protocol that's requesting the connection
>  *          ({@link java.net.Authenticator#getRequestingProtocol()})
> ...
>  * @param url The requesting URL that caused the authentication
> ... 
> public PasswordAuthentication
> requestPasswordAuthenticationInstance(String host,
>                                       InetAddress addr,
>                                       int port,
>                                       String protocol,
>                                       String prompt,
>                                       String scheme,
>                                       URL url,
>                                       RequestorType reqType) {
> ```

I know this is a standalone class which can in theory be instantiated and these methods called with `null` arguments, but I wonder is it possible in practice for a real authentication to occur without a URL. I'm not sure it's worth investing too much time in fixing all these inconsistencies.

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2890987453

From hchao at openjdk.org  Mon May 19 15:10:55 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 19 May 2025 15:10:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18]
In-Reply-To: <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
Message-ID: <NjERNaQrW8eTEaw66wmXTG1b92xDYJ-XP83W5RthojI=.98c3ce0a-2f29-4ef6-9a86-9b4f67e3ac8d@github.com>

On Sat, 17 May 2025 00:03:10 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright dates.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 746:

> 744:         return serverRandom;
> 745:     }
> 746: 

It looks like these getters (`getExporterMasterSecret(`), `getClientRandom()`, and `getServerRandom()`) are not used yet outside of this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2095927197

From hchao at openjdk.org  Mon May 19 15:16:55 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 19 May 2025 15:16:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18]
In-Reply-To: <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
Message-ID: <lEXGNFgfrCwV8dJNiLn8u1VxjcDeebADZKp_FNT57PU=.ca7389ae-8919-4eeb-affe-3af9c67c3d76@github.com>

On Sat, 17 May 2025 00:03:10 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright dates.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1623:

> 1621:                 } finally {
> 1622:                     KeyUtil.destroySecretKeys(derivedSecret);
> 1623:                 }

The `derivedSecret` is destroyed and cleared. How about `exporterMasterSecret`? Shall we also destroy it perhaps when the session is invalidated or closed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2095944384

From nbenalla at openjdk.org  Mon May 19 16:08:02 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 16:08:02 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
Message-ID: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>

Please review this patch to fix some `javadoc` bugs in `java.base`.
Certain `@link` tags used to refer to private fields instead of public APIs.

A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.

TIA

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

Commit messages:
 - respond to feedback
 - fix incorrect `@link` tags

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

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

From liach at openjdk.org  Mon May 19 16:08:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 16:08:03 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:

> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
> 4892:      * @throws NullPointerException if the argument is null
> 4893:      * @see <code>primitiveZero(Wrapper)</code>

Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:

> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
> 1340:      * @see <code>MethodType.readResolve()</code>
> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>

This is already not generated by the javadoc as this method is private. Why is this check against a private method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316583
PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316628

From duke at openjdk.org  Mon May 19 16:08:04 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 16:08:04 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
Message-ID: <b8Lmu1eAM7BHZOWKxWKFMH7wVAaZ02WB3CmFuiN9rUs=.dcefa204-dcb2-4583-b5a9-da50d4e6bc74@github.com>

On Sun, 18 May 2025 02:17:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:
> 
>> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
>> 4892:      * @throws NullPointerException if the argument is null
>> 4893:      * @see <code>primitiveZero(Wrapper)</code>
> 
> Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant.

From?<https://github.com/openjdk/jdk/pull/23706#discussion_r2094138280>:
Suggestion:

     * @see MethodHandles#zero

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094592478

From nbenalla at openjdk.org  Mon May 19 16:08:04 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 16:08:04 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
Message-ID: <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>

On Sun, 18 May 2025 02:18:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
> 
>> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
>> 1340:      * @see <code>MethodType.readResolve()</code>
>> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>
> 
> This is already not generated by the javadoc as this method is private. Why is this check against a private method?

They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2095501605

From wetmore at openjdk.org  Mon May 19 18:08:08 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 19 May 2025 18:08:08 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v19]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <UFCEReZHNdm10wvJsy5iM4YcqwvTWsjGYQQdBDasS7s=.bbe48b80-e095-4f75-83b6-dc3c5e53c76f@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' into JDK-8341346
 - Updated copyright dates.
 - Merge branch 'master' into JDK-8341346
 - Updated API to include SecretKey type, and a couple minor codereview comments
 - Merge branch 'master' into JDK-8341346
 - Minor Codereview comments.
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - Codereview:  removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused
 - Merged with changes for JDK-8353578
 - ... and 17 more: https://git.openjdk.org/jdk/compare/bd995256...ff494229

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=18
  Stats: 1041 lines in 9 files changed: 1020 ins; 2 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Mon May 19 20:18:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 19 May 2025 20:18:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18]
In-Reply-To: <NjERNaQrW8eTEaw66wmXTG1b92xDYJ-XP83W5RthojI=.98c3ce0a-2f29-4ef6-9a86-9b4f67e3ac8d@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
 <NjERNaQrW8eTEaw66wmXTG1b92xDYJ-XP83W5RthojI=.98c3ce0a-2f29-4ef6-9a86-9b4f67e3ac8d@github.com>
Message-ID: <lu5DldOYabUwM9a84Pm3gV-RQQj_bqynrOgaA3KlfZo=.46a53c17-1fa5-466e-a13e-6d7c77b629ab@github.com>

On Mon, 19 May 2025 15:06:26 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright dates.
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 746:
> 
>> 744:         return serverRandom;
>> 745:     }
>> 746: 
> 
> It looks like these getters (`getExporterMasterSecret(`), `getClientRandom()`, and `getServerRandom()`) are not used yet outside of this class.

Good point, everything is internal now.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096422333

From wetmore at openjdk.org  Mon May 19 20:28:46 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 19 May 2025 20:28:46 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  get*() no longer needed, backout error (oops!)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/ff494229..cde5edb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=18-19

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

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

From wetmore at openjdk.org  Mon May 19 20:28:48 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 19 May 2025 20:28:48 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18]
In-Reply-To: <lEXGNFgfrCwV8dJNiLn8u1VxjcDeebADZKp_FNT57PU=.ca7389ae-8919-4eeb-affe-3af9c67c3d76@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <Y-xKmh20MLmZKUAOUsnXcsGUPz3bcGW7w0fd3cEs8Ok=.1b6fdc49-0ae1-42c5-94e2-b15ffbbc7966@github.com>
 <lEXGNFgfrCwV8dJNiLn8u1VxjcDeebADZKp_FNT57PU=.ca7389ae-8919-4eeb-affe-3af9c67c3d76@github.com>
Message-ID: <6C6lGpq5XccWlV_AXIdTSeXKTBGNLaj3b1SORvMcUCg=.c23348c6-6fc4-4b32-9dbf-323355f82fa3@github.com>

On Mon, 19 May 2025 15:13:26 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright dates.
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1623:
> 
>> 1621:                 } finally {
>> 1622:                     KeyUtil.destroySecretKeys(derivedSecret);
>> 1623:                 }
> 
> The `derivedSecret` is destroyed and cleared. How about `exporterMasterSecret`? Shall we also destroy it perhaps when the session is invalidated or closed?

In RFC 8446/Section 7.1, the "derived" secret and "Master Secret" are temporary variables used to derive the application secrets, the exporter_master_secret, and the resumption_master_secret.  These variables are long-lived and don't need to be cleared like these two.

When we invalidate a session, that simply marks the session as unresumable, and doesn't destroy the session for active connections.  We don't "close" sessions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096432034

From darcy at openjdk.org  Mon May 19 20:43:52 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 19 May 2025 20:43:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
 <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
Message-ID: <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>

On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
>> 
>>> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
>>> 1340:      * @see <code>MethodType.readResolve()</code>
>>> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>
>> 
>> This is already not generated by the javadoc as this method is private. Why is this check against a private method?
>
> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)

Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be.

As it is, if the see tags are going to stay, I don't think `<code>foo</code>` markup should be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2096456914

From jnimeh at openjdk.org  Mon May 19 22:41:57 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 19 May 2025 22:41:57 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20]
In-Reply-To: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com>
Message-ID: <N1dDsbXxzJ0bdrzxeTZnNbvzXWQZFjJgVC9O0-dmKqI=.c3c0078c-889a-4a33-a520-6d7a4cae496a@github.com>

On Mon, 19 May 2025 20:28:46 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get*() no longer needed, backout error (oops!)

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1672:

> 1670:                 // RFC 5705, "If no context is provided, ..."
> 1671:                 seed[pos++] = (byte) ((context.length >> 8) & 0xFF);
> 1672:                 seed[pos++] = (byte) ((context.length) & 0xFF);

Because you're doing a primitive narrowing conversion down to a byte I don't think you need the 0xFF masking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096561543

From alanb at openjdk.org  Tue May 20 06:50:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 06:50:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <VcfrHDkeY9BD6yyKCDnOI58TH0DBihbleOxIBJknmUQ=.5fe13ac5-1863-4e7a-8917-2c8d0170fa9f@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 138:

> 136:  * {@link #isCompletedAbnormally} is true if a task was either
> 137:  * cancelled or encountered an exception, in which case {@link
> 138:  * #getException()} will return either the encountered exception or

Looks right too, the private overload of getException was added in JDK 22.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097113958

From alanb at openjdk.org  Tue May 20 06:54:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 06:54:58 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <2ZTFvRUO5p9CkTijR0qS6x9bwgbI3o4C286Wk9HvHVU=.04f8ca7b-cdf9-4a09-9d3d-587a414d51e1@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2023:

> 2021:         /**
> 2022:          * Provides a service with one or more implementations. The package for
> 2023:          * each {@link Provides#providers() provider} (or provider factory) is

okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097120353

From pminborg at openjdk.org  Tue May 20 12:06:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:06:35 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
Message-ID: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>

This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321

In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.

This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

Commit messages:
 - Remove import
 - Remove comment
 - Use getBufferAddress() rather than address()

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

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

From pminborg at openjdk.org  Tue May 20 12:06:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:06:35 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <lzJg1sV-u4HD60jpBBDLlUWKBYsM8PQA75M7skqrrPM=.5f9807b3-ec55-409a-b61e-9411d6157508@github.com>

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 254:

> 252:         ByteBuffer dst = Util.getTemporaryDirectBuffer(len);
> 253:         assert dst.position() == 0;
> 254:         NIO_ACCESS.acquireSession(dst);

Not strictly needed, but is proposed for consistency.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:

> 457: 
> 458:             boolean pending = false;
> 459:             NIO_ACCESS.acquireSession(buf);

Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097665536
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097670174

From alanb at openjdk.org  Tue May 20 12:27:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 12:27:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <Toe2xo4_PTLsTbdLXaE_IrNjmGMWDNAh24iC8eBDm1A=.f9472576-d2d5-4e30-bd15-432769b81e2a@github.com>

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

We need to audit the tests for the APIs that take a byte buffer to ensure that we have tests to exercise these APIs with buffers that are views on a memory segment. That would help identify any bugs. 

The temporary buffer cache is internal so I think better to separate from this JBS issue and PR as these cases cannot be views on a memory segment. Future work to re-implement the temporary buffer cache can re-visit this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894215287

From pminborg at openjdk.org  Tue May 20 12:49:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:49:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v2]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <vdNsstK_DuEmV0u3oqdPeGACB5930o7ZRAXfMjSkXvI=.96fffbc5-a065-49fd-8ff6-946f41556dac@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Revoke changes in classes that is always using DirectBuffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/6e733a18..9c5a3573

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

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

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

From pminborg at openjdk.org  Tue May 20 12:54:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 12:54:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/9c5a3573..f2764bf1

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

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

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

From alanb at openjdk.org  Tue May 20 13:40:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 13:40:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
Message-ID: <WdgiUn8mvh6olrlxQrcx6whmpEpkS1inE5eg0R-tBbg=.12c5165e-6f46-4c6d-9e6e-58192116de4e@github.com>

On Tue, 20 May 2025 12:54:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

A question for folks onsecurity-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894448506

From dfuchs at openjdk.org  Tue May 20 14:02:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 14:02:54 GMT
Subject: RFR: 8357013: Optimize response code parsing in HttpURLConnection
In-Reply-To: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
Message-ID: <mLNwpsjVl_yqjQNVQ_6wfBWwAC9w32LS_01BNmwdzuY=.b567311e-d8b2-48dc-aab7-596b40c8bc9b@github.com>

On Thu, 15 May 2025 05:14:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid allocating a substring to parse the response code in HttpURLConnection#getResponseCode, but instead use the Integer.parseInt overload that accepts String indices.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25245#pullrequestreview-2854323316

From dfuchs at openjdk.org  Tue May 20 14:02:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 14:02:56 GMT
Subject: RFR: 8357013: Optimize response code parsing in HttpURLConnection
In-Reply-To: <2zKfSnQeEa9cgreuub52YlZDAW1f2x2zBCpJfkwN2p4=.1870cc1f-c433-40c7-b82d-eb501af7c445@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
 <H1GhzGIRe-bi14VOiJkoGoskKcFnhKA11PyRJY_sPYs=.87a02580-4714-45d9-a6a0-bddd876231d0@github.com>
 <2zKfSnQeEa9cgreuub52YlZDAW1f2x2zBCpJfkwN2p4=.1870cc1f-c433-40c7-b82d-eb501af7c445@github.com>
Message-ID: <DnN8DCP9jqsZ2Q8r2w4-bgnn5sz6LSlTMvKVogC1VNA=.e4110e0c-f5a0-4e11-b0b7-872d0412ea23@github.com>

On Fri, 16 May 2025 19:34:59 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Thanks for this fix. The proposed changes LGTM. Did you run tier2 tests?
>
>> Thanks for this fix. The proposed changes LGTM. Did you run tier2 tests?
> 
> Yes, I've run tier1 and tier2 tests. There were a few unrelated failures, but the [test ](https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/HttpURLConnection/HttpResponseCode.java)that covers this change passed.

Thanks @kilink ; As a measure of safety I have run tier1 and tier2 against these changes in our CI as well and have observed no related failure. I'm going to approve now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25245#issuecomment-2894527249

From dfuchs at openjdk.org  Tue May 20 14:04:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 14:04:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <kxT45XYpRXuXA-BdYHrEDFAS4GF3V2avnHPpwlySnVw=.0b90c3e6-183b-4e34-82a7-0e39ece26ab4@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

Changes to `java.net.Socket` LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2854340236

From nbenalla at openjdk.org  Tue May 20 14:27:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 20 May 2025 14:27:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
 <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
 <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>
Message-ID: <AcjwrzK8MJLJeTiMG3VAJyPcG3-kGYEprMCumpI_vGg=.4e1b3a27-6d48-42b9-a3e4-6a712bf781f0@github.com>

On Mon, 19 May 2025 20:41:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)
>
> Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be.
> 
> As it is, if the see tags are going to stay, I don't think `<code>foo</code>` markup should be used.

I will revert the changes to `MethoType.java` and try to make the links to the private methods resolvable. (In a future patch)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2098123931

From alanb at openjdk.org  Tue May 20 15:43:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 15:43:00 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
Message-ID: <OCkEcMNLDLpYtzvQQL0huSnqLQCDQbMYbqlQOpOcE0w=.2e39cfd2-019c-45c7-bff1-5b902ee7af84@github.com>

On Tue, 20 May 2025 12:54:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up

src/java.base/share/classes/sun/nio/ch/Util.java line 46:

> 44: public class Util {
> 45: 
> 46:     static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();

There are methods in IOUtil for the classes in sun.nio.ch. So no need to expose NIO_ACCESS here.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 671:

> 669: 
> 670:             } finally {
> 671:                 NIO_ACCESS.releaseSession(buf);

I thin the change to WindowsAsynchronousFileChannel will need more than one reviewer as the I/O operation may complete on a different thread to the one that it was initiated on.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 764:

> 762:                     int outOfs = 0;
> 763:                     if (outBuffer instanceof DirectBuffer) {
> 764:                         outAddr = NIO_ACCESS.getBufferAddress(outBuffer);

This looks right.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1017:

> 1015:                 int outOfs = 0;
> 1016:                 if (outBuffer instanceof DirectBuffer) {
> 1017:                     outAddr = NIO_ACCESS.getBufferAddress(outBuffer);

This looks right.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Digest.java line 292:

> 290:             NIO_ACCESS.acquireSession(byteBuffer);
> 291:             try {
> 292:                 token.p11.C_DigestUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len);

`long address = NIO_ACCESS.getBufferAddress(byteBuffer);` might be clearer here.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 289:

> 287:             NIO_ACCESS.acquireSession(byteBuffer);
> 288:             try  {
> 289:                 token.p11.C_SignUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len);

I think I would introduce a long address here too, only to make the line easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098279301
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098297686
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098298906
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098299247
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098300469
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098302426

From pminborg at openjdk.org  Tue May 20 15:52:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 15:52:06 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v4]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <iW0jvH_sFnO_kK5bQy_z2GBNB-JWor9fuZOmJtIQNso=.3bd31965-2df6-475d-8091-49778d8daaf5@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Add tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/f2764bf1..be261f56

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

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

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

From myankelevich at openjdk.org  Tue May 20 15:58:41 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 20 May 2025 15:58:41 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
Message-ID: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>

HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.

Used to wait until the delay is complete at all times, regardless of the number of active exchanges.

Tests based on @eirbjo work, so adding Erik as a contributor.

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

Commit messages:
 - new line in the end of the test
 - JDK-8304065: HttpServer.stop should terminate immediately if no exchanges are in progress

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

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

From duke at openjdk.org  Tue May 20 15:58:54 2025
From: duke at openjdk.org (duke)
Date: Tue, 20 May 2025 15:58:54 GMT
Subject: RFR: 8357013: HttpURLConnection#getResponseCode can avoid
 substring call when parsing to int
In-Reply-To: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
Message-ID: <nCemyo43KVYt5Vft_tp6tOHp-2fTIiciJD1hNj6Ns74=.66da96be-cea8-44d1-8505-80fd542cf424@github.com>

On Thu, 15 May 2025 05:14:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid allocating a substring to parse the response code in HttpURLConnection#getResponseCode, but instead use the Integer.parseInt overload that accepts String indices.

@kilink 
Your change (at version b2d42d35a1d113649adb696646218d8b63bce9c5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25245#issuecomment-2895018049

From pminborg at openjdk.org  Tue May 20 16:10:07 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 16:10:07 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/be261f56..6435f777

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

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

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

From dfuchs at openjdk.org  Tue May 20 16:57:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 16:57:56 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <nHQ0_QOvqs2sqkUGvCVBcT_OyKxqZPXPCMkn36IcLB8=.28e8ba1d-cbc4-43fa-9377-596ea37d50a9@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

Some early comments. I will review the test next.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 252:

> 250:         selector.wakeup();
> 251:         long latest = System.nanoTime() + delay * 1000000000L;
> 252:         while (System.nanoTime() < latest) {

This is not correct as `latest` may overflow.

Suggestion:

        long start = System.nanoTime();
        while ((System.nanoTime() - start) / 1000_000L < delay ) {

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 411:

> 409:                 logger.log(Level.TRACE, "Stop event requested");
> 410: 
> 411:                 if (terminating && getExchangeCount() == 0) {

It looks like we may have to check `reqConnection.isEmpty()` here too for the case where the `ServerImpl` is configured with an executor, as it looks like the `exchangeCount` will be incremented in the executor. It would be interesting to try & craft a test with that scenario - possibly by configuring the server with an executor that sleeps some before calling `run()`, thus giving the oportunity of the `StopRequestedEvent` to be handled before the `ExchangeImpl` is created.

Also if we reach here we are terminating - so we could simply assert that.

Suggestion:

                boolean terminating = this.terminating;
                assert terminating;
                if (getExchangeCount() == 0 && reqConnection.isEmpty()) {


I suspect the other place where we set `finished = true` should also check that `reqConnection.isEmpty()` (and there we do need to check terminating).

src/jdk.httpserver/share/classes/sun/net/httpserver/StopRequestedEvent.java line 30:

> 28: /**
> 29:  * Stopping event for the http server.
> 30:  * Does not contain ay information about a connection.

Suggestion:

 * The event applies to the whole server and is not tied to any particular exchange.

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

PR Review: https://git.openjdk.org/jdk/pull/25333#pullrequestreview-2854863433
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098395272
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098432081
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098444830

From dfuchs at openjdk.org  Tue May 20 17:02:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 17:02:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <YVUvQibZ3c5IJPLddQjHqqDkKCFqorYEsIPNKNjv3J8=.86c92cf1-daca-44f3-942d-b0b6499e0e5d@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 409:

> 407:             // termination is in progress and exchange count is 0
> 408:             if (r instanceof StopRequestedEvent) {
> 409:                 logger.log(Level.TRACE, "Stop event requested");

Suggestion:

                logger.log(Level.TRACE, "Handling Stop Requested Event");

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 413:

> 411:                 if (terminating && getExchangeCount() == 0) {
> 412:                     finished = true;
> 413:                 }

Suggestion:

                } else {
                    logger.log(Level.TRACE, "Some requests are still pending");
                }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098463447
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098467455

From dfuchs at openjdk.org  Tue May 20 17:20:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 17:20:54 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <H3BSWv4UDnl-zhf1P5G6MfeDypqQaK9VDQzeurBB9Eo=.eed4b926-ad2a-4b90-94ce-95f03381a656@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 128:

> 126: 
> 127:         // Time the shutdown sequence
> 128:         final Duration delayDuration = Duration.ofSeconds(2);

We should use a greater margin here since we're not expecting to wait for that duration, and probably use `Utils.adjustTimeout()` too. I'd suggest something like:

Suggestion:

        final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 160:

> 158:         // Complete the exchange 10 second into the future.
> 159:         // Runs in parallel, so won't block the server stop
> 160:         final Duration exchangeDuration = Duration.ofSeconds(10);

Suggestion:

        final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 190:

> 188:     public void noActiveExchanges() {
> 189:         // With no active exchanges, shutdown should complete immediately
> 190:         final Duration delayDuration = Duration.ofSeconds(1);

Suggestion:

        final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 207:

> 205:         timeShutdown(delayDuration);
> 206:         log("Shutting down the server the second time");
> 207:         timeShutdown(delayDuration);

Should we check the time it took the server to shutdown here too?

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 228:

> 226:                 .uri(URI.create("http://"
> 227:                                 + server.getAddress().getAddress().getHostAddress()
> 228:                                 + ":" + server.getAddress().getPort() + "/"))

We should use `URIBuilder` here to take care of IPv4 vs IPv6 etc...

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 238:

> 236:                     // count the latch down to allow the handler to complete
> 237:                     // and the server's dispatcher thread to proceed; The handler
> 238:                     // is called withing the dispatcher thread since we haven't

Suggestion:

                    // is called within the dispatcher thread since we haven't

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098475385
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098478903
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098481789
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098485308
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098488908
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098489836

From duke at openjdk.org  Tue May 20 17:23:55 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 20 May 2025 17:23:55 GMT
Subject: Integrated: 8357013: HttpURLConnection#getResponseCode can avoid
 substring call when parsing to int
In-Reply-To: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
References: <JL3ZsW-pw8sBNbf2hghq2jZYYNhA7ZZFDeYOTdI6X9Y=.b7f9e1ff-b257-45b8-b901-3998323a13d2@github.com>
Message-ID: <fVqEzWWV9ciucELWuFrA3_RGxlZ69zoZBSCPwUg4zXE=.10109f4d-dda5-4096-987a-28ec1a1bfc80@github.com>

On Thu, 15 May 2025 05:14:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid allocating a substring to parse the response code in HttpURLConnection#getResponseCode, but instead use the Integer.parseInt overload that accepts String indices.

This pull request has now been integrated.

Changeset: e9d1d87b
Author:    Patrick Strawderman <pstrawderman at netflix.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9d1d87b34f636747065c01128a12fc057070e09
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357013: HttpURLConnection#getResponseCode can avoid substring call when parsing to int

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.org  Tue May 20 18:14:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 18:14:54 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <WE5wTXJF9XygXlWnvvATuO_MKD1kHoA5hIDzH2anZb0=.d0838f29-b280-4f6c-82af-963b874f075d@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

Looking at Dispatcher::run - there are a couple of additional places where we should take into account the `finished` flag.
I wonder if we should stop processing events as soon as the `finished` has been set by one event. That would mean testing for `finished` right after calling `handleEvent` - or change `handleEvent` to return a boolean, and exit out of the while loop and close the selector if we have set `finished`. 
Arguably - maybe there should not be any event in the queue after `finished` has been set - but there doesn't seem any valid reason to `reRegister` connections or call `select(1000)` again at that point.

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2895386493

From wetmore at openjdk.org  Tue May 20 21:14:02 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 20 May 2025 21:14:02 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20]
In-Reply-To: <N1dDsbXxzJ0bdrzxeTZnNbvzXWQZFjJgVC9O0-dmKqI=.c3c0078c-889a-4a33-a520-6d7a4cae496a@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com>
 <N1dDsbXxzJ0bdrzxeTZnNbvzXWQZFjJgVC9O0-dmKqI=.c3c0078c-889a-4a33-a520-6d7a4cae496a@github.com>
Message-ID: <b_j7WSbiuwNWuAb59_3jiRkDx3nSVh_jLt6XOLo7xJI=.094b7eaa-fb12-4066-9ba6-397f9c8a13e6@github.com>

On Mon, 19 May 2025 22:24:52 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get*() no longer needed, backout error (oops!)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1672:
> 
>> 1670:                 // RFC 5705, "If no context is provided, ..."
>> 1671:                 seed[pos++] = (byte) ((context.length >> 8) & 0xFF);
>> 1672:                 seed[pos++] = (byte) ((context.length) & 0xFF);
> 
> Because you're doing a primitive narrowing conversion down to a byte I don't think you need the 0xFF masking.

No, not required.  `java.lang.Integer.byteValue()` does exactly this.  

But I was thinking to leave so the intent was clear.  We talked, and will leave for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2098882406

From wetmore at openjdk.org  Tue May 20 22:45:40 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 20 May 2025 22:45:40 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v21]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <Za2JaxRFCyYjP5ctFW0owoOiCoi67ZOOmbTSjetN2JI=.ebfe5d0f-221f-49a7-84f5-3db2f04bb215@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'master' into JDK-8341346
 - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
 - get*() no longer needed, backout error (oops!)
 - Merge branch 'master' into JDK-8341346
 - Updated copyright dates.
 - Merge branch 'master' into JDK-8341346
 - Updated API to include SecretKey type, and a couple minor codereview comments
 - Merge branch 'master' into JDK-8341346
 - Minor Codereview comments.
 - Codereview comments:  updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs
 - ... and 20 more: https://git.openjdk.org/jdk/compare/cedd1a53...3e28d345

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=20
  Stats: 1018 lines in 9 files changed: 996 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From swen at openjdk.org  Tue May 20 22:52:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 22:52:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
Message-ID: <qVVOFXmNKnExwBvY7_peOZDqi949XhSdTIeL_bM8Wc8=.398e5fbf-5fba-4f88-bc36-1e12b864c97a@github.com>

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

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

> 950:                 // through a byte[] to get to the combined intrinsic
> 951:                 if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >=
> 952:                         NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) {

Suggestion:

                if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >=
                    NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) {

Here you can use the same alignment style as before

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

> 1605:                             Unsafe.getUnsafe().setMemory(
> 1606:                                     NIO_ACCESS.getBufferAddress(dst),
> 1607:                                 len + dst.position(), (byte) 0);

Suggestion:

                                NIO_ACCESS.getBufferAddress(dst),
                                len + dst.position(), (byte) 0);

Alignment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098987037
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098988459

From wetmore at openjdk.org  Tue May 20 22:57:22 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 20 May 2025 22:57:22 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v22]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <E81Zi5f_VXCIPB27fXT9et5L8j4PU7_fqyUTwh-1wEk=.ade52ef4-ee7a-482b-9a9a-0ebd7371355e@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Missed one change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/3e28d345..33baa381

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=20-21

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

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

From swen at openjdk.org  Tue May 20 23:02:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 23:02:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
Message-ID: <rJ8D16yRBqmG1g6axOkf8KdUzwlS4oW1owQX-49RJVA=.eb657f7b-9a32-4d8a-bd22-d704923d8b15@github.com>

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 583:

> 581:             }
> 582:             default -> throw new InternalError("Should not reach here");
> 583:         };

Suggestion:

        return switch (rand.nextInt(3)) {
            case 0  -> ByteBuffer.allocateDirect(buf.length)
                                 .put(buf)
                                 .flip();
            case 1  -> ByteBuffer.wrap(buf);
            case 2  -> Arena.ofAuto()
                            .allocate(buf.length)
                            .asByteBuffer()
                            .put(buf)
                            .flip();
            default -> throw new InternalError("Should not reach here");
        };

ByteBuffer supports chain programming style, so we can simplify it to this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098997233

From wetmore at openjdk.org  Tue May 20 23:49:37 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 20 May 2025 23:49:37 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v23]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <IAdAysgAn3zf0ZQpqEpb27fVMWMy6UKQY70POqID2dQ=.97bac563-8142-48e9-9e3b-5fb236cb5777@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Minor bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/33baa381..dae583e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=21-22

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

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

From valeriep at openjdk.org  Wed May 21 01:05:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 01:05:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
Message-ID: <1EFXzrYvM3fhV_mggScPO3sVnRRfSipz75__819ckZ0=.0c186ff7-e80a-49be-89fd-fe54753ec5a7@github.com>

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/sun/nio/ch/Util.java line 2:

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

I didn't see src changes in this class? Maybe you meant to update the copyright year for `IOUtil.java`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099102725

From valeriep at openjdk.org  Wed May 21 01:08:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 01:08:55 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v5]
In-Reply-To: <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <ryAITinkLb6aq5KI4RBHpy3qQ1sX1fFm89PsBjTXJJg=.afaeb829-c12c-41e4-b92c-798a7812461f@github.com>
Message-ID: <PdSZR0LssJDcnOFBEFS-cqzKnCcgteElx_5z2BbZm2U=.425dad05-a8f7-4b28-a2b4-62cacb9ecdfd@github.com>

On Tue, 20 May 2025 16:10:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 176:

> 174:                 dst.position(pos + n);
> 175:                 return n;
> 176:             }  finally {

nit: extra space before finally?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099108417

From wetmore at openjdk.org  Wed May 21 01:20:35 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 21 May 2025 01:20:35 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v24]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <Wewbra8nhpy8HUjTgixTwxDx-B5gJQy8kEbTV6H9b_Q=.66e31d95-1d11-49c0-82b9-110d7bee1479@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Added PKCS11 testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/dae583e8..c92d1e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=22-23

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

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

From valeriep at openjdk.org  Wed May 21 05:02:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 05:02:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <WdgiUn8mvh6olrlxQrcx6whmpEpkS1inE5eg0R-tBbg=.12c5165e-6f46-4c6d-9e6e-58192116de4e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
 <WdgiUn8mvh6olrlxQrcx6whmpEpkS1inE5eg0R-tBbg=.12c5165e-6f46-4c6d-9e6e-58192116de4e@github.com>
Message-ID: <GenqNjMq792XTYWXFt9sVovHnLg1FPyvgMgF1aBWcZw=.58d69f87-44ab-4942-a0ae-73283b062ccc@github.com>

On Tue, 20 May 2025 13:38:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?

I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2896582775

From djelinski at openjdk.org  Wed May 21 06:56:54 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 May 2025 06:56:54 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <iE3S_jMVVQoZsWnSACP4SYOv21Nba4ugsR9FKIUZfJY=.d66da97d-165d-4b33-9c8e-2a19a3b2b8a6@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 246:

> 244:         // posting a stop event, which will flip finished flag if it finishes
> 245:         // before the timeout in this method
> 246:         addEvent(new StopRequestedEvent());

post the event after setting `terminating = true`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098494315

From djelinski at openjdk.org  Wed May 21 06:56:55 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 May 2025 06:56:55 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <nHQ0_QOvqs2sqkUGvCVBcT_OyKxqZPXPCMkn36IcLB8=.28e8ba1d-cbc4-43fa-9377-596ea37d50a9@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <nHQ0_QOvqs2sqkUGvCVBcT_OyKxqZPXPCMkn36IcLB8=.28e8ba1d-cbc4-43fa-9377-596ea37d50a9@github.com>
Message-ID: <MF4-LK0x8MXSxgySy2v8h9aVaIdWr5XKHeUSrId_JQI=.be94831a-59f2-464e-a704-0f34d652b5df@github.com>

On Tue, 20 May 2025 16:24:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 252:
> 
>> 250:         selector.wakeup();
>> 251:         long latest = System.nanoTime() + delay * 1000000000L;
>> 252:         while (System.nanoTime() < latest) {
> 
> This is not correct as `latest` may overflow.
> 
> Suggestion:
> 
>         long start = System.nanoTime();
>         while ((System.nanoTime() - start) / 1000_000L < delay ) {

I suppose you could also replace `finished` with a CountDownLatch and get rid of the ugly `delay()` in a loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2098500452

From alanb at openjdk.org  Wed May 21 09:14:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 09:14:00 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <GenqNjMq792XTYWXFt9sVovHnLg1FPyvgMgF1aBWcZw=.58d69f87-44ab-4942-a0ae-73283b062ccc@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
 <WdgiUn8mvh6olrlxQrcx6whmpEpkS1inE5eg0R-tBbg=.12c5165e-6f46-4c6d-9e6e-58192116de4e@github.com>
 <GenqNjMq792XTYWXFt9sVovHnLg1FPyvgMgF1aBWcZw=.58d69f87-44ab-4942-a0ae-73283b062ccc@github.com>
Message-ID: <M2UGyXrn3TETmEqU5jsonPPXRIBb7G5faiObOA3eP1E=.26cd4672-1e58-4ddb-95e0-57460121b8a2@github.com>

On Wed, 21 May 2025 05:00:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?
> 
> I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.

Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897203363

From jpai at openjdk.org  Wed May 21 10:39:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 10:39:27 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system property
 from httpclient tests
Message-ID: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>

Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.

As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.

These tests continue to pass after this change.

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

Commit messages:
 - 8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

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

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

From vyazici at openjdk.org  Wed May 21 10:59:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 10:59:50 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <gjdJhZbs7CNFvGgEdbiptM7T1rfmw33Toc4mwyEohQw=.63ef96fd-503e-487f-b374-09b8ff0615d3@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

Verified that all `git grep tracePinnedThreads test/jdk/java/net` cases are covered.

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

Marked as reviewed by vyazici (Author).

PR Review: https://git.openjdk.org/jdk/pull/25347#pullrequestreview-2857246272

From pminborg at openjdk.org  Wed May 21 13:31:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:31:53 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v3]
In-Reply-To: <M2UGyXrn3TETmEqU5jsonPPXRIBb7G5faiObOA3eP1E=.26cd4672-1e58-4ddb-95e0-57460121b8a2@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <RRMVHZRWFdUexN34nihCDV-Aj-GwRgntNKdRSRMQcTA=.4f313106-3eee-4daa-b9dd-804d51f8eee1@github.com>
 <WdgiUn8mvh6olrlxQrcx6whmpEpkS1inE5eg0R-tBbg=.12c5165e-6f46-4c6d-9e6e-58192116de4e@github.com>
 <GenqNjMq792XTYWXFt9sVovHnLg1FPyvgMgF1aBWcZw=.58d69f87-44ab-4942-a0ae-73283b062ccc@github.com>
 <M2UGyXrn3TETmEqU5jsonPPXRIBb7G5faiObOA3eP1E=.26cd4672-1e58-4ddb-95e0-57460121b8a2@github.com>
Message-ID: <Y0JGMet3Fz5J03r8mnvTo4wU8FHc1rYMiPNI8oJdFHQ=.5537f54a-1a50-4d34-9356-e38b614f3da3@github.com>

On Wed, 21 May 2025 09:10:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment?
> > 
> > 
> > I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed.
> 
> Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests.

I've created https://bugs.openjdk.org/browse/JDK-8357466. There are some missing fields, I hope someone can fill them in.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897977877

From pminborg at openjdk.org  Wed May 21 13:38:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:38:12 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v6]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <WOTJ16EmXvYXY4MqihaKzNzRv7rfgVb1MoqxcMCRXk4=.2a8587aa-7f55-4033-b4e7-e8fd8394b0bd@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/6435f777..538147be

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

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

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

From pminborg at openjdk.org  Wed May 21 13:42:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 May 2025 13:42:39 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/538147be..d6b4233e

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

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

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

From djelinski at openjdk.org  Wed May 21 14:36:54 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 May 2025 14:36:54 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <SA2TLhPQlIa_trRYBv3Ji228YlXU5DBOwYCfvEjQJOY=.2720663c-4137-4e14-971d-7b4606c82f83@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25347#pullrequestreview-2857988193

From dfuchs at openjdk.org  Wed May 21 15:27:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 May 2025 15:27:51 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <jsfPrBMEve2GDtKy_xXTiNZ7Syzq1vEA4xUnwT6cvoY=.77e81acf-65da-4261-b092-aabbdb6c4d88@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25347#pullrequestreview-2858198020

From myankelevich at openjdk.org  Wed May 21 16:40:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:40:42 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v2]
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <bkjsOs2C0R5313A5QunSbDhk3nsgfH_McWgU_isgGeI=.ad867668-4d7a-4e75-977b-47c2f4a96c5b@github.com>

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

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

  addressing comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25333/files
  - new: https://git.openjdk.org/jdk/pull/25333/files/51fffc94..c924f793

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

  Stats: 133 lines in 3 files changed: 87 ins; 11 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25333/head:pull/25333

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

From myankelevich at openjdk.org  Wed May 21 16:40:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:40:42 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v2]
In-Reply-To: <iE3S_jMVVQoZsWnSACP4SYOv21Nba4ugsR9FKIUZfJY=.d66da97d-165d-4b33-9c8e-2a19a3b2b8a6@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <iE3S_jMVVQoZsWnSACP4SYOv21Nba4ugsR9FKIUZfJY=.d66da97d-165d-4b33-9c8e-2a19a3b2b8a6@github.com>
Message-ID: <0FGFEh6ybA7RRImP7G0Fwbq5wH3PBk5NlXkxh67y_k4=.345544f4-f3dc-464b-954b-0c1ddd6c2fd1@github.com>

On Tue, 20 May 2025 17:17:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing comments
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 246:
> 
>> 244:         // posting a stop event, which will flip finished flag if it finishes
>> 245:         // before the timeout in this method
>> 246:         addEvent(new StopRequestedEvent());
> 
> post the event after setting `terminating = true`

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100733670

From myankelevich at openjdk.org  Wed May 21 16:40:43 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:40:43 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v2]
In-Reply-To: <MF4-LK0x8MXSxgySy2v8h9aVaIdWr5XKHeUSrId_JQI=.be94831a-59f2-464e-a704-0f34d652b5df@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <nHQ0_QOvqs2sqkUGvCVBcT_OyKxqZPXPCMkn36IcLB8=.28e8ba1d-cbc4-43fa-9377-596ea37d50a9@github.com>
 <MF4-LK0x8MXSxgySy2v8h9aVaIdWr5XKHeUSrId_JQI=.be94831a-59f2-464e-a704-0f34d652b5df@github.com>
Message-ID: <_lAOxpMteSQ6Bui0rbgdflZXFsJCx8leRUsK-cRez3k=.106c2e73-17b3-4b51-8362-0a90f8eeee94@github.com>

On Tue, 20 May 2025 17:20:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 252:
>> 
>>> 250:         selector.wakeup();
>>> 251:         long latest = System.nanoTime() + delay * 1000000000L;
>>> 252:         while (System.nanoTime() < latest) {
>> 
>> This is not correct as `latest` may overflow.
>> 
>> Suggestion:
>> 
>>         long start = System.nanoTime();
>>         while ((System.nanoTime() - start) / 1000_000L < delay ) {
>
> I suppose you could also replace `finished` with a CountDownLatch and get rid of the ugly `delay()` in a loop.

Changed to the countdownlatch, so is removed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100724645

From myankelevich at openjdk.org  Wed May 21 16:40:44 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:40:44 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v2]
In-Reply-To: <YVUvQibZ3c5IJPLddQjHqqDkKCFqorYEsIPNKNjv3J8=.86c92cf1-daca-44f3-942d-b0b6499e0e5d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <YVUvQibZ3c5IJPLddQjHqqDkKCFqorYEsIPNKNjv3J8=.86c92cf1-daca-44f3-942d-b0b6499e0e5d@github.com>
Message-ID: <kxnDGG3gyrvu9tI2p-vJCqcoCl2h4fh6ef94ggUTTRs=.8b341def-bed9-4d14-9d68-6865a8cfb04f@github.com>

On Tue, 20 May 2025 16:58:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing comments
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 409:
> 
>> 407:             // termination is in progress and exchange count is 0
>> 408:             if (r instanceof StopRequestedEvent) {
>> 409:                 logger.log(Level.TRACE, "Stop event requested");
> 
> Suggestion:
> 
>                 logger.log(Level.TRACE, "Handling Stop Requested Event");

Done in the next commit

> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 411:
> 
>> 409:                 logger.log(Level.TRACE, "Stop event requested");
>> 410: 
>> 411:                 if (terminating && getExchangeCount() == 0) {
> 
> It looks like we may have to check `reqConnections.isEmpty()` here too for the case where the `ServerImpl` is configured with an executor, as it looks like the `exchangeCount` will be incremented in the executor. It would be interesting to try & craft a test with that scenario - possibly by configuring the server with an executor that sleeps some before calling `run()`, thus giving the oportunity of the `StopRequestedEvent` to be handled before the `ExchangeImpl` is created.
> 
> Also if we reach here we are terminating - so we could simply assert that.
> 
> Suggestion:
> 
>                 boolean terminating = this.terminating;
>                 assert terminating;
>                 if (getExchangeCount() == 0 && reqConnections.isEmpty()) {
> 
> 
> I suspect the other place where we set `finished = true` should also check that `reqConnections.isEmpty()` (and there we do need to check terminating).

Done in the next commit

> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 413:
> 
>> 411:                 if (terminating && getExchangeCount() == 0) {
>> 412:                     finished = true;
>> 413:                 }
> 
> Suggestion:
> 
>                 } else {
>                     logger.log(Level.TRACE, "Some requests are still pending");
>                 }

Done in the next commit

> src/jdk.httpserver/share/classes/sun/net/httpserver/StopRequestedEvent.java line 30:
> 
>> 28: /**
>> 29:  * Stopping event for the http server.
>> 30:  * Does not contain ay information about a connection.
> 
> Suggestion:
> 
>  * The event applies to the whole server and is not tied to any particular exchange.

Done in the next commit

> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 160:
> 
>> 158:         // Complete the exchange 10 second into the future.
>> 159:         // Runs in parallel, so won't block the server stop
>> 160:         final Duration exchangeDuration = Duration.ofSeconds(10);
> 
> Suggestion:
> 
>         final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

Done in the next commit

> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 190:
> 
>> 188:     public void noActiveExchanges() {
>> 189:         // With no active exchanges, shutdown should complete immediately
>> 190:         final Duration delayDuration = Duration.ofSeconds(1);
> 
> Suggestion:
> 
>         final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

Done in the next commit

> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 207:
> 
>> 205:         timeShutdown(delayDuration);
>> 206:         log("Shutting down the server the second time");
>> 207:         timeShutdown(delayDuration);
> 
> Should we check the time it took the server to shutdown here too?

This test just validates, that there is no error thrown. The other tests cover the timing scenarios

> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 238:
> 
>> 236:                     // count the latch down to allow the handler to complete
>> 237:                     // and the server's dispatcher thread to proceed; The handler
>> 238:                     // is called withing the dispatcher thread since we haven't
> 
> Suggestion:
> 
>                     // is called within the dispatcher thread since we haven't

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100728907
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100724961
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100730146
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100729880
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100730296
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100730441
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100732198
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100732503

From myankelevich at openjdk.org  Wed May 21 16:50:28 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:50:28 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v3]
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <txG7PhbwpNKOsk_Kmv02S7xv4knUwUijATiufU3z_rA=.4c6bbfa9-90a8-4af3-82b8-f1ae454e98d0@github.com>

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

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

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25333/files
  - new: https://git.openjdk.org/jdk/pull/25333/files/c924f793..54def0da

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

  Stats: 32 lines in 2 files changed: 8 ins; 7 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25333/head:pull/25333

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

From myankelevich at openjdk.org  Wed May 21 16:50:28 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 21 May 2025 16:50:28 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v3]
In-Reply-To: <H3BSWv4UDnl-zhf1P5G6MfeDypqQaK9VDQzeurBB9Eo=.eed4b926-ad2a-4b90-94ce-95f03381a656@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <H3BSWv4UDnl-zhf1P5G6MfeDypqQaK9VDQzeurBB9Eo=.eed4b926-ad2a-4b90-94ce-95f03381a656@github.com>
Message-ID: <R7GNJzCvWi9tLSiYreDSNd-i7AO44cdvr1S8rqpwYQA=.31005e75-7b54-44f1-a88a-0027ec892593@github.com>

On Tue, 20 May 2025 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 128:
> 
>> 126: 
>> 127:         // Time the shutdown sequence
>> 128:         final Duration delayDuration = Duration.ofSeconds(2);
> 
> We should use a greater margin here since we're not expecting to wait for that duration, and probably use `Utils.adjustTimeout()` too. I'd suggest something like:
> 
> Suggestion:
> 
>         final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

done in the next commit

> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 228:
> 
>> 226:                 .uri(URI.create("http://"
>> 227:                                 + server.getAddress().getAddress().getHostAddress()
>> 228:                                 + ":" + server.getAddress().getPort() + "/"))
> 
> We should use `URIBuilder` here to take care of IPv4 vs IPv6 etc...

done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100751630
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2100751035

From valeriep at openjdk.org  Wed May 21 17:57:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 21 May 2025 17:57:53 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <lzJg1sV-u4HD60jpBBDLlUWKBYsM8PQA75M7skqrrPM=.5f9807b3-ec55-409a-b61e-9411d6157508@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <lzJg1sV-u4HD60jpBBDLlUWKBYsM8PQA75M7skqrrPM=.5f9807b3-ec55-409a-b61e-9411d6157508@github.com>
Message-ID: <PuiQWL7tMhmqiTV9Vt9XuATGqu8bkCOoqoK-7ipcAbg=.d86ecbf8-a8a6-4790-9ad6-f7fcb75a53a1@github.com>

On Tue, 20 May 2025 11:01:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
> 
>> 457: 
>> 458:             boolean pending = false;
>> 459:             NIO_ACCESS.acquireSession(buf);
> 
> Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.

Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2100870190

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

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

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

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

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

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

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From syan at openjdk.org  Thu May 22 06:13:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 06:13:50 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <aEWvGTjGtmrJOgAluV9sTE5zsH1cljhzBw3KuDPopyo=.9b8ee59d-ba5e-4354-b979-4b547150e1f5@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

LGTM

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25347#pullrequestreview-2859903402

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

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

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

From djelinski at openjdk.org  Thu May 22 09:58:28 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 May 2025 09:58:28 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic
Message-ID: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>

We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.

The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.

No new test; instrumenting this class for testing would likely double its size.

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

Commit messages:
 - Ensure that delay is used with the correct timesource

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

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

From dfuchs at openjdk.org  Thu May 22 10:11:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 May 2025 10:11:57 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic
In-Reply-To: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
Message-ID: <dYkc2YJFpyMzOD3qkCBmGQqvSoOAL5BfPM494UEzzyM=.19449343-2c48-4862-825a-e6d6f26a15df@github.com>

On Thu, 22 May 2025 09:53:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
> 
> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
> 
> No new test; instrumenting this class for testing would likely double its size.

src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 85:

> 83: 
> 84:         boolean isInWindow(long delay) {
> 85:             return delay >= -TIME_WINDOW && delay <= TIME_WINDOW;

OK

src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 97:

> 95:         // use localSource if possible to avoid a volatile read
> 96:         if (source.isInWindow(delay)) {
> 97:             return source.instant(nanos);

I would keep the two args intant() method which avoids computing the delay twice. Using a local variable `source` in this method should be enough to solve the bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102158627
PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102153039

From jpai at openjdk.org  Thu May 22 10:38:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:38:53 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic
In-Reply-To: <dYkc2YJFpyMzOD3qkCBmGQqvSoOAL5BfPM494UEzzyM=.19449343-2c48-4862-825a-e6d6f26a15df@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <dYkc2YJFpyMzOD3qkCBmGQqvSoOAL5BfPM494UEzzyM=.19449343-2c48-4862-825a-e6d6f26a15df@github.com>
Message-ID: <0iVhgxeaI2FvwrlHpwgSL_dpQ3L_5yG7bj5qntzXL8s=.a1bb137c-cf6e-4d1a-86cd-2190c29c1d0d@github.com>

On Thu, 22 May 2025 09:59:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size.
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 97:
> 
>> 95:         // use localSource if possible to avoid a volatile read
>> 96:         if (source.isInWindow(delay)) {
>> 97:             return source.instant(nanos);
> 
> I would keep the two args intant() method which avoids computing the delay twice. Using a local variable `source` in this method should be enough to solve the bug.

Hello Daniel, with this proposed change, is there any reason to have the `localSource` field in this `TimeSource` anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102234265

From jpai at openjdk.org  Thu May 22 10:46:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:46:55 GMT
Subject: RFR: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <GMJ0V5lto-KrhvhZyV6d75sq_K-pSMJ5kK6FqUBOFNk=.5e750293-e440-49e2-a0b4-90032d1d7fe8@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25347#issuecomment-2900754279

From jpai at openjdk.org  Thu May 22 10:46:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:46:56 GMT
Subject: Integrated: 8357406: Remove usages of jdk.tracePinnedThreads system
 property from httpclient tests
In-Reply-To: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
References: <S5o73HYH7jgojfIbpJazQJtEy3tjuZ1wACIUpTv5yms=.26959733-ce10-4bbe-9178-ab0738b12269@github.com>
Message-ID: <2vWWZc05-r-ULo95TN3KZlD7h4FJEbSbUeDXDzwPc8A=.b1809539-ad1a-480b-b27b-03da845926ce@github.com>

On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes the usage of the outdated `jdk.tracePinnedThreads` system property from the httpclient tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
> 
> As noted in the linked issue, this system property is no longer supported by the Virtual Threads implementation in the JDK.
> 
> These tests continue to pass after this change.

This pull request has now been integrated.

Changeset: 26053fe7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26053fe78322940113629ee1bd72077f25e4be3e
Stats:     30 lines in 7 files changed: 0 ins; 14 del; 16 mod

8357406: Remove usages of jdk.tracePinnedThreads system property from httpclient tests

Reviewed-by: vyazici, djelinski, dfuchs, syan

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

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

From dfuchs at openjdk.org  Thu May 22 10:55:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 May 2025 10:55:03 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic
In-Reply-To: <0iVhgxeaI2FvwrlHpwgSL_dpQ3L_5yG7bj5qntzXL8s=.a1bb137c-cf6e-4d1a-86cd-2190c29c1d0d@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <dYkc2YJFpyMzOD3qkCBmGQqvSoOAL5BfPM494UEzzyM=.19449343-2c48-4862-825a-e6d6f26a15df@github.com>
 <0iVhgxeaI2FvwrlHpwgSL_dpQ3L_5yG7bj5qntzXL8s=.a1bb137c-cf6e-4d1a-86cd-2190c29c1d0d@github.com>
Message-ID: <br-LX3WkzVD4aEagoTTzm10DAdC06-4uWBN7E28NnEI=.88bb8a19-46cf-43de-a1b4-43fe4b46de91@github.com>

On Thu, 22 May 2025 10:35:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 97:
>> 
>>> 95:         // use localSource if possible to avoid a volatile read
>>> 96:         if (source.isInWindow(delay)) {
>>> 97:             return source.instant(nanos);
>> 
>> I would keep the two args intant() method which avoids computing the delay twice. Using a local variable `source` in this method should be enough to solve the bug.
>
> Hello Daniel, with this proposed change, is there any reason to have the `localSource` field in this `TimeSource` anymore?

Yes. It avoids the volatile read on nanoSource.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102262966

From dfuchs at openjdk.org  Thu May 22 11:24:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 May 2025 11:24:58 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v3]
In-Reply-To: <txG7PhbwpNKOsk_Kmv02S7xv4knUwUijATiufU3z_rA=.4c6bbfa9-90a8-4af3-82b8-f1ae454e98d0@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <txG7PhbwpNKOsk_Kmv02S7xv4knUwUijATiufU3z_rA=.4c6bbfa9-90a8-4af3-82b8-f1ae454e98d0@github.com>
Message-ID: <fWSZoIB0j2DQ8I72i8XZM6g96mzDaCVo6sYZ_QWw7Zc=.50105803-2dbc-4f85-8179-9dc905e6856b@github.com>

On Wed, 21 May 2025 16:50:28 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 228:

> 226: 
> 227:     public final boolean isFinishing() {
> 228:         return finishedLatch.getCount()==0;

Suggestion:

        return finishedLatch.getCount() == 0;

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 238:

> 236:      * but still stops as soon as maximum delay is reached.
> 237:      *
> 238:      * @param delay maximum delay in stopping the server

Suggestion:

     * This ensures that the server is stopped immediately after all exchanges are complete. HttpConnections will be forcefully closed if active exchanges do not
     * complete within the imparted delay.
     *
     * @param delay maximum delay to wait for exchanges completion, in seconds

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 489:

> 487: 
> 488:         public void run() {
> 489:              while (!isFinishing()) {

The name of the method is not great - but since it's pre-existing I'm OK with that.

Suggestion:

            // isFinishing() will be true when there are no active exchange after terminating
             while (!isFinishing()) {

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 164:

> 162:         // Complete the exchange 10 second into the future.
> 163:         // Runs in parallel, so won't block the server stop
> 164:         final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(5));

Let's use 10 since we're speaking about 10s everywhere. It doesn't really matter since we should finish way before 10 (unless the bug is present).

Suggestion:

        final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(10));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2102283879
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2102290292
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2102302993
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2102312019

From myankelevich at openjdk.org  Thu May 22 12:27:46 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 22 May 2025 12:27:46 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

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

  Suggestions from cr
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25333/files
  - new: https://git.openjdk.org/jdk/pull/25333/files/54def0da..5a879107

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

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

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

From nbenalla at openjdk.org  Thu May 22 15:18:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 22 May 2025 15:18:43 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

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

  revert changes to MethodType.java. <code>foo</code> markup should not be used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25287/files
  - new: https://git.openjdk.org/jdk/pull/25287/files/b17b55fa..0653af94

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

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

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

From djelinski at openjdk.org  Thu May 22 15:53:52 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 May 2025 15:53:52 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic
In-Reply-To: <br-LX3WkzVD4aEagoTTzm10DAdC06-4uWBN7E28NnEI=.88bb8a19-46cf-43de-a1b4-43fe4b46de91@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <dYkc2YJFpyMzOD3qkCBmGQqvSoOAL5BfPM494UEzzyM=.19449343-2c48-4862-825a-e6d6f26a15df@github.com>
 <0iVhgxeaI2FvwrlHpwgSL_dpQ3L_5yG7bj5qntzXL8s=.a1bb137c-cf6e-4d1a-86cd-2190c29c1d0d@github.com>
 <br-LX3WkzVD4aEagoTTzm10DAdC06-4uWBN7E28NnEI=.88bb8a19-46cf-43de-a1b4-43fe4b46de91@github.com>
Message-ID: <l4HNy3bV9Moa4StsAKuiFIL7B_xo3czY-ZKAZXoMNPE=.d72841e8-e6cc-4c3f-ab5f-056f035a9f20@github.com>

On Thu, 22 May 2025 10:52:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello Daniel, with this proposed change, is there any reason to have the `localSource` field in this `TimeSource` anymore?
>
> Yes. It avoids the volatile read on nanoSource.

It could serve as a safety net. But I can also revert this and add the assert mentioned in the PR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102888330

From liach at openjdk.org  Thu May 22 18:24:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:24:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
Message-ID: <2NivjYQr_KiIrdCorX_x68nTNHezBA1qKvhjaDknI1E=.5da267a6-125d-49bf-9de3-4eaf9afbfcd6@github.com>

On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MethodType.java. <code>foo</code> markup should not be used

Changes to MethodHandles look good. Please wait for a review from security developers for KEM.java.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2862198182

From djelinski at openjdk.org  Thu May 22 18:56:29 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 May 2025 18:56:29 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v2]
In-Reply-To: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
Message-ID: <RnDWZbFwtNb350IRc4LR3xME56ArkEInQ7yEX1YU5qc=.fc21ee65-6905-4638-ae1e-7d9595cb051e@github.com>

> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
> 
> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
> 
> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Restore instant(long,long)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25390/files
  - new: https://git.openjdk.org/jdk/pull/25390/files/bd5e4619..a16404aa

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

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

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

From valeriep at openjdk.org  Thu May 22 18:57:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 22 May 2025 18:57:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <PuiQWL7tMhmqiTV9Vt9XuATGqu8bkCOoqoK-7ipcAbg=.d86ecbf8-a8a6-4790-9ad6-f7fcb75a53a1@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <lzJg1sV-u4HD60jpBBDLlUWKBYsM8PQA75M7skqrrPM=.5f9807b3-ec55-409a-b61e-9411d6157508@github.com>
 <PuiQWL7tMhmqiTV9Vt9XuATGqu8bkCOoqoK-7ipcAbg=.d86ecbf8-a8a6-4790-9ad6-f7fcb75a53a1@github.com>
Message-ID: <G16vWKYsUXOQGiHeuCkBDp_MS13mmJdqN6u0DFx2I6U=.98a972cc-3773-48b3-9fcb-96e8f3b62171@github.com>

On Wed, 21 May 2025 17:55:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
>> 
>>> 457: 
>>> 458:             boolean pending = false;
>>> 459:             NIO_ACCESS.acquireSession(buf);
>> 
>> Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown.
>
> Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these.

Never mind, I see that there are already acquireSession/releaseSession calls when the ByteBuffer objects are accessed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2103213937

From valeriep at openjdk.org  Thu May 22 18:57:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 22 May 2025 18:57:51 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
Message-ID: <KmLzzPbilhsF0BGHuOcg3ahDiLGl9c_rI4JyPdltmTs=.6c3d252a-967b-408e-9683-d9035efc116c@github.com>

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

Security source changes look fine.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2862279408

From dfuchs at openjdk.org  Thu May 22 20:16:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 May 2025 20:16:51 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v2]
In-Reply-To: <RnDWZbFwtNb350IRc4LR3xME56ArkEInQ7yEX1YU5qc=.fc21ee65-6905-4638-ae1e-7d9595cb051e@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <RnDWZbFwtNb350IRc4LR3xME56ArkEInQ7yEX1YU5qc=.fc21ee65-6905-4638-ae1e-7d9595cb051e@github.com>
Message-ID: <vWuKFhen0FZrCMLxHim6MHl-2lhyEQX1_TN11-wZAlg=.7a219e0c-99a5-43f7-b28c-2d1d215019cc@github.com>

On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore instant(long,long)

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25390#pullrequestreview-2862461160

From wetmore at openjdk.org  Thu May 22 20:47:29 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 22 May 2025 20:47:29 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v25]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <xNWt-27maG6IGEpd2N0KyRHQfll9E6YBZpBt0hAWpwc=.4ee511d5-38f5-4403-bd59-a794db4af97e@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8341346
 - Added PKCS11 testing
 - Minor bug
 - Missed one change
 - Merge branch 'master' into JDK-8341346
 - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
 - get*() no longer needed, backout error (oops!)
 - Merge branch 'master' into JDK-8341346
 - Updated copyright dates.
 - Merge branch 'master' into JDK-8341346
 - ... and 24 more: https://git.openjdk.org/jdk/compare/139a05d0...e6b563e7

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=24
  Stats: 1023 lines in 9 files changed: 1001 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From jpai at openjdk.org  Fri May 23 05:18:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 May 2025 05:18:54 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v2]
In-Reply-To: <RnDWZbFwtNb350IRc4LR3xME56ArkEInQ7yEX1YU5qc=.fc21ee65-6905-4638-ae1e-7d9595cb051e@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <RnDWZbFwtNb350IRc4LR3xME56ArkEInQ7yEX1YU5qc=.fc21ee65-6905-4638-ae1e-7d9595cb051e@github.com>
Message-ID: <MMgw64DhoiwM-zM3okNHXDdcKqxrqgpzAY8b_q3rxJM=.ec1169f1-ce2f-4406-b290-f97251c4d82b@github.com>

On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore instant(long,long)

src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 100:

> 98:         long nanos = System.nanoTime();
> 99:         long delay = source.delay(nanos);
> 100:         // use localSource if possible to avoid a volatile read

Hello Daniel, the changes look OK to me. However, this pre-existing comment is now misplaced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2103819574

From djelinski at openjdk.org  Fri May 23 06:14:37 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 May 2025 06:14:37 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v3]
In-Reply-To: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
Message-ID: <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>

> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
> 
> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
> 
> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Move localSource comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25390/files
  - new: https://git.openjdk.org/jdk/pull/25390/files/a16404aa..5844e89f

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

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

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

From jpai at openjdk.org  Fri May 23 06:14:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 May 2025 06:14:37 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v3]
In-Reply-To: <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
Message-ID: <4ByOcFoRogeOQrQWQrWSKvnv2hrGua7ZEKRNlodqPvg=.13df43a7-7d8f-4f04-a7c0-19839cdc0aac@github.com>

On Fri, 23 May 2025 06:11:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move localSource comment

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25390#pullrequestreview-2863305218

From dfuchs at openjdk.org  Fri May 23 07:52:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 May 2025 07:52:51 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v3]
In-Reply-To: <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
Message-ID: <vibrnXnRj79I7kmxA8xTeekGiRNR0_vc4OyzB1Sld0s=.04b70e5b-f614-46c7-b5d7-bd2175cd6d67@github.com>

On Fri, 23 May 2025 06:14:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move localSource comment

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25390#pullrequestreview-2863538330

From msheppar at openjdk.org  Fri May 23 08:52:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 23 May 2025 08:52:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
Message-ID: <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>

On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from cr
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

If I have read the original code correctly there is a flaw in it, that is the startExchange is never called.
Thus the code in handleEvent won?t executed as anticipated

 391                     int exchanges = endExchange();              
 392                     if (terminating && exchanges == 0) {
 393                         finished = true;
 394                     }

Exchanges will always be negative. This is inherited in the new update

WRT current PR, I don't think it is good that the state of the server is encapsulated in the state of the CountDownLatch.
The use of the CountDownLatch to synchronise the stop and the Dispatcher shutdown is fine, but having the server state encapsulated in the CountDownLatch value is a bit oblique or obfuscating. I think the original volatile boolean variable is a clearer semantics

I would make stop synchronised to have only one thread executing at time. First check on entry then becomes test on the server's current state. This means that this state management needs some attention.

The addition of Stop event is a neat idea, but draws attention to the semantics of the stop. What is the desired semantics of stop, to not accept any new connections, i.e. stop the listener immediately, not accept new requests on existing connections. To allow existing Exchanges to complete and then shutdown all extant connections.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 227:

> 225:     }
> 226: 
> 227:     public final boolean isFinishing() {

encapsulating the server state in a CountDoenLatch is obfuscated semantics

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2903739980
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104135665

From myankelevich at openjdk.org  Fri May 23 08:57:54 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 23 May 2025 08:57:54 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
Message-ID: <UAp_sUEXczbC6oc6m48yHBYYcs6ktEektwPHt9WUAWI=.4c65e049-58d9-474f-bd19-f9337040204d@github.com>

On Fri, 23 May 2025 08:50:11 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestions from cr
>>   
>>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 227:
> 
>> 225:     }
>> 226: 
>> 227:     public final boolean isFinishing() {
> 
> encapsulating the server state in a CountDoenLatch is obfuscated semantics

Yes, but this is an existing function and it is used in other classes. I didn't change the functionality

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104143995

From msheppar at openjdk.org  Fri May 23 08:57:55 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 23 May 2025 08:57:55 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
Message-ID: <887WIHZXRIeXMo-N7zIRyHg4DAqO3s9rKikSMZLpzZQ=.3e26cb3b-c33c-4abe-b4de-c626ec5adaf0@github.com>

On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from cr
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 241:

> 239:      */
> 240:     public void stop (int delay) {
> 241:         if (delay < 0) {

with the use of CountDownLatch the negative check becomes superfluous i.e.

public boolean await(long timeout, TimeUnit unit) throws InterruptedException
Causes the current thread to wait until the latch has counted down to zero, unless the thread is interrupted, or the specified waiting time elapses.

. . . 
If the specified waiting time elapses then the value false is returned. If the time is less than or equal to zero, the method will not wait at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104144945

From msheppar at openjdk.org  Fri May 23 09:02:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 23 May 2025 09:02:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
Message-ID: <TjbkePUwdbMZI3gEuA9jfBaJ9dvmgZr-iwwPlDbdZhg=.4a488823-d41e-4c14-8c75-634ffc031533@github.com>

On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from cr
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 239:

> 237:      *
> 238:      * @param delay maximum delay to wait for exchanges completion, in seconds
> 239:      */

make synchronised to allow only one thread to execute stop at any one time

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 437:

> 435: 
> 436:                     logger.log(Level.TRACE, "Write Finished");
> 437:                     int exchanges = endExchange();

startExchange is never called => endExchange can return negative ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104154820
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104153198

From msheppar at openjdk.org  Fri May 23 09:10:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 23 May 2025 09:10:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <UAp_sUEXczbC6oc6m48yHBYYcs6ktEektwPHt9WUAWI=.4c65e049-58d9-474f-bd19-f9337040204d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
 <UAp_sUEXczbC6oc6m48yHBYYcs6ktEektwPHt9WUAWI=.4c65e049-58d9-474f-bd19-f9337040204d@github.com>
Message-ID: <RIcQcefaXNrUoyB_Nbiz0llVBdA7PmUlCCD2gTEPhwE=.0381958b-32f3-4ca5-af27-a59e201455ba@github.com>

On Fri, 23 May 2025 08:54:42 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 227:
>> 
>>> 225:     }
>>> 226: 
>>> 227:     public final boolean isFinishing() {
>> 
>> encapsulating the server state in a CountDownLatch is obfuscated semantics
>
> Yes, but this is an existing function and it is used in other classes. I didn't change the functionality

the internal state representation of the server could do with a rethink and overhaul, and representing part of that state in a synchronisation primitive obscures/obfuscates the server state's semantics. I don't think it's "clean code"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104166994

From dfuchs at openjdk.org  Fri May 23 09:55:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 May 2025 09:55:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <RIcQcefaXNrUoyB_Nbiz0llVBdA7PmUlCCD2gTEPhwE=.0381958b-32f3-4ca5-af27-a59e201455ba@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
 <UAp_sUEXczbC6oc6m48yHBYYcs6ktEektwPHt9WUAWI=.4c65e049-58d9-474f-bd19-f9337040204d@github.com>
 <RIcQcefaXNrUoyB_Nbiz0llVBdA7PmUlCCD2gTEPhwE=.0381958b-32f3-4ca5-af27-a59e201455ba@github.com>
Message-ID: <tHGgK-uqtqzk_XWkeJ3ZSVb6d4v4qf5NbZLp66cMvbs=.5f4b0406-c06f-4a64-b0c0-b49f5805eb82@github.com>

On Fri, 23 May 2025 09:07:51 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Yes, but this is an existing function and it is used in other classes. I didn't change the functionality
>
> the internal state representation of the server could do with a rethink and overhaul, and representing part of that state in a synchronisation primitive obscures/obfuscates the server state's semantics. I don't think it's "clean code"

I agree that the semantic of `finished` `finishing`  is a bit obfuscated. On the other hand I don't think we should go so far as overhauling / rethinking the states in this PR. If you recall there have been lots of fixes in this area (we had some `assert` firing at some point, and it took some time to find the root cause and fix).
That said having both a boolean *and* a countdown latch would be duplicate info, and potentially harder to manage consistency. 
If we don't want the countdown latch we might go back to looping with Thread.sleep in stop, or use wait/notify, and I am not sure it would be much better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104238253

From dfuchs at openjdk.org  Fri May 23 09:55:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 May 2025 09:55:55 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <TjbkePUwdbMZI3gEuA9jfBaJ9dvmgZr-iwwPlDbdZhg=.4a488823-d41e-4c14-8c75-634ffc031533@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <TjbkePUwdbMZI3gEuA9jfBaJ9dvmgZr-iwwPlDbdZhg=.4a488823-d41e-4c14-8c75-634ffc031533@github.com>
Message-ID: <0vHsUAc7OYewwPdnaJ6l6Orv6ZJhXh90qUDRSXsNpzo=.edf99096-659a-4aa2-9738-dfaeb833e09d@github.com>

On Fri, 23 May 2025 09:00:39 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestions from cr
>>   
>>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 239:
> 
>> 237:      *
>> 238:      * @param delay maximum delay to wait for exchanges completion, in seconds
>> 239:      */
> 
> make synchronised to allow only one thread to execute stop at any one time

Not sure that's the best solution. But if the `terminating` flag is already set then it means that another thread has initiated stop, and maybe in this case we should just jump to waiting on the latch - no need to post the event again or close the channel and wakeup the selector again. The part in `stop` that need synchronization already have it, so I don't think declaring stop as synchronized would be such a good idea. In particular it would prevent other threads to call getExchange() / endExchange() so I would be afraid it would prevent active exchanges from proceeding - unless we use wait/notify instead of a countdown latch - but that might be even more difficult to get right.

> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 241:
> 
>> 239:      */
>> 240:     public void stop (int delay) {
>> 241:         if (delay < 0) {
> 
> with the use of CountDownLatch the negative check becomes superfluous i.e.
> 
> public boolean await(long timeout, TimeUnit unit) throws InterruptedException
> Causes the current thread to wait until the latch has counted down to zero, unless the thread is interrupted, or the specified waiting time elapses.
> 
> . . . 
> If the specified waiting time elapses then the value false is returned. If the time is less than or equal to zero, the method will not wait at all.

It's not something we should change though, as it's part of the API contract in `HttpServer::stop`:
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#stop(int)

> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 437:
> 
>> 435: 
>> 436:                     logger.log(Level.TRACE, "Write Finished");
>> 437:                     int exchanges = endExchange();
> 
> startExchange is never called => endExchange can return negative ?

I hope that this is a scenario that cannot happen: to end an exchange you would have to start it first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104221149
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104204781
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2104206439

From dfuchs at openjdk.org  Fri May 23 10:00:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 May 2025 10:00:06 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
Message-ID: <4Ev9yIx28Oiz5gDMdsq4zpkXB8NTFVdD_IW7GA63TkE=.e52833ad-9a38-4176-bdf7-58f28eaea02c@github.com>

On Fri, 23 May 2025 08:48:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> If I have read the original code correctly there is a flaw in it, that is the startExchange is never called.

@msheppar what do you mean by that? It's called in [ExchangeImpl.java](https://github.com/openjdk/jdk/blob/68ee06f0c9ec420cb1a60e0b361971372b18b82b/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L98)

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2903915506

From djelinski at openjdk.org  Fri May 23 11:58:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 May 2025 11:58:04 GMT
Subject: RFR: 8357539: TimeSource.now() is not monotonic [v3]
In-Reply-To: <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
 <NEcCfaKqC84IpoTYgfyXk8zKmJHpwOQNXd1vRroy8-s=.2151c4fa-a405-462a-a80b-b86fc41b7eaa@github.com>
Message-ID: <Zgi1h-7_rUrOTMsqCKoBwl2gxrcyp8xuApJubWqvjQg=.b37c9df0-c1d3-4ada-a2d4-26b5ae79fcf8@github.com>

On Fri, 23 May 2025 06:14:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>> 
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>> 
>> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move localSource comment

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25390#issuecomment-2904180546

From djelinski at openjdk.org  Fri May 23 11:58:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 May 2025 11:58:05 GMT
Subject: Integrated: 8357539: TimeSource.now() is not monotonic
In-Reply-To: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
References: <njIqwsHHYn8aaTnVPHngJ2WbQiuWf_rjf8NbqnADkdc=.8d7e6829-443a-4096-88e2-c56b3357a103@github.com>
Message-ID: <GVVxg2D8fD6XHNQsJbpFdQo0n9XCm9Mz-XczykiEeQU=.1370e281-1fbd-47d7-98e8-0b25b187eb63@github.com>

On Thu, 22 May 2025 09:53:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
> 
> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
> 
> No new test; instrumenting this class for testing would likely double its size. Tier2 tests continue to pass.

This pull request has now been integrated.

Changeset: 488e4ea5
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/488e4ea5c6bc47be1d777bf5c26e2ffa2c436e28
Stats:     11 lines in 1 file changed: 5 ins; 2 del; 4 mod

8357539: TimeSource.now() is not monotonic

Reviewed-by: dfuchs, jpai

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

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

From msheppar at openjdk.org  Fri May 23 13:35:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 23 May 2025 13:35:54 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <4Ev9yIx28Oiz5gDMdsq4zpkXB8NTFVdD_IW7GA63TkE=.e52833ad-9a38-4176-bdf7-58f28eaea02c@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
 <4Ev9yIx28Oiz5gDMdsq4zpkXB8NTFVdD_IW7GA63TkE=.e52833ad-9a38-4176-bdf7-58f28eaea02c@github.com>
Message-ID: <6o6vUuNq0q1y3dUYcZzkUL9Arw7yHSke9gSDbJdp1c0=.dd2528a6-aedb-4fde-a532-50efaad178a5@github.com>

On Fri, 23 May 2025 09:57:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > If I have read the original code correctly there is a flaw in it, that is the startExchange is never called.
> 
> @msheppar what do you mean by that? It's called in [ExchangeImpl.java](https://github.com/openjdk/jdk/blob/68ee06f0c9ec420cb1a60e0b361971372b18b82b/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L98)

Well then I haven't read it correctly :-(  needs a deeper dive, I didn't examine the Exchange::run method in sufficient detail   ... thanks for the correction ....  BUT in my defence I see Dispatcher invoke handle, handle creates an Exchange, which is dispatched to an Executor and I would have expected that the run method of Exchange to call startExchange, as the log message says an exchange has started !!

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2904441249

From weijun at openjdk.org  Fri May 23 14:31:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 May 2025 14:31:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
Message-ID: <G8BGDogNzuXV8dPOHCFAIFiAt5Ppv5g6FAhb7-OyXKE=.57ac67b7-5c7a-48b0-8c7b-366b80ee67d3@github.com>

On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MethodType.java. <code>foo</code> markup should not be used

src/java.base/share/classes/javax/crypto/KEM.java line 711:

> 709:      * with the key encapsulation message so that the receiver is able to create
> 710:      * a matching decapsulator, it will be included as a byte array in the
> 711:      * {@link Encapsulated#params()} field inside the encapsulation output.

Good catch. The text must have been added before we changed `Encapsulated` from a record to a normal class. Now that `params` is a method instead of a record field, please consider rewriting the sentence to something like

it will be included as a byte array returned by the
{@link Encapsulated#params()} method within the
encapsulation output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2104718909

From dfuchs at openjdk.org  Fri May 23 14:40:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 May 2025 14:40:26 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool
Message-ID: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>

The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.

Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.

The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.

To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

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

Commit messages:
 - 8357639

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

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

From nbenalla at openjdk.org  Fri May 23 14:59:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 23 May 2025 14:59:07 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

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

  update javadoc based on feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25287/files
  - new: https://git.openjdk.org/jdk/pull/25287/files/0653af94..daaed6c5

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

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

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

From weijun at openjdk.org  Fri May 23 15:06:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 May 2025 15:06:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
Message-ID: <Dj7UqhJjXhFazTIjAIQcGFMSSevKeDpFYnpMWeLChu0=.3e17720c-c152-4dac-97b6-6ae7a60d5137@github.com>

On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc based on feedback

The `KEM.java` change looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2864755280

From Shruthi.Shruthi1 at ibm.com  Fri May 23 12:57:52 2025
From: Shruthi.Shruthi1 at ibm.com (Shruthi .)
Date: Fri, 23 May 2025 12:57:52 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11S
In-Reply-To: <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663E34342AC2F9AC8A876AACCFC2@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <cb761fa6-3b2e-4752-846d-3a7ff28861ae@oracle.com>
 <SJ0PR15MB4663D70B7F45120E4B75956DCCC62@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB4663242E65CB63DD64272DE0CCC32@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <2633ad7f-c278-4f88-bcbc-ec8211d7ee48@oracle.com>
 <SJ0PR15MB46631AD45E4B42C4A39F008DCCC22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ef07a775-f954-4051-a0e9-59100c7715c3@oracle.com>
 <SJ0PR15MB46638A0DE787D32EFABAA8E1CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ec39b10b-5271-41cf-aa7f-d3f915ee0a18@oracle.com>
 <SJ0PR15MB4663123A5C03544060DC27E9CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <8861a349-6446-4326-b168-e9594aeef70b@oracle.com>
 <SJ0PR15MB4663C04ADCBC69EFEF78C71CCCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <d79fdfb8-e717-4c73-8c0c-3fae0fadce01@oracle.com>
 <SJ0PR15MB4663218DFB930F6B6EF9F211CCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
 <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <SJ0PR15MB466351A414A67F29EC88EC19CC98A@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan,
I was able to backport the preClose re-order changes to JDK17 and I executed the Race.java testcase 500 times, and it passed consistently  without any failures.
I also tested Race.java without the patch and it fails in the first iteration it self.
We are running the tests under java/net and java/nio to check if there is any regression. Do you think I should run any other tests?
Also, can we proceed with porting preClose re-order fix to headstream?

Thanks
Shruthi
________________________________
From: Shruthi . <Shruthi.Shruthi1 at ibm.com>
Sent: Tuesday, April 8, 2025 6:03 PM
To: Alan Bateman <alan.bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: Re: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

Hi Alan,

I was able to successfully build the OpenJDK headstream with the preClose reordering patch, which you have shared: pending_signals.patch<https://bugs.openjdk.org/secure/attachment/113740/pending_signals.patch>.
To validate the build, I executed the Race.java testcase 500 times, and it passed consistently without any failures.
For comparison, I ran the same testcase without the patch, and it failed on the 86th iteration.

Thanks
Shruthi
________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Friday, March 14, 2025 3:00 PM
To: Shruthi . <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

On 14/03/2025 09:?22, Shruthi . wrote: The issue which we are seeing is not reproducible in JDK21 or higher version Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that

On 14/03/2025 09:22, Shruthi . wrote:
The issue which we are seeing is not reproducible in JDK21 or higher version

Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that would help you reproduce it with main line.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250523/4678d3f4/attachment.htm>

From wetmore at openjdk.org  Fri May 23 21:23:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 23 May 2025 21:23:04 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
 - Merge branch 'master' into JDK-8341346
 - Merge branch 'master' into JDK-8341346
 - Added PKCS11 testing
 - Minor bug
 - Missed one change
 - Merge branch 'master' into JDK-8341346
 - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
 - get*() no longer needed, backout error (oops!)
 - Merge branch 'master' into JDK-8341346
 - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=25
  Stats: 1022 lines in 9 files changed: 1000 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From alanb at openjdk.org  Mon May 26 07:35:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 07:35:18 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
Message-ID: <LwUblpznblLF1Sa4fUchmpMH0CK-kVoZfmlzBgsg15w=.da1ec0ca-9fc4-46d5-94fa-11909c1e06ef@github.com>

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 169:

> 167:         int rem = (pos <= lim ? lim - pos : 0);
> 168: 
> 169:         if (dst instanceof sun.nio.ch.DirectBuffer) {

I assume this can be changed to test dst.isDirect() now and avoid the explicit cross package dependency.

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 41:

> 39: import jdk.internal.invoke.MhUtil;
> 40: 
> 41: import static sun.nio.ch.Util.NIO_ACCESS;

I assume this is left over from a previous iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106733233
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106735489

From alanb at openjdk.org  Mon May 26 08:16:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 08:16:09 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
Message-ID: <Vwoq-RzYoyYkSw4vydZ3LdK8y1XTuQqgnAHlZ4qmGR0=.213e91da-9b6b-49a6-b91d-d7b355394452@github.com>

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:

> 457: 
> 458:             boolean pending = false;
> 459:             IOUtil.acquireScope(buf, true);

Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 575:

> 573:             case 2 -> Arena.ofAuto().allocate(buf.length).asByteBuffer()
> 574:                     .put(buf)
> 575:                     .flip();

I wonder if we could extend this to test with a shared arena too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106767298
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106771546

From michaelm at openjdk.org  Mon May 26 10:31:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 May 2025 10:31:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=10
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Mon May 26 10:59:54 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 May 2025 10:59:54 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <UlE7BVp40zqH-ioNN2abdsJOi6NQBp0rjfBgEAuN3Ok=.19aea016-c438-4135-ad8f-5bea8030ebfb@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

I think this change is fine as it is.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25097#pullrequestreview-2868039046

From duke at openjdk.org  Mon May 26 11:06:52 2025
From: duke at openjdk.org (duke)
Date: Mon, 26 May 2025 11:06:52 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <XpvhXFzyW9VPRtUJzpIhoFkagLD_Dm4bzEabW-QqfDU=.69a0bb0b-3877-4f2b-a912-6503d972a598@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

@kieran-farrell 
Your change (at version 6f12e2b0dda658c1290f4c712ca1f063ccac8f69) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25097#issuecomment-2909334359

From jpai at openjdk.org  Mon May 26 11:15:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 May 2025 11:15:57 GMT
Subject: RFR: 7046003: Default value of Authenticator.getRequestingURL() is
 not specified [v2]
In-Reply-To: <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
 <_O8ihTfrgwd_awoK7K20qyP-aZ1YJV-RZsYGx6_qKeI=.a747f5bc-af8a-4425-abcb-b41c1fd4ed84@github.com>
Message-ID: <N1n7v84qpoiaCuaRkFKSMxvYiAMpGCyuyZfa5qksYNI=.63766fca-741e-4268-8bcc-8f1c30855761@github.com>

On Wed, 7 May 2025 14:39:35 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes

This looks good to me too.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25097#pullrequestreview-2868073212

From duke at openjdk.org  Mon May 26 11:15:58 2025
From: duke at openjdk.org (kieran-farrell)
Date: Mon, 26 May 2025 11:15:58 GMT
Subject: Integrated: 7046003: Default value of Authenticator.getRequestingURL()
 is not specified
In-Reply-To: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
References: <d3eTByibX1M6AUQTskKA-FGjBSvP0q68ruzkoNsE5_E=.408490ef-051c-4efd-85e7-4eeee7207509@github.com>
Message-ID: <-pujdSqRjBzAcyjK83Q4D0dT8xwg9DoPtY1nsvwGFT8=.ca1786b2-9298-43f6-9620-a4e6bd215542@github.com>

On Wed, 7 May 2025 14:31:21 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Clarificatiion of spec to outline that Authenticator.getRequestingURL() returns null in the event that the corresponding request does not specify a URL.

This pull request has now been integrated.

Changeset: f825a511
Author:    Kieran Farrell <kieran.farrell at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f825a51198137799f00a0ec2cefa1daa59542f68
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

7046003: Default value of Authenticator.getRequestingURL() is not specified

Reviewed-by: michaelm, jpai

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

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

From dfuchs at openjdk.org  Mon May 26 11:33:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 11:33:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <GuDmDIXX3JwpsXgRXKZHcJo1pwarUx2mlzoLJbl6NaM=.8e831fee-49a7-4420-9c12-26e15db4f3b9@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2868122303

From nbenalla at openjdk.org  Mon May 26 12:44:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 12:44:01 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
Message-ID: <W-AqudctbSkZ6zNtSn0TC_ZMB5huGA_NIKyqfkqHmQo=.bb67eff3-f5ec-4f3c-8579-8014c871ca77@github.com>

On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc based on feedback

All files have been reviewed. Thanks All!

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

PR Comment: https://git.openjdk.org/jdk/pull/25287#issuecomment-2909611326

From nbenalla at openjdk.org  Mon May 26 12:44:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 12:44:01 GMT
Subject: Integrated: 8356632: Fix remaining {@link/@linkplain} tags with refer
 to private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <LWrM1KjboN8_atQM9_jbSW58HqQ4u3cjfIgTJ06SBvA=.8ffd59da-e73a-4e4f-910f-1071ea00e9f0@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

This pull request has now been integrated.

Changeset: bd095896
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd095896dd6e3fccb932f3d9823008766e9ab18d
Stats:     12 lines in 5 files changed: 0 ins; 0 del; 12 mod

8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base

Reviewed-by: weijun, liach

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

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

From pminborg at openjdk.org  Mon May 26 12:50:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 12:50:54 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <Vwoq-RzYoyYkSw4vydZ3LdK8y1XTuQqgnAHlZ4qmGR0=.213e91da-9b6b-49a6-b91d-d7b355394452@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
 <Vwoq-RzYoyYkSw4vydZ3LdK8y1XTuQqgnAHlZ4qmGR0=.213e91da-9b6b-49a6-b91d-d7b355394452@github.com>
Message-ID: <yPPWakioMPqZZh_C8iyK726wAyEo9Pa_-LsCraUdOo0=.118c0cc0-4b2c-40a9-8a89-e4137282e60c@github.com>

On Mon, 26 May 2025 07:51:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
> 
>> 457: 
>> 458:             boolean pending = false;
>> 459:             IOUtil.acquireScope(buf, true);
> 
> Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.

WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107273542

From pminborg at openjdk.org  Mon May 26 14:22:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 14:22:10 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <mP06wCY8rmRctOh5Qav37vLBAxlO67te9T1FjNYTXNA=.63575ecf-3597-4130-b556-5b34faac2c3e@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/d6b4233e..ec233e0c

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

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

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

From alanb at openjdk.org  Mon May 26 15:53:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 15:53:57 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v7]
In-Reply-To: <yPPWakioMPqZZh_C8iyK726wAyEo9Pa_-LsCraUdOo0=.118c0cc0-4b2c-40a9-8a89-e4137282e60c@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <tPeVVJuJim6yQw9iqDU19v9aT0KVReN9eLbXRBcJ2t4=.316c80d2-fdbf-47c4-8a61-ef4b2aad6217@github.com>
 <Vwoq-RzYoyYkSw4vydZ3LdK8y1XTuQqgnAHlZ4qmGR0=.213e91da-9b6b-49a6-b91d-d7b355394452@github.com>
 <yPPWakioMPqZZh_C8iyK726wAyEo9Pa_-LsCraUdOo0=.118c0cc0-4b2c-40a9-8a89-e4137282e60c@github.com>
Message-ID: <MIqVKhiwPG2MXYNnWU0V_unHBjI7Hh7j3kfQsJVQBlc=.9be38bca-8524-4594-917d-d293984d5d0e@github.com>

On Mon, 26 May 2025 12:47:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:
>> 
>>> 457: 
>>> 458:             boolean pending = false;
>>> 459:             IOUtil.acquireScope(buf, true);
>> 
>> Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.
>
> WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good.

Good, thanks for checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107592606

From alanb at openjdk.org  Mon May 26 16:07:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 16:07:54 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: <mP06wCY8rmRctOh5Qav37vLBAxlO67te9T1FjNYTXNA=.63575ecf-3597-4130-b556-5b34faac2c3e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <mP06wCY8rmRctOh5Qav37vLBAxlO67te9T1FjNYTXNA=.63575ecf-3597-4130-b556-5b34faac2c3e@github.com>
Message-ID: <veOIAP1F2MF4k07BGhU0RXmKy2Hgt2yvpMNO5kz8QwA=.db1ecaaa-6d3e-4b97-97fd-b074ce515916@github.com>

On Mon, 26 May 2025 14:22:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669:

> 667: 
> 668:             } finally {
> 669:                 IOUtil.releaseScope(buf);

I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. 

TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107608913

From michaelm at openjdk.org  Mon May 26 16:11:53 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 May 2025 16:11:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
Message-ID: <aEORWmideOMQjOYnEOzrJwAgozOYq3mwEaPk0O1jkrM=.9740ea3e-379b-4d43-9c25-f5466c143361@github.com>

On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from cr
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

I wonder could the two Event types be consolidated inside Event.java? It seems overkill to have them in three separate source files now.

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

PR Review: https://git.openjdk.org/jdk/pull/25333#pullrequestreview-2868836454

From dfuchs at openjdk.org  Mon May 26 16:31:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 16:31:52 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <aEORWmideOMQjOYnEOzrJwAgozOYq3mwEaPk0O1jkrM=.9740ea3e-379b-4d43-9c25-f5466c143361@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <aEORWmideOMQjOYnEOzrJwAgozOYq3mwEaPk0O1jkrM=.9740ea3e-379b-4d43-9c25-f5466c143361@github.com>
Message-ID: <zpoL0TycXr3vkiGsa2zZkg5gyigNNwjq_dfhEGXtTf4=.56a2a9ba-d4e7-446f-a486-e8538c63b0eb@github.com>

On Mon, 26 May 2025 16:08:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I wonder could the two Event types be consolidated inside Event.java? It seems overkill to have them in three separate source files now.

Do you mean refactoring WriteFinishEvent and StopRequestedEvent as inner classes of Event.java?

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2910225464

From msheppar at openjdk.org  Mon May 26 17:10:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:10:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:

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

new file => copyright ?

Copyright (c) 2025,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107664521

From msheppar at openjdk.org  Mon May 26 17:31:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:31:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <VR7MqG42V4SmE5H9X3A7PciRmGTvLH9A2dcWgu4CKeo=.c6a68516-7e72-4a1c-9120-458993e2f74f@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:

> 128:         public abstract String output();
> 129: 
> 130:         protected String output(boolean enhance) {

to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
suggest
refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107682303

From msheppar at openjdk.org  Mon May 26 17:42:59 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:42:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:

> 56:  *     public static SensitiveInfo filterUserName(String name)
> 57:  */
> 58: public final class Exceptions {

maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107691017

From msheppar at openjdk.org  Mon May 26 18:15:56 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 18:15:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <zOdLnzkbEVZk84LTjJ7V6rnpx7zAdrGoj5AHy4eGwrU=.a80f6e5f-5f0e-4c2c-936f-82f4cd22ba3e@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/java/net/HostPortrange.java line 73:

> 71: 
> 72:         // first separate string into two fields: hoststr, portstr
> 73:         String hoststr = null, portstr = null;

you could take the opportunity to update the HostPortrange constructor signature refactor rename
the parameter str to hostname  ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107715671

From msheppar at openjdk.org  Mon May 26 19:09:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 19:09:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251:             return;
> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")

This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

Consider the following: 
includeInException specifies the type of information that maybe included in an enhanced exception 
e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
This defines an information policy 

developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply

an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107759746

From alanb at openjdk.org  Mon May 26 19:25:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:25:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
Message-ID: <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>

On Mon, 26 May 2025 19:06:56 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
> 
>> 251:             return;
>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
> 
> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
> 
> Consider the following: 
> includeInException specifies the type of information that maybe included in an enhanced exception 
> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
> This defines an information policy 
> 
> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
> 
> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107784068

From msheppar at openjdk.org  Mon May 26 20:42:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 20:42:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt
a builder pattern for the creation of the filter exceptions, for example 

 FilteredExceptionBuilder / EnhancedExceptionBuilder.

It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.

EnhancedExceptionBuilder::class()
::exceptionMessage()
::port()
::hostname()
::userDetails()
::filterPolicy()

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238

From msheppar at openjdk.org  Mon May 26 21:46:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 21:46:52 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
Message-ID: <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>

On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>> 
>>> 251:             return;
>>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
>> 
>> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
>> 
>> Consider the following: 
>> includeInException specifies the type of information that maybe included in an enhanced exception 
>> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
>> This defines an information policy 
>> 
>> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
>> 
>> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages
>
>> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.
> 
> I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. 
But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above
Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149

From alanb at openjdk.org  Tue May 27 06:12:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 06:12:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
 <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>
Message-ID: <yPgX7-tnKUMHv-YOOhgSocI0KmdB3js_hgpIWhsPQy0=.94a4919d-ee0b-4778-9afc-f5d5e9ff87fd@github.com>

On Mon, 26 May 2025 21:44:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used.

Right, what is now "hostInfoExclSocket" is a confusing category and not easy to explain to anyone. However it is the long standing default. If you relax the default then security people will complain. If you make it more strict then developers will complain as it makes troubleshooting harder. With the current proposal then nobody has to deal with this confusing named category. Instead, if you want reveal more exceptions then you run with the property set to hostInfo, a category that is much simpler to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2108262111

From pminborg at openjdk.org  Tue May 27 11:23:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:23:55 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v8]
In-Reply-To: <veOIAP1F2MF4k07BGhU0RXmKy2Hgt2yvpMNO5kz8QwA=.db1ecaaa-6d3e-4b97-97fd-b074ce515916@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <mP06wCY8rmRctOh5Qav37vLBAxlO67te9T1FjNYTXNA=.63575ecf-3597-4130-b556-5b34faac2c3e@github.com>
 <veOIAP1F2MF4k07BGhU0RXmKy2Hgt2yvpMNO5kz8QwA=.db1ecaaa-6d3e-4b97-97fd-b074ce515916@github.com>
Message-ID: <E1PYTa9w46j4Pggxlc7mdz8qmnhg_kTB8LQW2bcTTUE=.849f6fb0-ecf6-45d0-af69-73720f4adc75@github.com>

On Mon, 26 May 2025 16:05:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669:
> 
>> 667: 
>> 668:             } finally {
>> 669:                 IOUtil.releaseScope(buf);
> 
> I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. 
> 
> TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR.

Sounds like a good idea: https://bugs.openjdk.org/browse/JDK-8357847

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2108922601

From pminborg at openjdk.org  Tue May 27 11:28:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:28:42 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v9]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <vDNMTtR3H7eIaU3_OmuHjJM7o4-UJA3PiD4fZhmGk_w=.2b460fb7-ac45-4502-a9b8-95559c9e656d@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

 - Revert copyright year
 - Revoke changes in WAFCI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/ec233e0c..c2a901b3

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

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

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

From pminborg at openjdk.org  Tue May 27 11:50:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 11:50:14 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <niTSchYIW9-jCs3hRcdnNG_UlJUJpzc6E_J0-md87uw=.cf6679fc-2dd2-4253-8ea8-fa1f701ceda1@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

 - Merge branch 'master' into jdk-segment-access
 - Revert copyright year
 - Revoke changes in WAFCI
 - Address comments
 - Fix copyright year
 - Update after comments
 - Update after comments
 - Add tests
 - Clean up
 - Revoke changes in classes that is always using DirectBuffer
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ede001e6...1eb284df

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/c2a901b3..1eb284df

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

  Stats: 57006 lines in 826 files changed: 38176 ins; 13844 del; 4986 mod
  Patch: https://git.openjdk.org/jdk/pull/25324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324

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

From alanb at openjdk.org  Tue May 27 12:46:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 12:46:57 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: <niTSchYIW9-jCs3hRcdnNG_UlJUJpzc6E_J0-md87uw=.cf6679fc-2dd2-4253-8ea8-fa1f701ceda1@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <niTSchYIW9-jCs3hRcdnNG_UlJUJpzc6E_J0-md87uw=.cf6679fc-2dd2-4253-8ea8-fa1f701ceda1@github.com>
Message-ID: <DFCSM4ttRwmtdNgOGrgdYyeInhCd3cK4KzGFxeGpgMc=.50c92dab-6d3b-4457-b192-a3387aedce4a@github.com>

On Tue, 27 May 2025 11:50:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-segment-access
>  - Revert copyright year
>  - Revoke changes in WAFCI
>  - Address comments
>  - Fix copyright year
>  - Update after comments
>  - Update after comments
>  - Add tests
>  - Clean up
>  - Revoke changes in classes that is always using DirectBuffer
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/5abc863c...1eb284df

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2870926691

From pminborg at openjdk.org  Tue May 27 12:49:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 12:49:56 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v10]
In-Reply-To: <niTSchYIW9-jCs3hRcdnNG_UlJUJpzc6E_J0-md87uw=.cf6679fc-2dd2-4253-8ea8-fa1f701ceda1@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <niTSchYIW9-jCs3hRcdnNG_UlJUJpzc6E_J0-md87uw=.cf6679fc-2dd2-4253-8ea8-fa1f701ceda1@github.com>
Message-ID: <bnYNTL6_eBYb9Ur_IssDcvXPfB-4eHOfwCcljjuwRsQ=.786c6972-71ef-41c0-93e1-0bfacd4d9ddb@github.com>

On Tue, 27 May 2025 11:50:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-segment-access
>  - Revert copyright year
>  - Revoke changes in WAFCI
>  - Address comments
>  - Fix copyright year
>  - Update after comments
>  - Update after comments
>  - Add tests
>  - Clean up
>  - Revoke changes in classes that is always using DirectBuffer
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ca90399f...1eb284df

I am reverting to 1 reviewer, as we have removed the asynchronous Windows class.

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

PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2912390902

From pminborg at openjdk.org  Tue May 27 13:01:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 13:01:09 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v11]
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <hWtUxzcHkSA8EKBvwBqDEb6GNaZbxpAfisYES_5EwaI=.3c756537-8d1c-4ddb-8f89-2a7fe1e495b7@github.com>

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

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

  Revert changes in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25324/files
  - new: https://git.openjdk.org/jdk/pull/25324/files/1eb284df..dcb67a79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=09-10

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

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

From michaelm at openjdk.org  Tue May 27 13:06:51 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 27 May 2025 13:06:51 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <zpoL0TycXr3vkiGsa2zZkg5gyigNNwjq_dfhEGXtTf4=.56a2a9ba-d4e7-446f-a486-e8538c63b0eb@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <aEORWmideOMQjOYnEOzrJwAgozOYq3mwEaPk0O1jkrM=.9740ea3e-379b-4d43-9c25-f5466c143361@github.com>
 <zpoL0TycXr3vkiGsa2zZkg5gyigNNwjq_dfhEGXtTf4=.56a2a9ba-d4e7-446f-a486-e8538c63b0eb@github.com>
Message-ID: <JPCokZkqCpj19mvDzarOLgtajM2nr64MFiKVSpTg0kM=.7a014a02-63e3-4965-b206-7b8ad86adc30@github.com>

On Mon, 26 May 2025 16:28:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > I wonder could the two Event types be consolidated inside Event.java? It seems overkill to have them in three separate source files now.
> 
> Do you mean refactoring WriteFinishEvent and StopRequestedEvent as inner classes of Event.java?

Potentially, but I thought the simplest approach would be as top-level package private classes in Event.java

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2912442445

From alanb at openjdk.org  Tue May 27 13:09:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 13:09:52 GMT
Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address() [v11]
In-Reply-To: <hWtUxzcHkSA8EKBvwBqDEb6GNaZbxpAfisYES_5EwaI=.3c756537-8d1c-4ddb-8f89-2a7fe1e495b7@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
 <hWtUxzcHkSA8EKBvwBqDEb6GNaZbxpAfisYES_5EwaI=.3c756537-8d1c-4ddb-8f89-2a7fe1e495b7@github.com>
Message-ID: <OqOmyocm8F6zflzE6m1g568cYRZcMYO5ePUfK-rop2M=.2bce5b2d-3a89-4ff1-8d85-4c58c2e9392d@github.com>

On Tue, 27 May 2025 13:01:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2871010526

From myankelevich at openjdk.org  Tue May 27 13:25:38 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 27 May 2025 13:25:38 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v5]
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

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

  consolidated events

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25333/files
  - new: https://git.openjdk.org/jdk/pull/25333/files/5a879107..50749eab

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

  Stats: 117 lines in 7 files changed: 22 ins; 85 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25333/head:pull/25333

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

From michaelm at openjdk.org  Tue May 27 13:39:52 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 27 May 2025 13:39:52 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
Message-ID: <hmv5dQfJuttV2tlISlz7H9Ng0lXzeA66GaDAXL5J07A=.8a8b5142-0152-48eb-988d-e7c32323f591@github.com>

On Fri, 23 May 2025 08:48:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> If I have read the original code correctly there is a flaw in it, that is the startExchange is never called. Thus the code in handleEvent won?t executed as anticipated
> 
> 391 int exchanges = endExchange(); 392 if (terminating && exchanges == 0) { 393 finished = true; 394 }
> 
> Exchanges will always be negative. This is inherited in the new update
> 
> WRT current PR, I don't think it is good that the state of the server is encapsulated in the state of the CountDownLatch. The use of the CountDownLatch to synchronise the stop and the Dispatcher shutdown is fine, but having the server state encapsulated in the CountDownLatch value is a bit oblique or obfuscating. I think the original volatile boolean variable is a clearer semantics
> 
> I would make stop synchronised to have only one thread executing at time. First check on entry then becomes test on the server's current state. This means that this state management needs some attention.
> 
> The addition of Stop event is a neat idea, but draws attention to the semantics of the stop. What is the desired semantics of stop, to not accept any new connections, i.e. stop the listener immediately, not accept new requests on existing connections. To allow existing Exchanges to complete and then shutdown all extant connections.

startExchange() is called in the constructor for ExchangeImpl, which is not changing in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2912550272

From msheppar at openjdk.org  Tue May 27 13:39:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 May 2025 13:39:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v5]
In-Reply-To: <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
Message-ID: <tsm2fuWDEv14ZBEcd3l3VvOKuVEKTAPe2ods8SdWP2c=.d67b8ea2-2e2c-4248-be86-15128effeef9@github.com>

On Tue, 27 May 2025 13:25:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consolidated events

src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java line 35:

> 33:         this.exchange = t;
> 34:     }
> 35: 

I don't see the purpose of this change and the value it brings other than collation and reducing explicit files for the derived Events ?
Could you elaborate the rationale please?

I do see a code smell in WriteFinished directly access the state of ExchangeImpl

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109214767

From dfuchs at openjdk.org  Tue May 27 14:07:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 14:07:55 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v5]
In-Reply-To: <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
Message-ID: <kWZ8IldMtJyn35wU9jLGkcu6annobdnB5qx9G-9CWnI=.c98a61a6-d022-4a54-8144-fcb68b2dac93@github.com>

On Tue, 27 May 2025 13:25:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consolidated events

src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java line 35:

> 33:         this.exchange = t;
> 34:     }
> 35: 

Can you make the `exchange` field final?

src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java line 48:

> 46: 
> 47:     /**
> 48:      * Event indicating that writing is finished.

Suggestion:

     * Event indicating that writing is finished for a given exchange.

src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java line 52:

> 50:     public static class WriteFinished extends Event {
> 51:         WriteFinished(ExchangeImpl t) {
> 52:             super (t);

Suggestion:

            super(Objects.requiresNonNull(t));

src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java line 56:

> 54:             t.writefinished = true;
> 55:         }
> 56:     }

These two classes could be marked final. Do they need to be public?
The Event class should be marked abstract and sealed. If we want to consolidate all events in a single file, marking the super class sealed with no permits clause will make it harder to sneak in a new subclass in a different file.

src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java line 97:

> 95:             } catch (IOException e) {}
> 96:         }
> 97:         Event.WriteFinished e = new Event.WriteFinished(t);

Suggestion:

        Event e = new Event.WriteFinished(t);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109291324
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109283346
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109288671
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109272167
PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109292791

From dfuchs at openjdk.org  Tue May 27 14:15:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 14:15:53 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <tHGgK-uqtqzk_XWkeJ3ZSVb6d4v4qf5NbZLp66cMvbs=.5f4b0406-c06f-4a64-b0c0-b49f5805eb82@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <kT4sMfOg67my-0NQL2vCvgFy6aZyjSaDAq7MXqeNEZo=.ce17aa0a-528c-4d2d-beb5-8df804f56ec7@github.com>
 <UAp_sUEXczbC6oc6m48yHBYYcs6ktEektwPHt9WUAWI=.4c65e049-58d9-474f-bd19-f9337040204d@github.com>
 <RIcQcefaXNrUoyB_Nbiz0llVBdA7PmUlCCD2gTEPhwE=.0381958b-32f3-4ca5-af27-a59e201455ba@github.com>
 <tHGgK-uqtqzk_XWkeJ3ZSVb6d4v4qf5NbZLp66cMvbs=.5f4b0406-c06f-4a64-b0c0-b49f5805eb82@github.com>
Message-ID: <PLvfF8syMjCEbupW7I9xX4szo_mlE6Ha-raPFeCI2fk=.e2ca2759-70f9-4ac0-9344-4edf10e6e1d6@github.com>

On Fri, 23 May 2025 09:49:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> the internal state representation of the server could do with a rethink and overhaul, and representing part of that state in a synchronisation primitive obscures/obfuscates the server state's semantics. I don't think it's "clean code"
>
> I agree that the semantic of `finished` `finishing`  is a bit obfuscated. On the other hand I don't think we should go so far as overhauling / rethinking the states in this PR. If you recall there have been lots of fixes in this area (we had some `assert` firing at some point, and it took some time to find the root cause and fix).
> That said having both a boolean *and* a countdown latch would be duplicate info, and potentially harder to manage consistency. 
> If we don't want the countdown latch we might go back to looping with Thread.sleep in stop, or use wait/notify, and I am not sure it would be much better.

I have a suggestion. Let's do this:


    public final boolean finished() {
        // we're finished when the latch reaches 0
        return finishedLatch.getCount() == 0;
    }
    
    public final boolean isFinishing() {
        return finished();
    }


Then replace things like `if (finished ...` with `if (finished() ...`
That should minimize the changes and make them look less awkward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109317990

From dfuchs at openjdk.org  Tue May 27 14:20:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 14:20:57 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v5]
In-Reply-To: <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <J7UIdtMQvvsRjtkGsS2Je4luApUmKnutFGx0K4MvRzQ=.38e56512-9eb7-49a1-817b-e67b588e35e0@github.com>
Message-ID: <IeRBR0fuK06VzTEtqw-yYy6Q2TTa8h9hI_WpbgSrKYw=.da3025de-74f5-4210-aad4-7cce392fe376@github.com>

On Tue, 27 May 2025 13:25:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consolidated events

src/jdk.httpserver/share/classes/sun/net/httpserver/UndefLengthOutputStream.java line 78:

> 76:             } catch (IOException e) {}
> 77:         }
> 78:         Event.WriteFinished e = new Event.WriteFinished(t);

Suggestion:

        Event e = new Event.WriteFinished(t);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25333#discussion_r2109332998

From myankelevich at openjdk.org  Tue May 27 18:42:38 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 27 May 2025 18:42:38 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v6]
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

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

  discussion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25333/files
  - new: https://git.openjdk.org/jdk/pull/25333/files/50749eab..1ca9ecd3

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

  Stats: 22 lines in 6 files changed: 7 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25333/head:pull/25333

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

From pminborg at openjdk.org  Tue May 27 19:14:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 19:14:05 GMT
Subject: Integrated: 8357268: Use JavaNioAccess.getBufferAddress rather than
 DirectBuffer.address()
In-Reply-To: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
References: <q-RZbZnsFscipBO7jupulTYqK_ttNVyTd_onddTGK64=.1b0318ce-c77e-47f6-a00b-e1dbe27d362e@github.com>
Message-ID: <WZBTAn4ZdMsvEu-GC2rYRaAuQme7UFPmkVCplQmB42M=.3b43f904-af83-4bbf-8fae-5f5e4843967d@github.com>

On Tue, 20 May 2025 10:51:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

This pull request has now been integrated.

Changeset: d4b923d1
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b923d175b07e39ee8ee2c79f04457ea1cfbdd0
Stats:     78 lines in 14 files changed: 17 ins; 0 del; 61 mod

8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address()

Reviewed-by: alanb, valeriep

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

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

From abarashev at openjdk.org  Tue May 27 23:40:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 27 May 2025 23:40:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26]
In-Reply-To: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com>
Message-ID: <dt_NNLapyHRjZLIqkLVp4Snh5c0mW2j0yAO4NvVMupc=.ba6b758e-2c6b-4ec5-9c9c-32e65b19e4ec@github.com>

On Fri, 23 May 2025 21:23:04 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>  - Merge branch 'master' into JDK-8341346
>  - Merge branch 'master' into JDK-8341346
>  - Added PKCS11 testing
>  - Minor bug
>  - Missed one change
>  - Merge branch 'master' into JDK-8341346
>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>  - get*() no longer needed, backout error (oops!)
>  - Merge branch 'master' into JDK-8341346
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99

src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java line 1:

> 1: /*

Not related to this PR, but `engineGenerateKey0` method should be `protected`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2110533393

From dfuchs at openjdk.org  Wed May 28 09:52:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 May 2025 09:52:55 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v6]
In-Reply-To: <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
Message-ID: <72EYGoxGIbYLtQhHeZ_O2PSWxBSGrZZMabpMXrPuCVo=.8d60a9a7-df0e-4e1a-bffe-b1d8282c59ed@github.com>

On Tue, 27 May 2025 18:42:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   discussion

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25333#pullrequestreview-2874355566

From myankelevich at openjdk.org  Wed May 28 10:02:57 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 28 May 2025 10:02:57 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v4]
In-Reply-To: <zpoL0TycXr3vkiGsa2zZkg5gyigNNwjq_dfhEGXtTf4=.56a2a9ba-d4e7-446f-a486-e8538c63b0eb@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <lN0uND4B4j4-5LHnKajb2n0qklLfFeUID4Cqb2o0lok=.2da45a52-118c-4245-aaa7-ed3cf26f631d@github.com>
 <aEORWmideOMQjOYnEOzrJwAgozOYq3mwEaPk0O1jkrM=.9740ea3e-379b-4d43-9c25-f5466c143361@github.com>
 <zpoL0TycXr3vkiGsa2zZkg5gyigNNwjq_dfhEGXtTf4=.56a2a9ba-d4e7-446f-a486-e8538c63b0eb@github.com>
Message-ID: <NiLEVZycX5G_Io1hgElCiOtawiYNi-bWV_ByjgnuZ0M=.10f21e6e-0f7d-4ed5-89ca-ecd9ea1928d6@github.com>

On Mon, 26 May 2025 16:28:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I wonder could the two Event types be consolidated inside Event.java? It seems overkill to have them in three separate source files now.
>
>> I wonder could the two Event types be consolidated inside Event.java? It seems overkill to have them in three separate source files now.
> 
> Do you mean refactoring WriteFinishEvent and StopRequestedEvent as inner classes of Event.java?

@dfuch, @msheppar, @djelinski , @Michael-Mc-Mahon, thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2915725286

From duke at openjdk.org  Wed May 28 10:02:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 10:02:59 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v6]
In-Reply-To: <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
Message-ID: <10P_hNFPJr5OZV1O62j1NPm03crD3f72iYuKGE86W8E=.2cfe4c33-b215-4f15-a430-66d4fc7c3d22@github.com>

On Tue, 27 May 2025 18:42:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   discussion

@myankelev 
Your change (at version 1ca9ecd3887186121ad06b69331a21d476a549c2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25333#issuecomment-2915726873

From michaelm at openjdk.org  Wed May 28 10:38:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 10:38:01 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress [v6]
In-Reply-To: <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
 <nKQrg2zjHshXcWBWMFB6PmiWNKIQrTTGhd9AWMvwod0=.e97382cd-2074-4586-8d6d-33319fabe75d@github.com>
Message-ID: <hseXI_EfvQ1wRSJyroTGv85yAkBjT8Kpj9VUt2nuwWg=.b1e5933a-f702-4119-a6a4-6c93b6563c25@github.com>

On Tue, 27 May 2025 18:42:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
>> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
>> 
>> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
>> 
>> Tests based on @eirbjo work, so adding Eirik as a contributor.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   discussion

Looks good

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25333#pullrequestreview-2874491359

From myankelevich at openjdk.org  Wed May 28 10:38:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 28 May 2025 10:38:02 GMT
Subject: Integrated: 8304065: HttpServer.stop should terminate immediately if
 no exchanges are in progress
In-Reply-To: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
References: <VUGZXylJPxIwFkNbkG5RRxYFL304XPr4sdLj6O9NZ9U=.142f472b-e7a4-46e1-80e5-67bef8fe8c2f@github.com>
Message-ID: <AowKMMEhrOF-aew8FYB6otP3kOGfUBK3jqx3a_EobQo=.97b2cba7-53cb-4f78-91dc-05c5e6371374@github.com>

On Tue, 20 May 2025 15:51:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> HttpServer::stop will terminate the server immidiately after all exhcnages are complete.
> If the exchanges take longer then the specified delay it will terminate straight after the delay, the same as the previous behaviour.
> 
> Used to wait until the delay is complete at all times, regardless of the number of active exchanges.
> 
> Tests based on @eirbjo work, so adding Eirik as a contributor.

This pull request has now been integrated.

Changeset: 627ef344
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/627ef34498c31b5d16f9da423cfe0a5fe46a3562
Stats:     540 lines in 7 files changed: 429 ins; 58 del; 53 mod

8304065: HttpServer.stop should terminate immediately if no exchanges are in progress

Co-authored-by: Eirik Bj?rsn?s <eirbjo at openjdk.org>
Reviewed-by: dfuchs, michaelm

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

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

From michaelm at openjdk.org  Wed May 28 11:13:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:13:12 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Wed May 28 11:34:58 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>
Message-ID: <Bu6wcccn3cfvlDuNu_L_zlPBD8tKrQJa-2gALdtWBvo=.b2a84461-3d41-4538-882f-01f387887b78@github.com>

On Mon, 26 May 2025 17:07:45 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> new file => copyright ?
> 
> Copyright (c) 2025,

The file isn't actually new, though webrev doesn't seem to realise that on this occasion (sometimes it does recognise name changes). It was previously named SocketExceptions. I presume we keep the existing header in that case?

> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:
> 
>> 128:         public abstract String output();
>> 129: 
>> 130:         protected String output(boolean enhance) {
> 
> to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
> suggest
> refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

Okay, I'll use one of those options, whichever fits best space wise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111618040
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111620553

From michaelm at openjdk.org  Wed May 28 11:38:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:38:01 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>
Message-ID: <EbqRLMAtkUaAjK5NMoZB-nsXuIDFS6MeuzirA985pHk=.13d13602-c91d-4105-821a-0ea06caca058@github.com>

On Mon, 26 May 2025 17:40:39 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:
> 
>> 56:  *     public static SensitiveInfo filterUserName(String name)
>> 57:  */
>> 58: public final class Exceptions {
> 
> maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

I see what you mean, but the class does more than just filter messages. It also generates new Exception objects from existing ones. Given that its original name was `SocketExceptions` and all we've done here is generalize it to work with other exception types, I think `Exceptions` is a reasonable name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111626402

From msheppar at openjdk.org  Wed May 28 23:16:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 28 May 2025 23:16:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
Message-ID: <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>

On Wed, 28 May 2025 11:13:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

her are few file with IOException, UnknownHostException and MalformedURLException, which are worth reviewing form Exception that may have been missed

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
Ln 562



open/src/java.base/share/classes/sun/security/x509/IPAddressName.java

open/src/java.base/share/classes/sun/security/x509/URIName.java

open/src/java.base/share/classes/sun/security/x509/RDN.java

open/src/java.base/share/classes/java/util/jar/JarFile.java


UnknownHostException

open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java

open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java


MalformedURLException

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java

open/src/java.base/share/classes/java/net/URL.java  ? Invalid port

open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java

open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java

open/src/java.rmi/share/classes/java/rmi/Naming.java

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2917817454

From wetmore at openjdk.org  Thu May 29 00:54:37 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 00:54:37 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is complete/approved.
> 
> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into JDK-8341346
 - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
 - Merge branch 'master' into JDK-8341346
 - Merge branch 'master' into JDK-8341346
 - Added PKCS11 testing
 - Minor bug
 - Missed one change
 - Merge branch 'master' into JDK-8341346
 - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
 - get*() no longer needed, backout error (oops!)
 - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=26
  Stats: 1022 lines in 9 files changed: 1000 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From jpai at openjdk.org  Thu May 29 06:06:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 06:06:45 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null
Message-ID: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>

Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?

As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.

Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.

Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:


import java.net.*;

public class Test {
    public static void main(String[] args) throws Exception {
        System.out.println("testing against Java " + System.getProperty("java.version"));

        final ClassLoader cl = new URLClassLoader(new URL[0], null);
        final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
        System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());

    }
}

which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:


testing against Java 24
Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
    at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
    at Test.main(Test.java:8)


No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

Once we settle on the proposed text, I'll file a CSR for this change. I've marked the issue as fix version "26" since there's no rush for this change. But if we settle down on this text and the change looks good, this week, then I'll go ahead and propose this for 25.

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

Commit messages:
 - 8228773: URLClassLoader constructors should include API note warning that the parent should not be null

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

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

From alanb at openjdk.org  Thu May 29 08:02:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 08:02:54 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com>

On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

src/java.base/share/classes/java/net/URLClassLoader.java line 98:

> 96:      * Constructs a new URLClassLoader for the specified URLs using the
> 97:      * {@linkplain ClassLoader#getSystemClassLoader() default delegation
> 98:      * parent class loader}. The URLs will be searched in the order

As we are changing it then maybe we could change this to "using the system class loader as the parent". I think that would be much clearer than "default delegation parent ...". Same thing in SecureClassLoader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113431536

From dfuchs at openjdk.org  Thu May 29 08:30:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 May 2025 08:30:58 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>

On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

src/java.base/share/classes/java/net/URLClassLoader.java line 82:

> 80:      * @apiNote If the {@code parent} is specified as {@code null} (for the
> 81:      * bootstrap class loader) then there is no guarantee that all platform
> 82:      * classes are visible.

Should we add a link to `{@linkplain ClassLoader##builtinLoaders ...}` somewhere  in this API note? 

> there is no guarantee that all platform classes are visible

sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113473277

From michaelm at openjdk.org  Thu May 29 09:02:55 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:55 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>
Message-ID: <mdD2ZTgb3Q0wHEk0-NhZtPOeZ-dz0EFld4FEShRehOU=.be92da99-2f81-4c00-861a-8116cc0d04ae@github.com>

On Mon, 26 May 2025 20:39:51 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example
> 
> FilteredExceptionBuilder / EnhancedExceptionBuilder.
> 
> It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.
> 
> EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy()

We've been through so many iterations at this stage, that I think what we've landed on is reasonable and probably most importantly, concise such that it's not overly intrusive at the call sites.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918770154

From michaelm at openjdk.org  Thu May 29 09:02:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
 <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>
Message-ID: <Baew1rh4CURyWBtnLgNuFHrTZNgxN5YK0oCFJpG9UOI=.00f12b97-d48d-480c-a416-770220936e39@github.com>

On Wed, 28 May 2025 23:13:21 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> here are a few files with IOException, UnknownHostException and MalformedURLException, which are worth reviewing for Exception that may have been missed
> 
> IOEXception:
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java Ln 562
> 
> open/src/java.base/share/classes/sun/security/x509/IPAddressName.java
> 
> open/src/java.base/share/classes/sun/security/x509/URIName.java
> 
> open/src/java.base/share/classes/sun/security/x509/RDN.java
> 
> open/src/java.base/share/classes/java/util/jar/JarFile.java
> 
> UnknownHostException
> 
> open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java
> 
> open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
> 
> MalformedURLException
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java
> 
> open/src/java.base/share/classes/java/net/URL.java ? Invalid port
> 
> open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java
> 
> open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java
> 
> open/src/java.rmi/share/classes/java/rmi/Naming.java

Thanks, I will take another look at all these cases and update any that I agree need to be included.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918771547

From hchao at openjdk.org  Thu May 29 11:20:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 29 May 2025 11:20:57 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
Message-ID: <Ppn82ErIWPXdbQZEcjGW_p1q4G5us4pDMt0t7iueICs=.5a2eae22-2377-40c5-861d-0c15f67ac752@github.com>

On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>  - Merge branch 'master' into JDK-8341346
>  - Merge branch 'master' into JDK-8341346
>  - Added PKCS11 testing
>  - Minor bug
>  - Missed one change
>  - Merge branch 'master' into JDK-8341346
>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>  - get*() no longer needed, backout error (oops!)
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1559:

> 1557:                     emptyHash = md.digest();
> 1558:                 } catch (NoSuchAlgorithmException nsae) {
> 1559:                     throw new ProviderException(

This exception is not listed in `@throws` of new API in `ExtendedSSLSession.java`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2113743245

From jpai at openjdk.org  Thu May 29 13:23:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 13:23:42 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <wzN4SvVRklIEeciOgMbGgAYDSCRMNMZHbwthjtXoBf8=.466ad722-7913-4428-979c-c1f6f0b87126@github.com>

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

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

  Alan's suggestion - replace default delegation class loader with system class loader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25517/files
  - new: https://git.openjdk.org/jdk/pull/25517/files/6acffa95..95ff99cb

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

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

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

From jpai at openjdk.org  Thu May 29 13:23:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 13:23:43 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com>
Message-ID: <-dIzX_UVlW7Ek6J3CKy_LksBrGYDmSBGrn8pUnyD8z8=.6e4bd106-5cd2-484b-bce1-ef104834a2d4@github.com>

On Thu, 29 May 2025 08:00:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestion - replace default delegation class loader with system class loader
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 98:
> 
>> 96:      * Constructs a new URLClassLoader for the specified URLs using the
>> 97:      * {@linkplain ClassLoader#getSystemClassLoader() default delegation
>> 98:      * parent class loader}. The URLs will be searched in the order
> 
> As we are changing it then maybe we could change this to "using the system class loader as the parent". I think that would be much clearer than "default delegation parent ...". Same thing in SecureClassLoader.

Done - updated these 2 places to use the "system class loader" reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113928114

From jpai at openjdk.org  Thu May 29 13:23:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 13:23:43 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
Message-ID: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>

On Thu, 29 May 2025 08:28:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>   there is no guarantee that all platform classes are visible
>
> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that.

Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. 

Alan, do you suggest we should reword this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113931597

From alanb at openjdk.org  Thu May 29 13:42:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 13:42:54 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
Message-ID: <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>

On Thu, 29 May 2025 13:20:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLClassLoader.java line 82:
>> 
>>> 80:      * @apiNote If the {@code parent} is specified as {@code null} (for the
>>> 81:      * bootstrap class loader) then there is no guarantee that all platform
>>> 82:      * classes are visible.
>> 
>> Should we add a link to `{@linkplain ClassLoader##builtinLoaders ...}` somewhere  in this API note? 
>> 
>>> there is no guarantee that all platform classes are visible
>> 
>> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that.
>
>>>   there is no guarantee that all platform classes are visible
>>
>> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that.
> 
> Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. 
> 
> Alan, do you suggest we should reword this?

I think what you have in the latest commit is good. To address Daniel's comment then we could add another sentence to the API note, something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113971128

From jpai at openjdk.org  Thu May 29 13:47:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 13:47:56 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
 <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
Message-ID: <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>

On Thu, 29 May 2025 13:40:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>>>   there is no guarantee that all platform classes are visible
>>>
>>> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that.
>> 
>> Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. 
>> 
>> Alan, do you suggest we should reword this?
>
> I think what you have in the latest commit is good. To address Daniel's comment then we could add another sentence to the API note, something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work.

> Should we add a link to {@linkplain ClassLoader##builtinLoaders ...} somewhere in this API note?

I think we can add that as a link for "bootstrap class loader". Something like:


 * @apiNote If the {@code parent} is specified as {@code null} (for the
 * {@linkplain ClassLoader##builtinLoaders bootstrap class loader}) then
 * there is no guarantee that all platform classes are visible.


Should we use this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113989966

From jpai at openjdk.org  Thu May 29 14:03:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 14:03:50 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v2]
In-Reply-To: <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
 <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
 <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>
Message-ID: <HlLZ8xMz3XtvbrUsTGrzKeu1-BYMOQkN455EF1tXNrA=.2e179735-f994-4255-8523-2dd928b86d51@github.com>

On Thu, 29 May 2025 13:45:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we use this?

I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114045277

From jpai at openjdk.org  Thu May 29 14:19:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 14:19:08 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

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

  additional sentence to the apiNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25517/files
  - new: https://git.openjdk.org/jdk/pull/25517/files/95ff99cb..12f70566

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

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

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

From jpai at openjdk.org  Thu May 29 14:19:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 May 2025 14:19:08 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <HlLZ8xMz3XtvbrUsTGrzKeu1-BYMOQkN455EF1tXNrA=.2e179735-f994-4255-8523-2dd928b86d51@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
 <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
 <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>
 <HlLZ8xMz3XtvbrUsTGrzKeu1-BYMOQkN455EF1tXNrA=.2e179735-f994-4255-8523-2dd928b86d51@github.com>
Message-ID: <CdyOA_k686W64sUSbJxEmp0zEblKNKQyyuQ7Fwsr3s4=.50e75b0f-99f1-44a0-a6c4-5e8916a3f620@github.com>

On Thu, 29 May 2025 14:01:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Should we add a link to {@linkplain ClassLoader##builtinLoaders ...} somewhere in this API note?
>> 
>> I think we can add that as a link for "bootstrap class loader". Something like:
>> 
>> 
>>  * @apiNote If the {@code parent} is specified as {@code null} (for the
>>  * {@linkplain ClassLoader##builtinLoaders bootstrap class loader}) then
>>  * there is no guarantee that all platform classes are visible.
>> 
>> 
>> Should we use this?
>
>> Should we use this?
> 
> I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly.

> something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work.

Done. Updated the PR with this text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114072976

From michaelm at openjdk.org  Thu May 29 14:35:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 14:35:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

  Additional callsites identified by Mark S.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/cf179f7d..34f20c9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11-12

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

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

From weijun at openjdk.org  Thu May 29 15:25:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 May 2025 15:25:58 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
Message-ID: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>

On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>  - Merge branch 'master' into JDK-8341346
>  - Merge branch 'master' into JDK-8341346
>  - Added PKCS11 testing
>  - Minor bug
>  - Missed one change
>  - Merge branch 'master' into JDK-8341346
>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>  - get*() no longer needed, backout error (oops!)
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 176:

> 174:      * RFC 8446 (TLSv1.3) treats a null context as non-null/empty.
> 175:      * <P>
> 176:      * The {@code label} {@code String} will be converted to bytes using

Two consecutive `{@code}` look a little strange to me, visually. How about just `{@code label} will be...`? You already use that in `@param label`. Same as in the other method.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 198:

> 196:      *                {@code label} will be converted to a {@code byte[]}
> 197:      *                before the operation begins.
> 198:      * @param context the context bytes used in the EKM calculation, or null

`null` needs to be in `{@code}`. Same as in `@throws NullPointerException`. Same as in the other method.

src/java.base/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java line 85:

> 83:      * @param secret the secret to use in the calculation (or null)
> 84:      * @param keyAlg the algorithm name that the generated SecretKey should
> 85:      *               have, or null if the default should be used

You no longer allow it to be `null`.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494:

> 1492:             if (exporterMasterSecret == null) {
> 1493:                 throw new RuntimeException(
> 1494:                         "Exporter master secret not captured");

Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`.

Same question in `useTLS10PlusSpec()` for the two randoms.

test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 1:

> 1: /*

Do you want to test about null/empty context difference in TLS 1.2/1.3?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114057734
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114060429
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114065976
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114120216
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114083657

From dfuchs at openjdk.org  Thu May 29 16:16:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 May 2025 16:16:51 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>
Message-ID: <BzxcVhVwfJAHzP-kPQIwCYxdTIW6okQ9ofsOtocGn8g=.7418cbd0-2c6f-4a06-bb0f-60bca6ace52d@github.com>

On Thu, 29 May 2025 14:19:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional sentence to the apiNote

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2878852031

From alanb at openjdk.org  Thu May 29 16:46:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 May 2025 16:46:57 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <CdyOA_k686W64sUSbJxEmp0zEblKNKQyyuQ7Fwsr3s4=.50e75b0f-99f1-44a0-a6c4-5e8916a3f620@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
 <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
 <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>
 <HlLZ8xMz3XtvbrUsTGrzKeu1-BYMOQkN455EF1tXNrA=.2e179735-f994-4255-8523-2dd928b86d51@github.com>
 <CdyOA_k686W64sUSbJxEmp0zEblKNKQyyuQ7Fwsr3s4=.50e75b0f-99f1-44a0-a6c4-5e8916a3f620@github.com>
Message-ID: <YQhmU8Y4JFKDHZRMFi_TMhmCmt-oEE1ryzorykkPuvs=.cecddd31-64fd-405a-88aa-debdb9306bb4@github.com>

On Thu, 29 May 2025 14:16:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Should we use this?
>> 
>> I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly.
>
>> something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work.
> 
> Done. Updated the PR with this text.

Ah, I see I said "system class loader" in error, I meant the bootstrap classloader because the that is what the first sentence is about. Sorry for the confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114348523

From mullan at openjdk.org  Thu May 29 17:01:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 29 May 2025 17:01:55 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>
Message-ID: <wVN0_y4KSoSDPQhX8DCJPUOGVZCAhQHV6wkO9S3BIuU=.6c9354e8-7085-472e-b413-204938a910c4@github.com>

On Thu, 29 May 2025 14:19:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional sentence to the apiNote

src/java.base/share/classes/java/net/URLClassLoader.java line 87:

> 85:      *
> 86:      * @param      urls the URLs from which to load classes and resources
> 87:      * @param      parent the parent class loader for delegation, can be null

s/null/{@code null}/

src/java.base/share/classes/java/net/URLClassLoader.java line 123:

> 121:      * obtain protocol handlers when creating new jar URLs.
> 122:      *
> 123:      * @apiNote If the {@code parent} is specified as {@code null} (for the

I think "If {@code parent}" is more correct, since you are implicitly referring to the parameter.

src/java.base/share/classes/java/net/URLClassLoader.java line 127:

> 125:      * classes are visible.
> 126:      * See {@linkplain ClassLoader##builtinLoaders Run-time Built-in Class Loaders}
> 127:      * for information on the system class loader and other built-in class loaders.

Seems more relevant to say "for information on the bootstrap class loader and other built-in class loaders." since you specifically mention bootstrap loader in the first sentence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114361908
PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114370688
PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114366997

From dfuchs at openjdk.org  Thu May 29 17:10:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 May 2025 17:10:04 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
Message-ID: <PdyBqRPpPYWVC7U-oXwgLdmgeLHcETvNhOPiGA3z9b4=.b31032de-4e42-4c9c-a994-bf0e2a279ccc@github.com>

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional callsites identified by Mark S.

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 566:

> 564:                                         filterNonSocketInfo(url.getHost())
> 565:                                             .prefixWith("should be <")
> 566:                                             .suffixWith(">")));

Suggestion:

        throw new IOException(formatMsg("Wrong HTTPS hostname%s",
                                        filterNonSocketInfo(url.getHost())
                                            .prefixWith(": should be <")
                                            .suffixWith(">")));

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 560:

> 558:         if (isa.isUnresolved()) {
> 559:             throw new UnknownHostException(
> 560:                 formatMsg("%s", filterNonSocketInfo(isa.getHostName())));

Suggestion:

                formatMsg(filterNonSocketInfo(isa.getHostName())));

src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java line 99:

> 97:             close();
> 98:             throw new UnknownHostException(
> 99:                 formatMsg("%s", filterNonSocketInfo(remote.toString())));

Suggestion:

            throw new UnknownHostException(
                formatMsg(filterNonSocketInfo(remote.toString())));

src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java line 125:

> 123:     protected MalformedURLException newInvalidURISchemeException(String uri) {
> 124:         return new MalformedURLException(formatMsg("Not an LDAP URL: %s",
> 125:                                                    filterNonSocketInfo(uri)));

Suggestion:

        return new MalformedURLException(formatMsg("Not an LDAP URL%s",
                                                   filterNonSocketInfo(uri).prefixWith(": ")));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 238:

> 236: 
> 237:     private MalformedURLException newMalformedURLException(String prefix, String msg) {
> 238:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).withPrefix(prefix.isEmpty()? "" : ": "));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 250:

> 248:                 URI u = new URI(uri);
> 249:                 scheme = u.getScheme();
> 250:                 if (scheme == null) throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

                if (scheme == null) throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 262:

> 260:                     if (!hostport.equals(auth)) {
> 261:                         // throw if we have user info or regname
> 262:                         throw newMalformedURLException("unsupported authority:", auth);

Suggestion:

                        throw newMalformedURLException("unsupported authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 271:

> 269:                 if (u.getRawFragment() != null) {
> 270:                     if (!acceptsFragment()) {
> 271:                         throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                        throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 308:

> 306:         int fmark = uri.indexOf('#');
> 307:         if (i < 0 || slash > 0 && i > slash || qmark > 0 && i > qmark || fmark > 0 && i > fmark) {
> 308:             throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

            throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 312:

> 310:         if (fmark > -1) {
> 311:             if (!acceptsFragment()) {
> 312:                 throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 358:

> 356:                     String ui = u.getRawUserInfo();
> 357:                     if (ui != null) {
> 358:                         throw newMalformedURLException("user info not supported in authority:", ui);

Suggestion:

                        throw newMalformedURLException("user info not supported in authority", ui);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 361:

> 359:                     }
> 360:                     if (!"/".equals(p)) {
> 361:                         throw newMalformedURLException("invalid authority:", auth);

Suggestion:

                        throw newMalformedURLException("invalid authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 364:

> 362:                     }
> 363:                     if (q != null) {
> 364:                         throw newMalformedURLException("invalid trailing characters in authority: ?", q);

Suggestion:

                        throw new MalformedURLException("invalid trailing characters in authority: ?" + formatMsg(filterNonSocketInfo(q)));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 374:

> 372:                         // throw if we have user info or regname
> 373:                         throw newMalformedURLException("Authority component is not server-based, " +
> 374:                                               "or contains user info. Unsupported authority:", auth);

Suggestion:

                                              "or contains user info. Unsupported authority", auth);

src/java.rmi/share/classes/java/rmi/Naming.java line 227:

> 225: 
> 226:     private static MalformedURLException newMalformedURLException(String prefix, String msg) {
> 227:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).prefixWith(": "));

src/java.rmi/share/classes/java/rmi/Naming.java line 250:

> 248:              */
> 249:             MalformedURLException mue = newMalformedURLException(
> 250:                 "invalid URL String:", str);

Suggestion:

                "invalid URL String", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 282:

> 280:         if (uri.isOpaque()) {
> 281:             throw newMalformedURLException(
> 282:                 "not a hierarchical URL:", str);

Suggestion:

                "not a hierarchical URL", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 286:

> 284:         if (uri.getFragment() != null) {
> 285:             throw newMalformedURLException(
> 286:                 "invalid character, '#', in URL name:", str);

Suggestion:

                "invalid character, '#', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 289:

> 287:         } else if (uri.getQuery() != null) {
> 288:             throw newMalformedURLException(
> 289:                 "invalid character, '?', in URL name:", str);

Suggestion:

                "invalid character, '?', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 292:

> 290:         } else if (uri.getUserInfo() != null) {
> 291:             throw newMalformedURLException(
> 292:                 "invalid character, '@', in URL host:", str);

Suggestion:

                "invalid character, '@', in URL host", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 296:

> 294:         String scheme = uri.getScheme();
> 295:         if (scheme != null && !scheme.equals("rmi")) {
> 296:             throw newMalformedURLException("invalid URL scheme:", str);

Suggestion:

            throw new MalformedURLException(formatMsg("invalid URL scheme%s", filterNonSocketInfo(str).prefixWith(": ").replaceWith(": rmi"));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114314118
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114338001
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114341371
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114325981
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114336092
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114343715
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344189
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344732
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114349684
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114360771
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361269
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361808
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114372438
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114373811
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114380353
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381257
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381615
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381991
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382430
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382678
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114383025

From bpb at openjdk.org  Thu May 29 19:10:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 19:10:46 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v14]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <6JakAvYfDIFLQHI8MwxCjvEl-4MR4rQmJzJNGytPQIw=.689b5a9f-c0c6-4dea-8e6b-b668b999e8c0@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - ... and 4 more: https://git.openjdk.org/jdk/compare/79aff26c...95ce13fb

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=13
  Stats: 1540 lines in 93 files changed: 774 ins; 668 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From wetmore at openjdk.org  Thu May 29 20:04:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 20:04:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26]
In-Reply-To: <dt_NNLapyHRjZLIqkLVp4Snh5c0mW2j0yAO4NvVMupc=.ba6b758e-2c6b-4ec5-9c9c-32e65b19e4ec@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com>
 <dt_NNLapyHRjZLIqkLVp4Snh5c0mW2j0yAO4NvVMupc=.ba6b758e-2c6b-4ec5-9c9c-32e65b19e4ec@github.com>
Message-ID: <1fBXXKWhwmVtCs4xV7oD805N2cWK9gXvidfRvEaDCFo=.58eb8aa5-94e8-403c-8ff1-dfa00b3e1d4c@github.com>

On Tue, 27 May 2025 23:37:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - Merge branch 'master' into JDK-8341346
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99
>
> src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java line 1:
> 
>> 1: /*
> 
> Not related to this PR, but `engineGenerateKey0` method should be `protected`

I will go ahead and tweak it.  Shouldn't be a problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114662829

From wetmore at openjdk.org  Thu May 29 20:16:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 20:16:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
Message-ID: <FyBdEWLSRzJ9rI4A7PTeg_uj4oIRB_oQYIewKOLFV5M=.44bc3ebd-c47a-4f39-ab3a-fb6db65da94d@github.com>

On Thu, 29 May 2025 14:08:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 176:
> 
>> 174:      * RFC 8446 (TLSv1.3) treats a null context as non-null/empty.
>> 175:      * <P>
>> 176:      * The {@code label} {@code String} will be converted to bytes using
> 
> Two consecutive `{@code}` look a little strange to me, visually. How about just `{@code label} will be...`? You already use that in `@param label`. Same as in the other method.

Done.

     * {@code label} will be converted to bytes using
     * the {@link java.nio.charset.StandardCharsets#UTF_8}
     * character encoding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114679469

From wetmore at openjdk.org  Thu May 29 20:33:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 20:33:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
Message-ID: <0RcPynZ_KgnC2dSHO6JMMnk9LTFzhKAOX1vmuunrh7k=.184fc841-3e8d-4153-8653-37939926c3c9@github.com>

On Thu, 29 May 2025 14:09:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 198:
> 
>> 196:      *                {@code label} will be converted to a {@code byte[]}
>> 197:      *                before the operation begins.
>> 198:      * @param context the context bytes used in the EKM calculation, or null
> 
> `null` needs to be in `{@code}`. Same as in `@throws NullPointerException`. Same as in the other method.

As we discussed in Slack, the javadocs are all over the place on this one.  Some have it, others don't.  We have more non-code nulls than code in the JSSE docs.  I don't mind either way.  But if we're going to do this, we might want to do it throughout the security code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114703622

From wetmore at openjdk.org  Thu May 29 20:37:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 20:37:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
Message-ID: <_4JYDI_vv1GEjvgVyM4LT05cCh9osKWbpxo36VhGbS8=.615a0a2a-9b40-490c-957d-8ff909dff556@github.com>

On Thu, 29 May 2025 14:12:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> src/java.base/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java line 85:
> 
>> 83:      * @param secret the secret to use in the calculation (or null)
>> 84:      * @param keyAlg the algorithm name that the generated SecretKey should
>> 85:      *               have, or null if the default should be used
> 
> You no longer allow it to be `null`.

Egads, good catch.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114708506

From wetmore at openjdk.org  Thu May 29 22:15:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 22:15:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <Ppn82ErIWPXdbQZEcjGW_p1q4G5us4pDMt0t7iueICs=.5a2eae22-2377-40c5-861d-0c15f67ac752@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <Ppn82ErIWPXdbQZEcjGW_p1q4G5us4pDMt0t7iueICs=.5a2eae22-2377-40c5-861d-0c15f67ac752@github.com>
Message-ID: <VZRJNuNy95tNsLHP2y7fq3VUwEeTd7tKf7AuXJboQKs=.c8a90891-1a02-49d7-837a-9ba4b31796bd@github.com>

On Thu, 29 May 2025 11:17:50 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1559:
> 
>> 1557:                     emptyHash = md.digest();
>> 1558:                 } catch (NoSuchAlgorithmException nsae) {
>> 1559:                     throw new ProviderException(
> 
> This exception is not listed in `@throws` of new API in `ExtendedSSLSession.java`?

Weijun and I talked about this.  This is a really extreme case all providers that provide basic functionality have been removed.  We don't mention this anywhere else, and it's done in several places.  It's a RuntimeException, and we don't always document every situation. 

I'm ok to skip this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114826097

From wetmore at openjdk.org  Thu May 29 22:29:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 29 May 2025 22:29:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
Message-ID: <_pHe7Ea7Rh7GEWiV08QMYfDNd1lOgle1CTSuKYfYRaM=.42fb5cb5-572a-4538-95dd-f55aa86186d7@github.com>

On Thu, 29 May 2025 14:22:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 1:
> 
>> 1: /*
> 
> Do you want to test about null/empty context difference in TLS 1.2/1.3?

I can add that in the TLS1.2- arm, although I'm not sure it's really needed.  

Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114839789

From hchao at openjdk.org  Thu May 29 23:49:53 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 29 May 2025 23:49:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
Message-ID: <RA88X3VQUUT8jKHFEmVl60PhieGh5koV8n0CblrBYwE=.0edf90f8-28c1-465c-a94d-dd46360184e4@github.com>

On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>  - Merge branch 'master' into JDK-8341346
>  - Merge branch 'master' into JDK-8341346
>  - Added PKCS11 testing
>  - Minor bug
>  - Missed one change
>  - Merge branch 'master' into JDK-8341346
>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>  - get*() no longer needed, backout error (oops!)
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2879841654

From wetmore at openjdk.org  Fri May 30 01:13:48 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 30 May 2025 01:13:48 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is complete/approved.
> 
> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

  Last minute codereview comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/858362c8..d0a0a7bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=26-27

  Stats: 31 lines in 5 files changed: 24 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Fri May 30 01:27:56 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 30 May 2025 01:27:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
Message-ID: <NlEJHrt7oqj710XWuYNXAReEveNeVFoaI4eDYXCDjbo=.10aa0cf5-51bd-44fb-8402-895aaa6a5176@github.com>

On Thu, 29 May 2025 14:42:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
>>  - Merge branch 'master' into JDK-8341346
>>  - Merge branch 'master' into JDK-8341346
>>  - Added PKCS11 testing
>>  - Minor bug
>>  - Missed one change
>>  - Merge branch 'master' into JDK-8341346
>>  - Private Codereview comment:  Don't allow use of null keyAlgs, plus some minor cleanups
>>  - get*() no longer needed, backout error (oops!)
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494:
> 
>> 1492:             if (exporterMasterSecret == null) {
>> 1493:                 throw new RuntimeException(
>> 1494:                         "Exporter master secret not captured");
> 
> Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`.
> 
> Same question in `useTLS10PlusSpec()` for the two randoms.

@wangweij asked if `SSLSession` are ever in a partially completed state.  The answer is yes, during handshaking the `SSLSocket/SSLEngine.getHandshakeSession()` methods can return `SSLSession` that is incomplete.  As such, it makes more sense for this to be an `IllegalArgumentException`.  

Drafted the CSR, made the update, and refinalized it.  Hopefully the wording is acceptable.  ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114985934

From weijun at openjdk.org  Fri May 30 01:53:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 May 2025 01:53:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28]
In-Reply-To: <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
Message-ID: <7j7RJqSNu8rArSRF8NlX2gVRSjryTwI36FHrMXhbPPk=.545457e6-1db1-4601-8b2f-5f9032f4825b@github.com>

On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last minute codereview comments

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2879996771

From jpai at openjdk.org  Fri May 30 06:26:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 06:26:51 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <YQhmU8Y4JFKDHZRMFi_TMhmCmt-oEE1ryzorykkPuvs=.cecddd31-64fd-405a-88aa-debdb9306bb4@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <TXsF-HsG7f3-htbT6JunZG1KPldRichIBhQH_4hO6OY=.ffed90ea-ec88-4474-bca2-2dc8d3d4f4e4@github.com>
 <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com>
 <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com>
 <bGC8njCUQOqv9gFE_BXsYInodo5yGLLuaN2IPD2oLoU=.1e0813bb-f2e3-492f-94cf-881d0c6fcb13@github.com>
 <HlLZ8xMz3XtvbrUsTGrzKeu1-BYMOQkN455EF1tXNrA=.2e179735-f994-4255-8523-2dd928b86d51@github.com>
 <CdyOA_k686W64sUSbJxEmp0zEblKNKQyyuQ7Fwsr3s4=.50e75b0f-99f1-44a0-a6c4-5e8916a3f620@github.com>
 <YQhmU8Y4JFKDHZRMFi_TMhmCmt-oEE1ryzorykkPuvs=.cecddd31-64fd-405a-88aa-debdb9306bb4@github.com>
Message-ID: <zHKZi8VBkuU4LeejXmEuCkuRjBnPRXtg04KIDGTiHcA=.45f47a79-d652-4c7d-952b-b4cd60b37dfa@github.com>

On Thu, 29 May 2025 16:43:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work.
>> 
>> Done. Updated the PR with this text.
>
> Ah, I see I said "system class loader" in error, I meant the bootstrap classloader because the that is what the first sentence is about. Sorry for the confusion.

No problem. Although I had seen that discrepancy, I assumed that you probably wanted to nudge users towards the use of system class loader for these constructors. I will replace it to bootstrap class loader shortly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115221587

From jpai at openjdk.org  Fri May 30 06:55:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 06:55:07 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v4]
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - replace system class loader reference with bootstrap class loader
 - remove "the"
 - {@code null} instead of null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25517/files
  - new: https://git.openjdk.org/jdk/pull/25517/files/12f70566..9897bec3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=02-03

  Stats: 18 lines in 2 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25517/head:pull/25517

PR: https://git.openjdk.org/jdk/pull/25517

From jpai at openjdk.org  Fri May 30 06:55:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 06:55:08 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v3]
In-Reply-To: <wVN0_y4KSoSDPQhX8DCJPUOGVZCAhQHV6wkO9S3BIuU=.6c9354e8-7085-472e-b413-204938a910c4@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <bv3B6jjekjavwAt-Tvt7ce0tNtSbXi-KL6NSOu8tFe0=.205c45bd-4f2d-490d-8e6b-aa683a6b4eaa@github.com>
 <wVN0_y4KSoSDPQhX8DCJPUOGVZCAhQHV6wkO9S3BIuU=.6c9354e8-7085-472e-b413-204938a910c4@github.com>
Message-ID: <jZ7uH-f9u4VdvYc_039_ML9cOqUbRzakUtHqYjmM1RE=.7cdad628-0018-4ae1-9b2f-033e62700b6a@github.com>

On Thu, 29 May 2025 16:50:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional sentence to the apiNote
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 87:
> 
>> 85:      *
>> 86:      * @param      urls the URLs from which to load classes and resources
>> 87:      * @param      parent the parent class loader for delegation, can be null
> 
> s/null/{@code null}/

Fixed in the latest update of this PR.

> src/java.base/share/classes/java/net/URLClassLoader.java line 123:
> 
>> 121:      * obtain protocol handlers when creating new jar URLs.
>> 122:      *
>> 123:      * @apiNote If the {@code parent} is specified as {@code null} (for the
> 
> I think "If {@code parent}" is more correct, since you are implicitly referring to the parameter.

Done.

> src/java.base/share/classes/java/net/URLClassLoader.java line 127:
> 
>> 125:      * classes are visible.
>> 126:      * See {@linkplain ClassLoader##builtinLoaders Run-time Built-in Class Loaders}
>> 127:      * for information on the system class loader and other built-in class loaders.
> 
> Seems more relevant to say "for information on the bootstrap class loader and other built-in class loaders." since you specifically mention bootstrap loader in the first sentence.

Fixed in the latest update of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255429
PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255846
PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255640

From alanb at openjdk.org  Fri May 30 07:17:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 07:17:57 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v4]
In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
Message-ID: <21HVYE8jgNoGmFPIpAqTSYtdH7l1EWr_qUViokvicOY=.0b72b66b-56c6-4d71-b323-506d81a7dea2@github.com>

On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - replace system class loader reference with bootstrap class loader
>  - remove "the"
>  - {@code null} instead of null

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2880392639

From jpai at openjdk.org  Fri May 30 07:17:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 07:17:57 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v4]
In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
Message-ID: <ffU-FfNG7h9PtfTKsdM4fCrt4FrhKLFOU7-6XMyh2PY=.92497a72-f562-45bd-95ca-1c089619caf5@github.com>

On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - replace system class loader reference with bootstrap class loader
>  - remove "the"
>  - {@code null} instead of null

The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8358126

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25517#issuecomment-2921445858

From jnimeh at openjdk.org  Fri May 30 07:19:54 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 30 May 2025 07:19:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28]
In-Reply-To: <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
Message-ID: <KnJppZKgbiPeX79x3edHcOczGTWPbiSp8cvlZnOZjsk=.94071cc4-4fe0-4a5d-a148-cac173eb71cf@github.com>

On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last minute codereview comments

Marked as reviewed by jnimeh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2880396913

From michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v14]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <pUfglxcMEvXttRaI8rASxa75JI0HVHTATct7tYPm-zI=.80721996-2a07-4ed0-861e-da5cf021bdff@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/34f20c9a..cf5233c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12-13

  Stats: 21 lines in 6 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
Message-ID: <F1Awcr4qDnApE7VJu2PJAqhh51UTiLTZYU_VIdEahDw=.c6d106ab-58cb-41c3-a8d8-01f50029f222@github.com>

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional callsites identified by Mark S.

Thanks for the suggestions. I have committed all of them except for two. One, I will modify in another way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921687319

From michaelm at openjdk.org  Fri May 30 09:39:36 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:39:36 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14
  Stats: 984 lines in 47 files changed: 711 ins; 101 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From michaelm at openjdk.org  Fri May 30 10:32:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:32:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@github.com>
Message-ID: <P96m60ysmbCYcE3X7wab62zI3WsIiPGnaJtVxE-awLo=.59112bf2-ede7-428f-a407-b77b7101983e@github.com>

On Fri, 30 May 2025 09:39:36 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

The last change to java.net.HostPortrange (renaming the constructor parameter) has caused a problem. The parameter is hiding a field of the same name. I need to fix that now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921954327

From michaelm at openjdk.org  Fri May 30 10:44:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:44:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Fixed problem with j.n.HostPortRange

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/462ee011..3eec6c03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14-15

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From alanb at openjdk.org  Fri May 30 10:47:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:47:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
Message-ID: <VYoQ0Q223Fc-URXr9oD7NgN5L8Sg9b0o7uUnS5OD3X4=.bc219762-0d1c-4df3-9c8b-d27c7f854aee@github.com>

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java line 50:

> 48:         if (index == -1)
> 49:             throw new MalformedURLException(
> 50:                 formatMsg("no !/ found in url spec%s", filterJarName(s).prefixWith(": ")));

JMOD files can only be used at compile time and link time. So I think you can drop the changes jmod stream handler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115650070

From mullan at openjdk.org  Fri May 30 13:07:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 13:07:55 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v4]
In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
Message-ID: <XT6nFJApFhLZiXJu1WeZM8WtdlYlB5XHoMxUUzBFkQM=.12c8110e-941f-4da1-adea-e2166caa8d10@github.com>

On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - replace system class loader reference with bootstrap class loader
>  - remove "the"
>  - {@code null} instead of null

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2881305741

From mullan at openjdk.org  Fri May 30 13:34:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 13:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
Message-ID: <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/conf/security/java.security line 1282:

> 1280: # Exception messages may include potentially sensitive information such as file
> 1281: # names, host names, or port numbers. By default, socket related exceptions
> 1282: # have this information restricted (meaning the sensitive details are removed).

I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115938656

From dfuchs at openjdk.org  Fri May 30 14:44:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 May 2025 14:44:12 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v2]
In-Reply-To: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
Message-ID: <b0b1aeMPGiuFk9VGwARZgFzj5AreCnteR7o8G7MXN-U=.b69823e7-67de-4ede-94ab-54b346e339d6@github.com>

> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
> 
> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
> 
> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
> 
> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

Daniel Fuchs 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:

 - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Avoid unnecessary volatile reads
 - 8357639

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25416/files
  - new: https://git.openjdk.org/jdk/pull/25416/files/6abcee8f..ad1b28a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=00-01

  Stats: 36183 lines in 726 files changed: 27029 ins; 5883 del; 3271 mod
  Patch: https://git.openjdk.org/jdk/pull/25416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25416/head:pull/25416

PR: https://git.openjdk.org/jdk/pull/25416

From michaelm at openjdk.org  Fri May 30 14:52:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 14:52:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
 <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
Message-ID: <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>

On Fri, 30 May 2025 13:32:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed problem with j.n.HostPortRange
>
> src/java.base/share/conf/security/java.security line 1282:
> 
>> 1280: # Exception messages may include potentially sensitive information such as file
>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>> 1282: # have this information restricted (meaning the sensitive details are removed).
> 
> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."

# Exception messages relating to Jar files and exceptions containing user
# identity information are also restricted by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116074735

From hchao at openjdk.org  Fri May 30 14:57:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 30 May 2025 14:57:57 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27]
In-Reply-To: <NlEJHrt7oqj710XWuYNXAReEveNeVFoaI4eDYXCDjbo=.10aa0cf5-51bd-44fb-8402-895aaa6a5176@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <oSr0PubC4HucFkUyOBt5Sl7rEBPr8ZBMYEXGfC-6uf4=.40baaa88-4c3f-456c-9fe5-c3b6103e8e3e@github.com>
 <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com>
 <NlEJHrt7oqj710XWuYNXAReEveNeVFoaI4eDYXCDjbo=.10aa0cf5-51bd-44fb-8402-895aaa6a5176@github.com>
Message-ID: <mqOY7Tirvzp0bcNi9WhLNv5kTK-rOPsTqUNa6AT4kWs=.7f04ac1d-306f-427f-b5e8-59b61cff4fe6@github.com>

On Fri, 30 May 2025 01:25:37 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494:
>> 
>>> 1492:             if (exporterMasterSecret == null) {
>>> 1493:                 throw new RuntimeException(
>>> 1494:                         "Exporter master secret not captured");
>> 
>> Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`.
>> 
>> Same question in `useTLS10PlusSpec()` for the two randoms.
>
> @wangweij asked if `SSLSession` are ever in a partially completed state.  The answer is yes, during handshaking the `SSLSocket/SSLEngine.getHandshakeSession()` methods can return `SSLSession` that is incomplete.  As such, it makes more sense for this to be an `IllegalArgumentException`.  
> 
> Drafted the CSR, made the update, and refinalized it.  Hopefully the wording is acceptable.  ;)

Updates look good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2116081641

From hchao at openjdk.org  Fri May 30 14:57:56 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 30 May 2025 14:57:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28]
In-Reply-To: <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <rXHSkMiG5snVmFRF1WO6J60GPm9ZZDcrOAlwGx58Lso=.88abf771-e0bb-4d6b-a57f-d47a6f7c8da4@github.com>
Message-ID: <Oq6yTgNpMzNo_WVdxbeJBuCGJirQ-lun181nX8YJwvo=.ef91a782-dd56-4c86-abdb-77bdcc4cdc08@github.com>

On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last minute codereview comments

Marked as reviewed by hchao (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2881612431

From mullan at openjdk.org  Fri May 30 17:35:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 17:35:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
 <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
 <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>
Message-ID: <f8m8PjPiFHbTl_iC58jZRmiL3f7QGCvpKnWHLp96m6o=.891a55c7-0e96-4b64-ad91-934b2d9d3f6e@github.com>

On Fri, 30 May 2025 14:50:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1282:
>> 
>>> 1280: # Exception messages may include potentially sensitive information such as file
>>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>>> 1282: # have this information restricted (meaning the sensitive details are removed).
>> 
>> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.
>
> Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."
> 
> # Exception messages relating to Jar files and exceptions containing user
> # identity information are also restricted by default.

I would change "Jar" to "JAR" as I think that is the more common form and used in other places in this file. Looks fine otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116314192

From mullan at openjdk.org  Fri May 30 19:30:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 19:30:58 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
Message-ID: <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>

On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - changed boolean array initialization
>  - 8325766: Review seclibs tests for cert expiry

test/lib/jdk/test/lib/security/CertificateBuilder.java line 109:

> 107:      */
> 108:     public static CertificateBuilder newCertificateBuilder(String subjectName,
> 109:                            PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)

My suggestion is to make this a regular constructor and have an additional method that sets the certificate lifetime as a `Duration` parameter, ex:

`new CertificateBuilder(subject, pubKey, caPubKey, keyUsage).withValidity(Duration.ofHours(1));`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2116514041

From michaelm at openjdk.org  Fri May 30 20:50:37 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:50:37 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v17]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <kvmaa0cxCoqK7HE2kVuAIUDf4O_qDGucd7gd7Xje2bQ=.83fe5bdf-26e2-4672-b899-b0a6b61f508b@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  doc update to java.security

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/3eec6c03..5970c2b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15-16

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From michaelm at openjdk.org  Fri May 30 20:58:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:58:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v18]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <FNrGMio3jb29ipNfsDQi7WkE4YTdV57DePH2cfJ_jx8=.a2ff9393-5a98-4e58-a806-cc9055d87b13@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - doc update to java.security
 - removed jmod/Handler change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/5970c2b3..4aad0141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16-17

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From wetmore at openjdk.org  Fri May 30 21:32:38 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 30 May 2025 21:32:38 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v29]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <M2sh0ip8pNaL08whQ8zDJkgKf0PBe0PS7ml-P8PES5U=.df5a8e33-a998-4559-bdef-d7922ae87069@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is complete/approved.
> 
> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' into JDK-8341346
 - Merge branch 'master' into JDK-8341346
 - Last minute codereview comments
 - Merge branch 'master' into JDK-8341346
 - Remove TlsExporterKeyingMaterial for now.  Can add later if needed.
 - Merge branch 'master' into JDK-8341346
 - Merge branch 'master' into JDK-8341346
 - Added PKCS11 testing
 - Minor bug
 - Missed one change
 - ... and 30 more: https://git.openjdk.org/jdk/compare/db340e54...07fda411

-------------

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=28
  Stats: 1043 lines in 9 files changed: 1023 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From jnimeh at openjdk.org  Fri May 30 21:58:38 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 30 May 2025 21:58:38 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30]
In-Reply-To: <DvV82DCoP8wXowtRRoMpF-kz-5RspcT5AUf8pNYBkkQ=.40ccf6dc-7fdf-4257-837d-27aaace7357c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <DvV82DCoP8wXowtRRoMpF-kz-5RspcT5AUf8pNYBkkQ=.40ccf6dc-7fdf-4257-837d-27aaace7357c@github.com>
Message-ID: <uYytqcj69KrQWNA90HdBr7EgOAfaty2Ffa1QHkSPwh0=.ed2f9e0e-c898-432a-8dcc-c1cc1f39aa5c@github.com>

On Fri, 30 May 2025 21:54:55 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolved Merge Problem

Marked as reviewed by jnimeh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2882629576

From wetmore at openjdk.org  Fri May 30 21:58:38 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 30 May 2025 21:58:38 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <DvV82DCoP8wXowtRRoMpF-kz-5RspcT5AUf8pNYBkkQ=.40ccf6dc-7fdf-4257-837d-27aaace7357c@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is complete/approved.
> 
> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Resolved Merge Problem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/07fda411..d0cf6917

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=28-29

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From hchao at openjdk.org  Fri May 30 22:01:56 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 30 May 2025 22:01:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30]
In-Reply-To: <DvV82DCoP8wXowtRRoMpF-kz-5RspcT5AUf8pNYBkkQ=.40ccf6dc-7fdf-4257-837d-27aaace7357c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
 <DvV82DCoP8wXowtRRoMpF-kz-5RspcT5AUf8pNYBkkQ=.40ccf6dc-7fdf-4257-837d-27aaace7357c@github.com>
Message-ID: <CrENt3__OnGMKoOtqTRihhPoRdp4nTh0ahvpNhau3Y8=.003824e3-c9fe-4724-8df2-407e09498eeb@github.com>

On Fri, 30 May 2025 21:58:38 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is complete/approved.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolved Merge Problem

Marked as reviewed by hchao (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2882635456

From wetmore at openjdk.org  Fri May 30 23:09:00 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 30 May 2025 23:09:00 GMT
Subject: Integrated: 8341346: Add support for exporting TLS Keying Material
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <292ACWvjhRB891IoH8NFr12kx8tjJsDBunsx7LsuhT4=.3e57f29d-370d-40ea-8dd8-7c03a9583313@github.com>

On Wed, 30 Apr 2025 22:39:47 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is complete/approved.
> 
> Tests include new unit tests for TLSv1-1.3.  Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

This pull request has now been integrated.

Changeset: 2926435d
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2926435d228f21a227763ff4efcf32e511aa258a
Stats:     1043 lines in 9 files changed: 1023 ins; 0 del; 20 mod

8341346: Add support for exporting TLS Keying Material

Reviewed-by: hchao, jnimeh, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/24976

From jpai at openjdk.org  Sat May 31 13:05:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 13:05:56 GMT
Subject: RFR: 8228773: URLClassLoader constructors should include API note
 warning that the parent should not be null [v4]
In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
 <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com>
Message-ID: <C3nmzK8FH2HEziJLz45MSWPF8vGPnOKmT7Iuc8QD8nc=.b86ce555-4242-443d-b015-d85284585d89@github.com>

On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
>> 
>> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
>> 
>> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
>> 
>> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
>> 
>> 
>> import java.net.*;
>> 
>> public class Test {
>>     public static void main(String[] args) throws Exception {
>>         System.out.println("testing against Java " + System.getProperty("java.version"));
>> 
>>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
>> 
>>     }
>> }
>> 
>> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
>> 
>> 
>> testing against Java 24
>> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>>     at Test.main(Test.java:8)
>> 
>> 
>> No new tests have been introduced and existing tes...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - replace system class loader reference with bootstrap class loader
>  - remove "the"
>  - {@code null} instead of null

Thank you all for the reviews. The CSR has been approved. I'll go ahead with the integration now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25517#issuecomment-2925161327

From jpai at openjdk.org  Sat May 31 13:05:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 13:05:57 GMT
Subject: Integrated: 8228773: URLClassLoader constructors should include API
 note warning that the parent should not be null
In-Reply-To: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
References: <x1Lr2iBTqz8kXKAvcJQmb4x5MGNKDUrHQ-vTzMjLgXw=.2b3523a8-bc35-4448-8096-48dde6444e4d@github.com>
Message-ID: <JT2b5FfRW4GPuctvXXPAG4UPC6gy2b1QS9WjdjSKaAE=.c4030b45-6281-4288-a6fb-c3e7c9bda7d5@github.com>

On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773?
> 
> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes.
> 
> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders.
> 
> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider:
> 
> 
> import java.net.*;
> 
> public class Test {
>     public static void main(String[] args) throws Exception {
>         System.out.println("testing against Java " + System.getProperty("java.version"));
> 
>         final ClassLoader cl = new URLClassLoader(new URL[0], null);
>         final Class<?> klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module
>         System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader());
> 
>     }
> }
> 
> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`:
> 
> 
> testing against Java 24
> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet
>     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
>     at Test.main(Test.java:8)
> 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
> 
> Once we settle on th...

This pull request has now been integrated.

Changeset: 84002d12
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84002d12ed83c8254422fdda349aa647422d0768
Stats:     57 lines in 2 files changed: 42 ins; 0 del; 15 mod

8228773: URLClassLoader constructors should include API note warning that the parent should not be null

Reviewed-by: alanb, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/25517

From egahlin at openjdk.org  Sat May 31 13:18:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 31 May 2025 13:18:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
Message-ID: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>

Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).

Testing: test/jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25559/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351594
  Stats: 1230 lines in 37 files changed: 1028 ins; 87 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From mgronlun at openjdk.org  Sat May 31 20:15:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:15:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:

> 37:  * example, {@code "100/s"}).
> 38:  * <p>
> 39:  * If the event class annotated with {@code Throttle} are filtered by other

"is filtered"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118216821

From mgronlun at openjdk.org  Sat May 31 20:19:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:19:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <99eWsd--g2GrdhR2r9_HY7JMWK2RZJZ7ahwatYCvXU4=.50bb0e3f-5ee2-41b7-bf66-0d83e8d08c52@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:

> 146:             return true;
> 147:         }
> 148:         if (superClass != null) {

Does this also need to search superClass's super?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118221175

From mgronlun at openjdk.org  Sat May 31 21:12:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:12:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <vKdKE5fLsvlLISgHCtv-hd4fsDPY9ziU6odImrFsAGM=.441615c8-e981-46fd-9a37-39218703002e@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:

> 254:             // }
> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);

Can issue a dup() here if you want to avoid the second aload(0).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118257554

From mgronlun at openjdk.org  Sat May 31 21:17:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:17:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Dbuu94cHaFlQPlttifkqqPt53bkI1_7PouvQlThOw40=.f7a88efa-c25a-408d-8fc8-4d4ac6d74898@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:

> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);
> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);

In native,we use the endTime for duration events? Is there a need to synchronize the two?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118261907

From mgronlun at openjdk.org  Sat May 31 21:27:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:27:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:

> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);

Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:

> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
> 589:         codeBuilder.aload(0);
> 590:         expression.accept(codeBuilder);

dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:

> 57:     // static boolean shouldThrottleCommit(long timestamp)
> 58:     public boolean shouldThrottleCommit(long timestamp) {
> 59:         return throttler.sample(timestamp);

Can we assert on isEnabled?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 77:

> 75:             return rawDuration;
> 76:         }
> 77:         long endTime = startTime + rawDuration;

I see now that you are using endTime as well, nice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272073
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272829
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118277498
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118279057

From mgronlun at openjdk.org  Sat May 31 21:38:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:38:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <i-9qmnjV-4cag2uwXDkuIsfyZKhgx8vm_wJHJinIz1Y=.8b8466a6-8e87-4327-87ee-b3fdb6591af2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:

> 60:     // Not synchronized in fast path, but uses volatile reads.
> 61:     public boolean sample(long ticks) {
> 62:         if (disabled) {

This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 74:

> 72:                 }
> 73:             }
> 74:             return activeWindow.sample();

In native, a ticks value outside of the window is not returned true.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 76:

> 74:             return activeWindow.sample();
> 75:         }
> 76:         return current.sample();

This could result in sampling in an already expired window.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118281909
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118282232
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118283830

From Shruthi.Shruthi1 at ibm.com  Sat May 31 19:12:45 2025
From: Shruthi.Shruthi1 at ibm.com (Shruthi .)
Date: Sat, 31 May 2025 19:12:45 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11S
In-Reply-To: <SJ0PR15MB466351A414A67F29EC88EC19CC98A@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663E34342AC2F9AC8A876AACCFC2@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <cb761fa6-3b2e-4752-846d-3a7ff28861ae@oracle.com>
 <SJ0PR15MB4663D70B7F45120E4B75956DCCC62@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB4663242E65CB63DD64272DE0CCC32@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <2633ad7f-c278-4f88-bcbc-ec8211d7ee48@oracle.com>
 <SJ0PR15MB46631AD45E4B42C4A39F008DCCC22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ef07a775-f954-4051-a0e9-59100c7715c3@oracle.com>
 <SJ0PR15MB46638A0DE787D32EFABAA8E1CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ec39b10b-5271-41cf-aa7f-d3f915ee0a18@oracle.com>
 <SJ0PR15MB4663123A5C03544060DC27E9CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <8861a349-6446-4326-b168-e9594aeef70b@oracle.com>
 <SJ0PR15MB4663C04ADCBC69EFEF78C71CCCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <d79fdfb8-e717-4c73-8c0c-3fae0fadce01@oracle.com>
 <SJ0PR15MB4663218DFB930F6B6EF9F211CCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
 <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB466351A414A67F29EC88EC19CC98A@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <SJ0PR15MB4663D5C27435718507DBA5C0CC60A@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan,

I wanted to follow up on the update I shared earlier
I?ve successfully backported the preClose re-order changes to JDK 17 and ran the Race.java test case 500 times. It passed consistently without any failures. For validation, I also ran the test without the patch, and it failed on the first iteration. I ran the tests under java/nio to see if there is any regression and all the testcases are passing.
Currently, we are running the tests under java/net.

  *
Do you recommend running any additional test groups?
  *
Also, can we proceed with porting the preClose re-order fix to headstream?

Please let me know your thoughts.
Thanks
Shruthi

________________________________
From: Shruthi . <Shruthi.Shruthi1 at ibm.com>
Sent: Friday, May 23, 2025 6:27 PM
To: Alan Bateman <alan.bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: Re: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

Hi Alan,
I was able to backport the preClose re-order changes to JDK17 and I executed the Race.java testcase 500 times, and it passed consistently  without any failures.
I also tested Race.java without the patch and it fails in the first iteration it self.
We are running the tests under java/net and java/nio to check if there is any regression. Do you think I should run any other tests?
Also, can we proceed with porting preClose re-order fix to headstream?

Thanks
Shruthi
________________________________
From: Shruthi . <Shruthi.Shruthi1 at ibm.com>
Sent: Tuesday, April 8, 2025 6:03 PM
To: Alan Bateman <alan.bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: Re: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

Hi Alan,

I was able to successfully build the OpenJDK headstream with the preClose reordering patch, which you have shared: pending_signals.patch<https://bugs.openjdk.org/secure/attachment/113740/pending_signals.patch>.
To validate the build, I executed the Race.java testcase 500 times, and it passed consistently without any failures.
For comparison, I ran the same testcase without the patch, and it failed on the 86th iteration.

Thanks
Shruthi
________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Friday, March 14, 2025 3:00 PM
To: Shruthi . <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

On 14/03/2025 09:?22, Shruthi . wrote: The issue which we are seeing is not reproducible in JDK21 or higher version Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that

On 14/03/2025 09:22, Shruthi . wrote:
The issue which we are seeing is not reproducible in JDK21 or higher version

Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that would help you reproduce it with main line.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250531/0cd8d4ef/attachment-0001.htm>