From serb at openjdk.org  Thu Jan  1 04:24:24 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jan 2026 04:24:24 GMT
Subject: Withdrawn: 8374320: Update copyright year to 2025 for java.net.http in
 files where it was missed
In-Reply-To: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
References: <i1BM1nHJu2w611rqvMcufkN4_ommsmNTzqCAoH6ZoI0=.82c59e6f-53ac-47c9-8f00-aa6db1c0f93d@github.com>
Message-ID: <zYIlVtcK68eED3BdTEfHQQl4ow1lpsna9z9Ozp5zGwE=.a8399be1-3dc7-47df-9942-0887d23da6d8@github.com>

On Wed, 24 Dec 2025 02:05:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `
> git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

This pull request has been closed without being integrated.

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

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

From lucy at openjdk.org  Thu Jan  1 14:42:01 2026
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 1 Jan 2026 14:42:01 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
Message-ID: <l4jn5ThlTxQ7LO1VtRoG4EMMdsegZuy0FLXvGkiqEsA=.e03fa985-e5ab-4a44-99fc-69cb696690c5@github.com>

On Thu, 18 Dec 2025 16:39:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
>> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the message as suggested by jaikiran

Changes look good.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28851#pullrequestreview-3621895310

From alanb at openjdk.org  Thu Jan  1 15:34:01 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jan 2026 15:34:01 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
Message-ID: <mW5rJcG1MbvJx-o_Nmiuer-5gy1YLFPLEN7k9gdOHbk=.3c580f14-ead1-4363-b8d2-eda5ccdc1612@github.com>

On Thu, 18 Dec 2025 16:39:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
>> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the message as suggested by jaikiran

> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.

Would it be possible to say which method or test failure lead to this? I'm wondering how we end up calling it with an IPv6 address when not supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/28851#issuecomment-3703828941

From duke at openjdk.org  Thu Jan  1 16:12:02 2026
From: duke at openjdk.org (EunHyunsu)
Date: Thu, 1 Jan 2026 16:12:02 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
Message-ID: <zaWDe3ePQbOh_dQ1QA_l-TL2nUVDCdoNz5U8BTs87eI=.adb888ec-483a-4fa0-9e66-e6a2d6d18de4@github.com>

On Fri, 19 Dec 2025 12:11:11 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> ### Problem
>> 
>>   When the HTTP/2 client receives a GOAWAY frame with a non-zero error code, the current implementation discards both the error code and debug data. Users only see generic "Connection closed by peer" errors without any information about why the server terminated the connection.
>> 
>>   ### Solution
>> 
>>   Per [RFC 9113 ?5.4.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.4.1), a GOAWAY frame with a non-zero error code indicates a connection error requiring immediate closure. This fix:
>> 
>>   1. **Distinguishes** graceful shutdown (NO_ERROR) from connection errors
>>   2. **Preserves** error code and debug data in exception messages
>>   3. **Categorizes** streams based on `lastStreamId`:
>>      - Streams with ID > `lastStreamId`: Marked as unprocessed for automatic retry
>>      - Streams with ID ? `lastStreamId`: Failed with detailed error information
>> 
>>   ### Changes
>> 
>>   **Core Implementation** (`Http2Connection.java`):
>>   - Modified `handleGoAway()` to check error code and route appropriately
>>   - Added `handleGoAwayWithError()` method that:
>>     - Extracts error code and debug data from GOAWAY frame
>>     - Creates meaningful error messages with error name, hex code, and debug data
>>     - Properly categorizes streams for retry or failure
>> 
>>   **Test Infrastructure**:
>>   - `Http2TestServerConnection.sendGoAway(int, int, byte[])`: Supports custom error codes
>>   - `Http2TestExchangeImpl.getServerConnection()`: Accessor for test handlers
>>   - `GoAwayWithErrorTest`: Verifies proper error propagation
>> 
>>   ### Example
>> 
>>   **Before:**
>>   IOException: Connection closed by peer
>> 
>>   **After:**
>>   IOException: Received GOAWAY with error code Protocol error (0x1): Invalid HEADERS frame
>> 
>>   ### Testing
>> 
>>   - New `GoAwayWithErrorTest` passes
>>   - Existing HTTP/2 tests unaffected (NO_ERROR path unchanged)
>>   - Backward compatible (no public API changes)
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371903: Use stateLock to synchronize stream iteration and connection closure

Hi all, Just following up to see if anyone has a chance to take a look at this.  
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3703858581

From mbaesken at openjdk.org  Fri Jan  2 08:26:57 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 2 Jan 2026 08:26:57 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
Message-ID: <67h3VvwrDDwHRCfIQxHCux3yHg6zz9907-QCm63McFw=.626701cb-bab6-4c5a-904e-561e41541f0f@github.com>

On Thu, 18 Dec 2025 16:39:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
>> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the message as suggested by jaikiran

Hi Alan, it was the test  javax/net/ssl/HttpsURLConnection/SubjectAltNameIP.java .
See  https://bugs.openjdk.org/browse/JDK-8373676  .


Error :
command: main SubjectAltNameIP [::1]
reason: User specified action: run main/othervm SubjectAltNameIP [::1]
started: Sun Dec 14 21:22:53.422 CET 2025
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules java.base --add-exports java.base/sun.net.util=ALL-UNNAMED
Process id: 14723
finished: Sun Dec 14 21:22:59.728 CET 2025
elapsed time (seconds): 6.306
----------configuration:(4/101)----------
Boot Layer
  add modules: java.base
  add exports: java.base/sun.net.util ALL-UNNAMED

----------System.out:(0/0)----------
----------System.err:(26/1574)----------
java.lang.RuntimeException: Server failed to start.
at SubjectAltNameIP.doClientSide(SubjectAltNameIP.java:139)
at SubjectAltNameIP.<init>(SubjectAltNameIP.java:189)
at SubjectAltNameIP.main(SubjectAltNameIP.java:176)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1516)
**Caused by: java.net.SocketException: Protocol family unavailable**
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:525)
at java.base/sun.nio.ch.Net.bind(Net.java:514)
at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:641)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:326)
at java.base/java.net.ServerSocket.<init>(ServerSocket.java:222)
at java.base/javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:155)
at java.base/sun.security.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:80)
at java.base/sun.security.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:87)
at SubjectAltNameIP.doServerSide(SubjectAltNameIP.java:106)
at SubjectAltNameIP.lambda$startServer$0(SubjectAltNameIP.java:203)
... 1 more

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

PR Comment: https://git.openjdk.org/jdk/pull/28851#issuecomment-3704734885

From mbaesken at openjdk.org  Fri Jan  2 08:26:59 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 2 Jan 2026 08:26:59 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <l4jn5ThlTxQ7LO1VtRoG4EMMdsegZuy0FLXvGkiqEsA=.e03fa985-e5ab-4a44-99fc-69cb696690c5@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
 <l4jn5ThlTxQ7LO1VtRoG4EMMdsegZuy0FLXvGkiqEsA=.e03fa985-e5ab-4a44-99fc-69cb696690c5@github.com>
Message-ID: <U6HLkl98UKJMpjv5HpwQQgVXZUEbNPbYnjR4VdiI1x4=.f51e069e-7214-4402-9ec2-ac8eb6691707@github.com>

On Thu, 1 Jan 2026 14:39:14 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Changes look good.

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/28851#issuecomment-3704735509

From syan at openjdk.org  Sat Jan  3 02:08:21 2026
From: syan at openjdk.org (SendaoYan)
Date: Sat, 3 Jan 2026 02:08:21 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
Message-ID: <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>

> Hi all,
> 
> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
> 
> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,

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

  use "jdk.test.lib.Utils.adjustTimeout"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29012/files
  - new: https://git.openjdk.org/jdk/pull/29012/files/12b21e72..9c7e744e

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

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

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

From syan at openjdk.org  Sat Jan  3 02:08:24 2026
From: syan at openjdk.org (SendaoYan)
Date: Sat, 3 Jan 2026 02:08:24 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <p7h_EQJWCz9bEVWdiGZiU51tVBu-uJYN4ReeWp-evws=.ffe0f3d2-1cfc-4a73-b175-b963c56b741c@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
 <p7h_EQJWCz9bEVWdiGZiU51tVBu-uJYN4ReeWp-evws=.ffe0f3d2-1cfc-4a73-b175-b963c56b741c@github.com>
Message-ID: <AO2ltHVOymT37t8ZEIW0l8lP4CKaIw1W00_ST2zknJM=.54960e57-429e-40ca-a4d7-9b45f25fb148@github.com>

On Wed, 31 Dec 2025 11:04:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use "jdk.test.lib.Utils.adjustTimeout"
>
> test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java line 81:
> 
>> 79:     protected static final Duration REQUEST_TIMEOUT =
>> 80:             Duration.ofMillis(Long.parseLong(System.getProperty("test.requestTimeoutMillis"))
>> 81:             * timeoutFactor);
> 
> Can we use `jdk.test.lib.Utils::adjustTimeout` instead of manually reading and applying the `test.timeout.factor` system property?

Thanks for the advice. 
Since jdk.test.lib.Utils has some duplicate element name to jdk.internal.net.http.common.Utils, So I use the fully qualified name of jdk.test.lib.Utils.adjustTimeout.

> test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java line 111:
> 
>> 109:                     .ofMillis(RESPONSE_FAILURE_WAIT_DURATION_MILLIS)
>> 110:                     .multipliedBy(RETRY_LIMIT)
>> 111:                     .multipliedBy(timeoutFactor);
> 
> Similar to what we do with `REQUEST_TIMEOUT`, can we instead use `adjustTimeout` while initializing the `RESPONSE_FAILURE_WAIT_DURATION_MILLIS`?

Same as above. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29012#discussion_r2658647452
PR Review Comment: https://git.openjdk.org/jdk/pull/29012#discussion_r2658647576

From alan.bateman at oracle.com  Sat Jan  3 06:22:34 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 3 Jan 2026 06:22:34 +0000
Subject: Request to work on JDK-8374344
In-Reply-To: <f41b2e75-69e4-4ebf-b822-d62474a7322b@oracle.com>
References: <CAKz31GBJ+Q9J7i2Tnuybhp1fXh6nV5gWAfCy9E5eFJ-cs1-C3g@mail.gmail.com>
 <f41b2e75-69e4-4ebf-b822-d62474a7322b@oracle.com>
Message-ID: <f7bfc532-198e-4295-8829-b3130a0710db@oracle.com>


This might be tricky to specify, and could end up with some implNote to 
document the behavior of the JDK protocol handler. In any case, net-dev 
(rather than core-libs-dev) is the place to discuss this.

-Alan


On 02/01/2026 20:02, Alexey Ivanov wrote:
> Hi Vignesh,
>
> This question belongs in core-libs-dev because the component of the 
> issue is *core-libs*.
>
> On 2025-12-27 15:53, Vignesh Sadanki wrote:
>> Hi everyone,
>>
>> I'm new to OpenJDK and interested in contributing. I came across bug 
>> JDK-8374344 ("Clarifying HttpURLConnection.disconnect() Behavior 
>> Regarding Resource Management and Connection Pooling") and would like 
>> to work on it.
>>
>> Could someone confirm if this bug is available for me to take, and if 
>> there are any guidelines I should follow?
>>
>> Thanks,
>> Vignesh Sadankae


From alanb at openjdk.org  Sat Jan  3 07:27:15 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Jan 2026 07:27:15 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <67h3VvwrDDwHRCfIQxHCux3yHg6zz9907-QCm63McFw=.626701cb-bab6-4c5a-904e-561e41541f0f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
 <67h3VvwrDDwHRCfIQxHCux3yHg6zz9907-QCm63McFw=.626701cb-bab6-4c5a-904e-561e41541f0f@github.com>
Message-ID: <jpa-hOmIvF6jtsp2UbAv71QALEASO2Y-pXpIXae4YHE=.95ade2d2-7f94-4db1-8891-1eece1529820@github.com>

On Fri, 2 Jan 2026 08:22:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, it was the test javax/net/ssl/HttpsURLConnection/SubjectAltNameIP.java .
See https://bugs.openjdk.org/browse/JDK-8373676 .

Thanks, just checking that there was an issue to track fixing the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28851#issuecomment-3706857795

From jpai at openjdk.org  Sun Jan  4 04:20:02 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 4 Jan 2026 04:20:02 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
Message-ID: <N4eEWgURd4CiWK71YQuSU2fnslX6Sste4e0tXNYNDE4=.c23ea23b-35b1-4e4f-aa14-dad0fdd1adb3@github.com>

On Thu, 18 Dec 2025 16:39:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
>> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the message as suggested by jaikiran

Hello Matthias, this looks OK to me. Please run tier2 tests before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28851#pullrequestreview-3624660969

From dholmes at openjdk.org  Sun Jan  4 21:05:50 2026
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 4 Jan 2026 21:05:50 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
 <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
Message-ID: <C5Kjf9MBytHy6qJfUI9BcjZWHyWWZxdtHqLwovwl0cI=.5058bfbb-70bc-4cd0-bcf7-2916f7d0f1bf@github.com>

On Sat, 3 Jan 2026 02:08:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
>> 
>> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use "jdk.test.lib.Utils.adjustTimeout"

I've updated the JBS report as we have seen further timeouts in related tests with no use of -Xcomp.

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

PR Comment: https://git.openjdk.org/jdk/pull/29012#issuecomment-3708422500

From mbaesken at openjdk.org  Mon Jan  5 08:28:03 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Jan 2026 08:28:03 GMT
Subject: RFR: 8373704: Improve
 "SocketException: Protocol family unavailable" message [v2]
In-Reply-To: <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
 <jm8ra-AgLByXm9yLgaKItj8HZBMWixYi7JhubdAWUDM=.ec78681e-d484-458c-bb1a-434261c2623f@github.com>
Message-ID: <SVGmMoaw0gD0FvtxhPOwEeVWJXw6Zk1gtBudI1aQZGg=.a5b61182-0351-4048-9bc9-59af5bff3b5f@github.com>

On Thu, 18 Dec 2025 16:39:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
>> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the message as suggested by jaikiran

Thanks for the reviews !  I observed no issues in the  tier2 tests .

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

PR Comment: https://git.openjdk.org/jdk/pull/28851#issuecomment-3709398862

From mbaesken at openjdk.org  Mon Jan  5 08:30:04 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Jan 2026 08:30:04 GMT
Subject: Integrated: 8373704: Improve
 "SocketException: Protocol family unavailable" message
In-Reply-To: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
References: <ZPS8yD-n8Y9YhT5OEfxW636qLx5LRIILMxrb-2Yz5fc=.4121acc4-895a-410f-bd42-8ee4e58699f8@github.com>
Message-ID: <QBzKvIcMBOJv5zs-O-WNTZ_Oyb2-n_NnNgYBN-zruv4=.d0d32144-ad07-4792-a4e3-1a66d2a02a16@github.com>

On Tue, 16 Dec 2025 15:18:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8373676](https://bugs.openjdk.org/browse/JDK-8373676)
> we noticed a "SocketException: Protocol family unavailable" because of missing ipv6 support. We could improve this exception and tell that the ipv6 support is not available or something related.

This pull request has now been integrated.

Changeset: 16303822
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/163038222a371c07aff8bce50eee55bb389104d0
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8373704: Improve "SocketException: Protocol family unavailable" message

Reviewed-by: lucy, jpai

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

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

From vyazici at openjdk.org  Mon Jan  5 10:02:58 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 5 Jan 2026 10:02:58 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
 <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
Message-ID: <gtYWjDooy_Jf1KI2djFmfC9byllOEodISBN7zaIkAQc=.d043a142-bcdf-4489-a747-c4587fe3e5ea@github.com>

On Sat, 3 Jan 2026 02:08:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
>> 
>> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use "jdk.test.lib.Utils.adjustTimeout"

Thanks so much, @sendaoYan!

I've verified that `TimeoutResponseBodyTest` passes on 9c7e744eb35 with 50 repetitions with and without `-Xcomp` provided.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29012#pullrequestreview-3626203301

From mdonovan at openjdk.org  Mon Jan  5 13:17:25 2026
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 5 Jan 2026 13:17:25 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v6]
In-Reply-To: <iWeGtVvsrO8_8f-cTWXKp1sNTNh2ZyoaEewCeAlLFDA=.1d320ee2-e7ce-418c-bbfd-ee7e79676b6a@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <iWeGtVvsrO8_8f-cTWXKp1sNTNh2ZyoaEewCeAlLFDA=.1d320ee2-e7ce-418c-bbfd-ee7e79676b6a@github.com>
Message-ID: <QL63V-o4SeyiQULm5KmD_qQk3D4nJ4jP3SxaA3steWg=.34057286-20c0-453b-bc57-2ca399b455df@github.com>

On Thu, 14 Aug 2025 12:14:48 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:
> 
>   addressing comments

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 47:

> 45:  * @library /test/lib
> 46:  *
> 47:  * @run main/othervm -Dtest.separateThreads=false CloseKeepAliveCached false

The `test.separateThreads` property is used to statically set `separateServerThread` on line 88, but then on line 230, you set `separateServerThread` based on `args[0]`. One of those could go away. I think each `@test` block should only need 1 `@run` instruction, right?

Also, what is being tested differently if the server is in the "sub" thread versus when it is in the "main" thread?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 122:

> 120:              * Signal Client, we're ready for his connect.
> 121:              */
> 122:             serverReady = true;

Change this to a `CountDownLatch`?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 203:

> 201:             http.disconnect();
> 202:         } catch (IOException ioex) {
> 203:             if (sslServerSocket != null) {

Is there a reason for closing the server socket in the client thread? If not, `sslServerSocket` could be made local to `doServerSide()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661448695
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661405377
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2661399349

From bpb at openjdk.org  Mon Jan  5 20:49:23 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Jan 2026 20:49:23 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v19]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <kFhaxXu-xFdJ8f7vJ03SBs-AGWtje9R4exhzQlbED3U=.ff0ecdd9-8284-452f-a6a8-7102cc61fb62@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 19 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/27dbdec2...c7446357

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=18
  Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 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 duke at openjdk.org  Mon Jan  5 23:31:28 2026
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 5 Jan 2026 23:31:28 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v3]
In-Reply-To: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
References: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
Message-ID: <8SLkhjVWhVQcYVc3X2GlG1Gt2VN7U7xGANcVU5VRxmU=.15b61806-afd3-460e-a09e-cc9d78057946@github.com>

> Remaking the PR since I messed up the upstream merge on the other one. See (https://github.com/openjdk/jdk/pull/27751) for the bulk of the previous discussion
> 
> - adds a flag to ExchangeImpl to signal whether the current request is a GET Upgrade request
> - Adds a new `UpgradeInputStream`/`UpgradeOutputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UpgradeInputStream`

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

 - Merge branch 'openjdk:master' into JDK-8368695
 - Merge branch 'master' into JDK-8368695
 - Merge branch 'master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - Create UpgradeOutputStream.java
 - ... and 9 more: https://git.openjdk.org/jdk/compare/de81d389...ac3b5379

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

Changes: https://git.openjdk.org/jdk/pull/27989/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27989&range=02
  Stats: 457 lines in 4 files changed: 449 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27989/head:pull/27989

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

From jpai at openjdk.org  Tue Jan  6 06:30:08 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:30:08 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
Message-ID: <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>

On Thu, 18 Dec 2025 13:53:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

test/jdk/java/net/httpclient/ALPNProxyFailureTest.java line 47:

> 45: public class ALPNProxyFailureTest extends ALPNFailureTest {
> 46: 
> 47:     private static final SSLContext context = SimpleSSLContext.findSSLContext();

Hello Volkan, there seems to be an oversight here - as far as I can see, the call to `SSLContext.setDefault(context)` is no longer being done after this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28771#discussion_r2663789227

From jpai at openjdk.org  Tue Jan  6 06:47:14 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:47:14 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
Message-ID: <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>

On Thu, 18 Dec 2025 13:53:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Thank you for doing this cleanup. Looks simple but is involved because of the number of places this change was required. Apart from one issue to a test change, that I added as a review comment, the rest looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28771#issuecomment-3713347821

From jpai at openjdk.org  Tue Jan  6 06:50:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:50:51 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3629653398

From vyazici at openjdk.org  Tue Jan  6 09:01:22 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 09:01:22 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v5]
In-Reply-To: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
Message-ID: <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>

> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Restore incorrectly removed `SSLContext::setDefault` in `ALPNProxyFailureTest`
 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Merge remote-tracking branch 'upstream/master' into simpleSslHc
 - Make sure `get()` returns the same instance
 - Restore `test/jdk/java/net/httpclient/` changes
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

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

Changes: https://git.openjdk.org/jdk/pull/28771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28771&range=04
  Stats: 974 lines in 179 files changed: 53 ins; 662 del; 259 mod
  Patch: https://git.openjdk.org/jdk/pull/28771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28771/head:pull/28771

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

From vyazici at openjdk.org  Tue Jan  6 09:01:25 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 09:01:25 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
 <4lwNtk0KLDVIiqe9p8aYaUDMTse9boXuJcF2G9hJHGo=.9597ff45-3da9-4865-8a87-084b5984dac1@github.com>
Message-ID: <qawHl-cni-xAcQR5UpdeMrMZkMtF_heWLYHpB9Tlkr4=.e7d68435-0edb-458d-a5ea-94fb5d9ca422@github.com>

On Tue, 6 Jan 2026 06:26:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Make sure `get()` returns the same instance
>>  - Restore `test/jdk/java/net/httpclient/` changes
>>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>>  - Overhaul `SimpleSSLContext` and its usages
>
> test/jdk/java/net/httpclient/ALPNProxyFailureTest.java line 47:
> 
>> 45: public class ALPNProxyFailureTest extends ALPNFailureTest {
>> 46: 
>> 47:     private static final SSLContext context = SimpleSSLContext.findSSLContext();
> 
> Hello Volkan, there seems to be an oversight here - as far as I can see, the call to `SSLContext.setDefault(context)` is no longer being done after this change.

Doh! :facepalm: Fixed in 3204e85f57e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28771#discussion_r2664167892

From jpai at openjdk.org  Tue Jan  6 09:12:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 09:12:18 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v5]
In-Reply-To: <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <jOH1psXH5CpUFpoLm2jS03s8Vr0aC3XnwJFMkn76lMA=.b258ab68-f5ce-486d-bcda-251aa61b6871@github.com>
Message-ID: <frakj_Lr_FEhIyjssXrikC6DW7CM05lksFE3nycln2s=.b0156721-662d-4b2b-a2ad-c69e9d06cbe6@github.com>

On Tue, 6 Jan 2026 09:01:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Restore incorrectly removed `SSLContext::setDefault` in `ALPNProxyFailureTest`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>  - Make sure `get()` returns the same instance
>  - Restore `test/jdk/java/net/httpclient/` changes
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Thank you for the update. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28771#pullrequestreview-3630065748

From vyazici at openjdk.org  Tue Jan  6 10:22:10 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 10:22:10 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods [v4]
In-Reply-To: <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
 <91z1GserVQHgwJNfH6VWSSERKpd7qtyAJL7dY2Ynh24=.da80636c-9d89-4467-985d-6f28fd3d63cc@github.com>
 <hg6GKjrO5C07bVPtvmzvgaX2aVRthjpkRY2WxIzttGE=.c2ddf304-d18f-4690-8ee0-547a3f686890@github.com>
Message-ID: <ucS0Wnfj_vjeriM3sTmAtGzIkcFs-0Q5lQtCm_mRtBg=.e18ee30f-98b6-4189-b739-cc6f3bb991a9@github.com>

On Tue, 6 Jan 2026 06:44:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Merge remote-tracking branch 'upstream/master' into simpleSslHc
>>  - Make sure `get()` returns the same instance
>>  - Restore `test/jdk/java/net/httpclient/` changes
>>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>>  - Overhaul `SimpleSSLContext` and its usages
>
> Thank you for doing this cleanup. Looks simple but is involved because of the number of places this change was required. Apart from one issue to a test change, that I added as a review comment, the rest looks good to me.

Thanks so much for the review @jaikiran.

All `test/jdk/java/net/httpclient/` tests pass on several platforms using b8544bbff7e.

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

PR Comment: https://git.openjdk.org/jdk/pull/28771#issuecomment-3714105562

From vyazici at openjdk.org  Tue Jan  6 10:24:20 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 6 Jan 2026 10:24:20 GMT
Subject: Integrated: 8373515: Migrate "test/jdk/java/net/httpclient/" to
 null-safe "SimpleSSLContext" methods
In-Reply-To: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
Message-ID: <TMjEQubDdKK7tKX5XKO-Bfa8IewA4rpV5D1OUCb_3gk=.b65b32f3-32d4-45d3-a86a-3c7e1f5a5de3@github.com>

On Thu, 11 Dec 2025 18:49:12 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

This pull request has now been integrated.

Changeset: 3a80c639
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a80c639d804a0697b8eb477fe4c96407709449b
Stats:     974 lines in 179 files changed: 53 ins; 662 del; 259 mod

8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe "SimpleSSLContext" methods

Reviewed-by: jpai

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

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

From sshivang at openjdk.org  Tue Jan  6 11:08:34 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 11:08:34 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
Message-ID: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>

8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
Straight Backport

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

Commit messages:
 - Backport 629e4ac6f45c87898f6a014f28a443c800413869

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

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

From sshivang at openjdk.org  Tue Jan  6 11:08:34 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 11:08:34 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <5aVQ24ZshlttTck85Da1nc1JzyxzvLB4qOFjFnbhd-w=.5750aebe-734c-4102-8324-ff1a887d0199@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

@dfuch Can you please review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3714286788

From sshivang at openjdk.org  Tue Jan  6 14:49:54 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Tue, 6 Jan 2026 14:49:54 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <X9TCD0ph4NedupLHDI3yuzCwx4DkqG29fK-My0X67f0=.951c7f6a-7082-4af9-bd80-eaed216156e6@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

@dfuch Can you please review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3714980944

From jpai at openjdk.org  Tue Jan  6 15:07:37 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 15:07:37 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <p2QKik6KDdH4zCC7tiphXRqdCiuIbekzGmL8P7Dp64g=.c771fde7-7d67-40cf-bd08-d2115bb1e6db@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Hello Shivangi, I will talk to Volkan tomorrow to decide if we should backport this or do it at a later date.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3715049162

From djelinski at openjdk.org  Wed Jan  7 09:05:34 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:05:34 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <04gf4mIw4A8ibXD8SGV_8CrNDyiNiriuGlIGTa1I3JA=.d5eaaabc-e0f0-4ddd-b381-f8aea75f7dca@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633935001

From vyazici at openjdk.org  Wed Jan  7 09:07:26 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:07:26 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Update copyright years
 - Migrate forgotten `ClearTextServerSSL`
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Remove wildcard imports
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
 - Make sure `get()` returns the same instance
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

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

Changes: https://git.openjdk.org/jdk/pull/28905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=02
  Stats: 77 lines in 12 files changed: 4 ins; 39 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/28905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28905/head:pull/28905

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

From djelinski at openjdk.org  Wed Jan  7 09:12:15 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:12:15 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <48aZoJx-DQzKIw3ZBTis2I56oNJHZax_Zh1PVKHhZuM=.abd44f14-aaf9-4d3c-8b86-385105cede40@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633955099

From vyazici at openjdk.org  Wed Jan  7 09:25:04 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:25:04 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <GBpdvibXcfk6QgI_JLki-rvzjtkIVFCFw3IgRIs03ec=.d2ea029e-02f4-419f-94c1-afada6af3c21@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java line 1:

> 1: /*

This should have been addressed in [JDK-8373537], but forgotten. Doing it here.

[JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2667658921

From vyazici at openjdk.org  Wed Jan  7 10:00:09 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 10:00:09 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <rXVSDY6AFq06w7eUJenZHZj_MlPDaEx60kJH3tNNROw=.8c388b35-5633-47f7-9872-718a4d9849f2@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

I'm keen on backporting JDK-8372661 and all its sub-tasks (mind that their merge order matters!), preferably ASAP. It is a matter of time we will need to backport a change set touching tests that use `SimpleSSLContext`, and the author will need to deal with the merge conflict. Put another way, I am not able to see a reason to postpone this operation. That said, porting process can be complicated, and @dfuch has extensive experience on the subject. I will defer the _"When shall we backport?"_ question to him.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3718100043

From jpai at openjdk.org  Wed Jan  7 10:29:02 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Jan 2026 10:29:02 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <zaWDe3ePQbOh_dQ1QA_l-TL2nUVDCdoNz5U8BTs87eI=.adb888ec-483a-4fa0-9e66-e6a2d6d18de4@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
 <zaWDe3ePQbOh_dQ1QA_l-TL2nUVDCdoNz5U8BTs87eI=.adb888ec-483a-4fa0-9e66-e6a2d6d18de4@github.com>
Message-ID: <i6qvcjy5xGKgcPPipT4CegTwxyn0EWvkDNwc-2qzOdE=.94c5ac0f-2eb6-48ba-afe0-63d128ef085b@github.com>

On Thu, 1 Jan 2026 16:09:26 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8371903: Use stateLock to synchronize stream iteration and connection closure
>
> Hi all, Just following up to see if anyone has a chance to take a look at this.  
> Thanks.

Hello @ehs208, I was away on holidays and am catching up with the reviews. I will finish this review this week. Sorry about the delay.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3710648130

From djelinski at openjdk.org  Wed Jan  7 10:29:04 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 10:29:04 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
Message-ID: <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>

On Fri, 19 Dec 2025 12:11:11 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> ### Problem
>> 
>>   When the HTTP/2 client receives a GOAWAY frame with a non-zero error code, the current implementation discards both the error code and debug data. Users only see generic "Connection closed by peer" errors without any information about why the server terminated the connection.
>> 
>>   ### Solution
>> 
>>   Per [RFC 9113 ?5.4.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.4.1), a GOAWAY frame with a non-zero error code indicates a connection error requiring immediate closure. This fix:
>> 
>>   1. **Distinguishes** graceful shutdown (NO_ERROR) from connection errors
>>   2. **Preserves** error code and debug data in exception messages
>>   3. **Categorizes** streams based on `lastStreamId`:
>>      - Streams with ID > `lastStreamId`: Marked as unprocessed for automatic retry
>>      - Streams with ID ? `lastStreamId`: Failed with detailed error information
>> 
>>   ### Changes
>> 
>>   **Core Implementation** (`Http2Connection.java`):
>>   - Modified `handleGoAway()` to check error code and route appropriately
>>   - Added `handleGoAwayWithError()` method that:
>>     - Extracts error code and debug data from GOAWAY frame
>>     - Creates meaningful error messages with error name, hex code, and debug data
>>     - Properly categorizes streams for retry or failure
>> 
>>   **Test Infrastructure**:
>>   - `Http2TestServerConnection.sendGoAway(int, int, byte[])`: Supports custom error codes
>>   - `Http2TestExchangeImpl.getServerConnection()`: Accessor for test handlers
>>   - `GoAwayWithErrorTest`: Verifies proper error propagation
>> 
>>   ### Example
>> 
>>   **Before:**
>>   IOException: Connection closed by peer
>> 
>>   **After:**
>>   IOException: Received GOAWAY with error code Protocol error (0x1): Invalid HEADERS frame
>> 
>>   ### Testing
>> 
>>   - New `GoAwayWithErrorTest` passes
>>   - Existing HTTP/2 tests unaffected (NO_ERROR path unchanged)
>>   - Backward compatible (no public API changes)
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371903: Use stateLock to synchronize stream iteration and connection closure

Well with af092399cd5d188fdec4061d33528f6dc0f3a7f0 the `GoAwayWithErrorTest` deadlocks sometimes, with the following stack traces:
Thread 1:

              "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
              "java.net.http/jdk.internal.net.http.Http2Connection.tryReserveForPoolCheckout(Http2Connection.java:1604)",
              "java.net.http/jdk.internal.net.http.Http2ClientImpl.getConnectionFor(Http2ClientImpl.java:109)",
              "java.net.http/jdk.internal.net.http.ExchangeImpl.attemptHttp2Exchange(ExchangeImpl.java:143)",
              "java.net.http/jdk.internal.net.http.ExchangeImpl.get(ExchangeImpl.java:122)",
              "java.net.http/jdk.internal.net.http.Exchange.establishExchange(Exchange.java:409)",
              "java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:624)",
              "java.net.http/jdk.internal.net.http.Exchange.responseAsync(Exchange.java:447)",
              "java.net.http/jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:483)",
              "java.net.http/jdk.internal.net.http.MultiExchange.lambda$responseAsync0$0(MultiExchange.java:402)",

Thread 2:

              "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
              "java.net.http/jdk.internal.net.http.Http2ClientImpl.removeFromPool(Http2ClientImpl.java:225)",
              "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.doTerminate(Http2Connection.java:2135)",
              "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.terminate(Http2Connection.java:2099)",
              "java.net.http/jdk.internal.net.http.Http2Connection.close(Http2Connection.java:899)",
              "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAwayWithError(Http2Connection.java:1481)",
              "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1411)",

connectionPoolLock and stateLock are acquired in a different order, leading to the deadlock.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3718222666

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From duke at openjdk.org  Wed Jan  7 12:47:49 2026
From: duke at openjdk.org (EunHyunsu)
Date: Wed, 7 Jan 2026 12:47:49 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v11]
In-Reply-To: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
Message-ID: <WriftUc3cD36qBvE2sutctHYM9-Nxp0CGSKtfEwqTuY=.3802078b-e26f-46a6-87e6-0d725d31fcbf@github.com>

> ### Problem
> 
>   When the HTTP/2 client receives a GOAWAY frame with a non-zero error code, the current implementation discards both the error code and debug data. Users only see generic "Connection closed by peer" errors without any information about why the server terminated the connection.
> 
>   ### Solution
> 
>   Per [RFC 9113 ?5.4.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.4.1), a GOAWAY frame with a non-zero error code indicates a connection error requiring immediate closure. This fix:
> 
>   1. **Distinguishes** graceful shutdown (NO_ERROR) from connection errors
>   2. **Preserves** error code and debug data in exception messages
>   3. **Categorizes** streams based on `lastStreamId`:
>      - Streams with ID > `lastStreamId`: Marked as unprocessed for automatic retry
>      - Streams with ID ? `lastStreamId`: Failed with detailed error information
> 
>   ### Changes
> 
>   **Core Implementation** (`Http2Connection.java`):
>   - Modified `handleGoAway()` to check error code and route appropriately
>   - Added `handleGoAwayWithError()` method that:
>     - Extracts error code and debug data from GOAWAY frame
>     - Creates meaningful error messages with error name, hex code, and debug data
>     - Properly categorizes streams for retry or failure
> 
>   **Test Infrastructure**:
>   - `Http2TestServerConnection.sendGoAway(int, int, byte[])`: Supports custom error codes
>   - `Http2TestExchangeImpl.getServerConnection()`: Accessor for test handlers
>   - `GoAwayWithErrorTest`: Verifies proper error propagation
> 
>   ### Example
> 
>   **Before:**
>   IOException: Connection closed by peer
> 
>   **After:**
>   IOException: Received GOAWAY with error code Protocol error (0x1): Invalid HEADERS frame
> 
>   ### Testing
> 
>   - New `GoAwayWithErrorTest` passes
>   - Existing HTTP/2 tests unaffected (NO_ERROR path unchanged)
>   - Backward compatible (no public API changes)

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

  8371903: Move close() outside stateLock to avoid deadlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28632/files
  - new: https://git.openjdk.org/jdk/pull/28632/files/af092399..9d57110a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28632&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28632&range=09-10

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

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

From duke at openjdk.org  Wed Jan  7 12:47:52 2026
From: duke at openjdk.org (EunHyunsu)
Date: Wed, 7 Jan 2026 12:47:52 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
 <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>
Message-ID: <LUV8kEwfrpyvY1Bo63JGWJNH7EB-0Fsy8FB02AvFriE=.c51e089b-f847-4fb6-9f8f-b0744c4d0065@github.com>

On Wed, 7 Jan 2026 10:25:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8371903: Use stateLock to synchronize stream iteration and connection closure
>
> Well with af092399cd5d188fdec4061d33528f6dc0f3a7f0 the `GoAwayWithErrorTest` deadlocks sometimes, with the following stack traces:
> Thread 1:
> 
>               "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
>               "java.net.http/jdk.internal.net.http.Http2Connection.tryReserveForPoolCheckout(Http2Connection.java:1604)",
>               "java.net.http/jdk.internal.net.http.Http2ClientImpl.getConnectionFor(Http2ClientImpl.java:109)",
>               "java.net.http/jdk.internal.net.http.ExchangeImpl.attemptHttp2Exchange(ExchangeImpl.java:143)",
>               "java.net.http/jdk.internal.net.http.ExchangeImpl.get(ExchangeImpl.java:122)",
>               "java.net.http/jdk.internal.net.http.Exchange.establishExchange(Exchange.java:409)",
>               "java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:624)",
>               "java.net.http/jdk.internal.net.http.Exchange.responseAsync(Exchange.java:447)",
>               "java.net.http/jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:483)",
>               "java.net.http/jdk.internal.net.http.MultiExchange.lambda$responseAsync0$0(MultiExchange.java:402)",
> 
> Thread 2:
> 
>               "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
>               "java.net.http/jdk.internal.net.http.Http2ClientImpl.removeFromPool(Http2ClientImpl.java:225)",
>               "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.doTerminate(Http2Connection.java:2135)",
>               "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.terminate(Http2Connection.java:2099)",
>               "java.net.http/jdk.internal.net.http.Http2Connection.close(Http2Connection.java:899)",
>               "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAwayWithError(Http2Connection.java:1481)",
>               "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1411)",
> 
> connectionPoolLock and stateLock are acquired in a different order, leading to the deadlock.

@djelinski 
I addressed the deadlock by moving `close(cause)` outside of stateLock, keeping the stream iteration synchronized while avoiding holding the lock during `close()`.

The change works in local testing, but I don?t have a way to validate this under CI conditions. I?m also unsure whether this is the best solution, so I?d appreciate any guidance or alternative suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3718696751

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From vyazici at openjdk.org  Wed Jan  7 15:41:20 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:20 GMT
Subject: Integrated: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <X8OYy1PDIL2dy5b_mrT5hQnBs5UbLpGinvMEGY3ZWNE=.b6038750-3c14-4d6f-872c-140e97deac8e@github.com>

On Thu, 18 Dec 2025 18:32:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

This pull request has now been integrated.

Changeset: 3541bc86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3541bc8635ad8f5f4151758de3a134c9c105cebd
Stats:     77 lines in 12 files changed: 4 ins; 39 del; 34 mod

8373538: Migrate all tests to null-safe "SimpleSSLContext" methods

Reviewed-by: djelinski, jpai

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

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

From vyazici at openjdk.org  Wed Jan  7 15:41:19 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:19 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
 <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
Message-ID: <L2UJUrYrTSIoMJkOm2xLVkIghe89aZ6lfXsTsknwPe4=.78a2c70f-73b0-4e3b-9516-c29f2b29c8ac@github.com>

On Tue, 6 Jan 2026 06:48:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove wildcard imports
>
> This looks good to me.

@jaikiran, @djelinski, thanks so much for the reviews, and patience.
`SimpleSSLContext` null-safe static factory methods saga ends with this commit.

Tier 1-2 are clear on 76dae687368.

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

PR Comment: https://git.openjdk.org/jdk/pull/28905#issuecomment-3719466520

From sshivang at openjdk.org  Thu Jan  8 09:45:10 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 8 Jan 2026 09:45:10 GMT
Subject: [jdk26] RFR: 8373807:
 test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java getURI() uses
 "localhost"
Message-ID: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>

Hi all,

This pull request contains a backport of commit [f3a48560](https://github.com/openjdk/jdk/commit/f3a48560b5e3a280f6f76031eb3d475ff9ee49f4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Daniel Fuchs on 17 Dec 2025 and was reviewed by Jaikiran Pai.

Thanks!

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

Commit messages:
 - Backport f3a48560b5e3a280f6f76031eb3d475ff9ee49f4

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

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

From jpai at openjdk.org  Thu Jan  8 09:53:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Jan 2026 09:53:18 GMT
Subject: [jdk26] RFR: 8373807:
 test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java getURI() uses
 "localhost"
In-Reply-To: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
References: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
Message-ID: <OEh0CoqD0Eq7I_w-Vz770UAYWTgqv54g78DLnR7sqvg=.5e9e2d04-d02c-43e7-9cbe-3cd864c29a34@github.com>

On Thu, 8 Jan 2026 09:35:49 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f3a48560](https://github.com/openjdk/jdk/commit/f3a48560b5e3a280f6f76031eb3d475ff9ee49f4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 17 Dec 2025 and was reviewed by Jaikiran Pai.
> 
> Thanks!

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29111#pullrequestreview-3638632865

From duke at openjdk.org  Thu Jan  8 11:14:28 2026
From: duke at openjdk.org (duke)
Date: Thu, 8 Jan 2026 11:14:28 GMT
Subject: [jdk26] RFR: 8373807:
 test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java getURI() uses
 "localhost"
In-Reply-To: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
References: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
Message-ID: <CdwRik0TRBbpI_3u4-4N6qc9i1QzOQhKePVfH_VsCn4=.d2a40823-4f8e-4d3b-8c05-e9e5e41ada48@github.com>

On Thu, 8 Jan 2026 09:35:49 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f3a48560](https://github.com/openjdk/jdk/commit/f3a48560b5e3a280f6f76031eb3d475ff9ee49f4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 17 Dec 2025 and was reviewed by Jaikiran Pai.
> 
> Thanks!

@Shivangi-aa 
Your change (at version e695f023a9b9ce183e5a2eb405af8856246bc9dc) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29111#issuecomment-3723382999

From sshivang at openjdk.org  Thu Jan  8 12:01:18 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 8 Jan 2026 12:01:18 GMT
Subject: [jdk26] Integrated: 8373807:
 test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java getURI() uses
 "localhost"
In-Reply-To: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
References: <jzd-ibEzfdq5hnnj0hcly1Zbk745Mj0TtYLEdZajjLM=.ae310cc5-2959-4a77-89e9-948ce0a9c69f@github.com>
Message-ID: <EKUPKoBU2lLe0GWe367BJuowy2lL-Y--Yq8HZerkdkc=.0ad25c5b-dd74-4f53-89b2-432e9e5f798e@github.com>

On Thu, 8 Jan 2026 09:35:49 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f3a48560](https://github.com/openjdk/jdk/commit/f3a48560b5e3a280f6f76031eb3d475ff9ee49f4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 17 Dec 2025 and was reviewed by Jaikiran Pai.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 08215aed
Author:    Shivangi Gupta <sshivang at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08215aed7b7666162755a0cfc973172375c86689
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8373807: test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java getURI() uses "localhost"

Reviewed-by: jpai
Backport-of: f3a48560b5e3a280f6f76031eb3d475ff9ee49f4

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

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

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From jpai at openjdk.org  Mon Jan 12 06:34:01 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Jan 2026 06:34:01 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <LUV8kEwfrpyvY1Bo63JGWJNH7EB-0Fsy8FB02AvFriE=.c51e089b-f847-4fb6-9f8f-b0744c4d0065@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
 <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>
 <LUV8kEwfrpyvY1Bo63JGWJNH7EB-0Fsy8FB02AvFriE=.c51e089b-f847-4fb6-9f8f-b0744c4d0065@github.com>
Message-ID: <jEAy1apz4OrfuBZz2lWRWU8XYT34y8lribEogyys7Fk=.f83b012c-7820-460c-94f2-3fb312c670e4@github.com>

On Wed, 7 Jan 2026 12:45:00 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> Well with af092399cd5d188fdec4061d33528f6dc0f3a7f0 the `GoAwayWithErrorTest` deadlocks sometimes, with the following stack traces:
>> Thread 1:
>> 
>>               "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection.tryReserveForPoolCheckout(Http2Connection.java:1604)",
>>               "java.net.http/jdk.internal.net.http.Http2ClientImpl.getConnectionFor(Http2ClientImpl.java:109)",
>>               "java.net.http/jdk.internal.net.http.ExchangeImpl.attemptHttp2Exchange(ExchangeImpl.java:143)",
>>               "java.net.http/jdk.internal.net.http.ExchangeImpl.get(ExchangeImpl.java:122)",
>>               "java.net.http/jdk.internal.net.http.Exchange.establishExchange(Exchange.java:409)",
>>               "java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:624)",
>>               "java.net.http/jdk.internal.net.http.Exchange.responseAsync(Exchange.java:447)",
>>               "java.net.http/jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:483)",
>>               "java.net.http/jdk.internal.net.http.MultiExchange.lambda$responseAsync0$0(MultiExchange.java:402)",
>> 
>> Thread 2:
>> 
>>               "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)",
>>               "java.net.http/jdk.internal.net.http.Http2ClientImpl.removeFromPool(Http2ClientImpl.java:225)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.doTerminate(Http2Connection.java:2135)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.terminate(Http2Connection.java:2099)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection.close(Http2Connection.java:899)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAwayWithError(Http2Connection.java:1481)",
>>               "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1411)",
>> 
>> connectionPoolLock and stateLock are acquired in a different order, leading to the deadlock.
>
> @djelinski   
> I addressed the deadlock by moving `close(cause)` outside of stateLock, keeping the stream iteration synchronized while avoiding holding the lock during `close()`.
> 
> The change works in local testing, but I don?t have a way to validate this under CI conditions. I?m also unsure whether this is the best solution, so I?d appreciate any guidance or alternative suggestions.

Hello @ehs208, looking at these issues, I think this might need a bit more work and I don't have a straightforward/easy suggestion to make right now and I will need to take a deeper look at the code and experiment with a few changes. Would it be OK, if I took over the work on this one? I will add you as a contributor for the help you have provided so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3737034265

From duke at openjdk.org  Mon Jan 12 06:34:02 2026
From: duke at openjdk.org (EunHyunsu)
Date: Mon, 12 Jan 2026 06:34:02 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <jEAy1apz4OrfuBZz2lWRWU8XYT34y8lribEogyys7Fk=.f83b012c-7820-460c-94f2-3fb312c670e4@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
 <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>
 <LUV8kEwfrpyvY1Bo63JGWJNH7EB-0Fsy8FB02AvFriE=.c51e089b-f847-4fb6-9f8f-b0744c4d0065@github.com>
 <jEAy1apz4OrfuBZz2lWRWU8XYT34y8lribEogyys7Fk=.f83b012c-7820-460c-94f2-3fb312c670e4@github.com>
Message-ID: <k0eC6zHL9mcQGHYMn4zlodbCb5FV8dULw_ORqsVF1QQ=.cf77a161-ca80-437f-bb7a-9c547592d56b@github.com>

On Mon, 12 Jan 2026 06:15:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @djelinski   
>> I addressed the deadlock by moving `close(cause)` outside of stateLock, keeping the stream iteration synchronized while avoiding holding the lock during `close()`.
>> 
>> The change works in local testing, but I don?t have a way to validate this under CI conditions. I?m also unsure whether this is the best solution, so I?d appreciate any guidance or alternative suggestions.
>
> Hello @ehs208, looking at these issues, I think this might need a bit more work and I don't have a straightforward/easy suggestion to make right now and I will need to take a deeper look at the code and experiment with a few changes. Would it be OK, if I took over the work on this one? I will add you as a contributor for the help you have provided so far.

Hello @jaikiran
Thanks for taking a deeper look. I'm fine with you taking this over, and I appreciate the contributor credit.
Happy to help further if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3737069862

From dfuchs at openjdk.org  Tue Jan 13 10:48:15 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 Jan 2026 10:48:15 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <Bf2QVEG7njXtnz_a6KYQ63HW0y18ITbOLOHKCVQrsj4=.02988e96-6a8e-4333-b591-b9931215aff5@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

If no other backport needs it then maybe we can backport it in some (the first?) update after GA.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3743613367

From duke at openjdk.org  Tue Jan 13 18:22:49 2026
From: duke at openjdk.org (Josiah Noel)
Date: Tue, 13 Jan 2026 18:22:49 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v4]
In-Reply-To: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
References: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
Message-ID: <pk5mZlOdnP4FCkpi9Qql_6zcL9Y0Gvbwd6uVwOhWFIw=.fe2f1cc0-175b-40b7-9907-cc316dfdb447@github.com>

> Remaking the PR since I messed up the upstream merge on the other one. See (https://github.com/openjdk/jdk/pull/27751) for the bulk of the previous discussion
> 
> - adds a flag to ExchangeImpl to signal whether the current request is a GET Upgrade request
> - Adds a new `UpgradeInputStream`/`UpgradeOutputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UpgradeInputStream`

Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'openjdk:master' into JDK-8368695
 - Merge branch 'openjdk:master' into JDK-8368695
 - Merge branch 'master' into JDK-8368695
 - Merge branch 'master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/f23752a7...c9684377

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

Changes: https://git.openjdk.org/jdk/pull/27989/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27989&range=03
  Stats: 457 lines in 4 files changed: 449 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27989/head:pull/27989

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

From dfuchs at openjdk.org  Wed Jan 14 15:34:14 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Jan 2026 15:34:14 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
 <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
Message-ID: <e6muB-E8m6SVO4k4RzeucYRWgAaUgNi_CzXfsUX3cjk=.ee763f62-d9d8-4422-aaa7-7075c326ae51@github.com>

On Sat, 3 Jan 2026 02:08:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
>> 
>> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use "jdk.test.lib.Utils.adjustTimeout"

Looks reasonable to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29012#pullrequestreview-3661345096

From dfuchs at openjdk.org  Wed Jan 14 15:54:44 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Jan 2026 15:54:44 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v11]
In-Reply-To: <WriftUc3cD36qBvE2sutctHYM9-Nxp0CGSKtfEwqTuY=.3802078b-e26f-46a6-87e6-0d725d31fcbf@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <WriftUc3cD36qBvE2sutctHYM9-Nxp0CGSKtfEwqTuY=.3802078b-e26f-46a6-87e6-0d725d31fcbf@github.com>
Message-ID: <GQ8TZblR89fMPhmFJtikM_3e3bAtAuVM40fpNEVFtfM=.81f47c60-c7c8-4bb7-9476-9aebd48278fe@github.com>

On Wed, 7 Jan 2026 12:47:49 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> ### Problem
>> 
>>   When the HTTP/2 client receives a GOAWAY frame with a non-zero error code, the current implementation discards both the error code and debug data. Users only see generic "Connection closed by peer" errors without any information about why the server terminated the connection.
>> 
>>   ### Solution
>> 
>>   Per [RFC 9113 ?5.4.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.4.1), a GOAWAY frame with a non-zero error code indicates a connection error requiring immediate closure. This fix:
>> 
>>   1. **Distinguishes** graceful shutdown (NO_ERROR) from connection errors
>>   2. **Preserves** error code and debug data in exception messages
>>   3. **Categorizes** streams based on `lastStreamId`:
>>      - Streams with ID > `lastStreamId`: Marked as unprocessed for automatic retry
>>      - Streams with ID ? `lastStreamId`: Failed with detailed error information
>> 
>>   ### Changes
>> 
>>   **Core Implementation** (`Http2Connection.java`):
>>   - Modified `handleGoAway()` to check error code and route appropriately
>>   - Added `handleGoAwayWithError()` method that:
>>     - Extracts error code and debug data from GOAWAY frame
>>     - Creates meaningful error messages with error name, hex code, and debug data
>>     - Properly categorizes streams for retry or failure
>> 
>>   **Test Infrastructure**:
>>   - `Http2TestServerConnection.sendGoAway(int, int, byte[])`: Supports custom error codes
>>   - `Http2TestExchangeImpl.getServerConnection()`: Accessor for test handlers
>>   - `GoAwayWithErrorTest`: Verifies proper error propagation
>> 
>>   ### Example
>> 
>>   **Before:**
>>   IOException: Connection closed by peer
>> 
>>   **After:**
>>   IOException: Received GOAWAY with error code Protocol error (0x1): Invalid HEADERS frame
>> 
>>   ### Testing
>> 
>>   - New `GoAwayWithErrorTest` passes
>>   - Existing HTTP/2 tests unaffected (NO_ERROR path unchanged)
>>   - Backward compatible (no public API changes)
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371903: Move close() outside stateLock to avoid deadlock

One suggestion is to store the `lastProcessedStream` in an AtomicLong at the Http2Connection level and use that information in `doTerminate()` to decide whether to mark the stream as unprocessed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3750218450

From syan at openjdk.org  Thu Jan 15 02:42:44 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 15 Jan 2026 02:42:44 GMT
Subject: RFR: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp [v2]
In-Reply-To: <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
 <zcVEA8p93HkRIJiJNB1nMm4uGbgRzlg9UlrizH90Ht8=.20a7f59e-8b52-49a5-83da-459bc8ec42b6@github.com>
Message-ID: <P6panPMd7MeOfVq__wQlIq-yURtaGxjWYZjbcJkWnqM=.4aea9e27-b4b6-4907-a228-6d04bb5c20ac@github.com>

On Sat, 3 Jan 2026 02:08:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
>> 
>> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use "jdk.test.lib.Utils.adjustTimeout"

GHA report linux-x64 fastdebug build fails "No space left on device". This seems like environmental issue. It's unrelated to this PR.

Thanks for the reviews and verify @vy @dfuch.

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

PR Comment: https://git.openjdk.org/jdk/pull/29012#issuecomment-3752614467

From syan at openjdk.org  Thu Jan 15 02:44:18 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 15 Jan 2026 02:44:18 GMT
Subject: Integrated: 8374432:
 TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with
 -Xcomp
In-Reply-To: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
References: <VDUKRpK5rqmuEWTZRA2o_J7sGIZFCYFSbFOcUD9OHos=.75d95cee-cec9-437a-81a1-c9033dbac945@github.com>
Message-ID: <qXa1dgXhAdRF9fwBmnqVheaDSJqEYkUHe7M2-iclOLE=.39c40fdd-4dc9-42ca-abd3-4db9f35c41fb@github.com>

On Wed, 31 Dec 2025 08:14:09 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure  was observed timed out when run with jvm option -Xcomp. The failure details shows in [JDK-8374432](https://bugs.openjdk.org/browse/JDK-8374432). Maybe it need more time for C2 to compile the httpclient classes than the default mixed mode.
> 
> So this PR read the timeout factor from jtreg, and apply the timeout factor to `REQUEST_TIMEOUT` by multiply it. Change has been verified locally by run the related tests test/jdk/java/net/httpclient/TimeoutResponseHeaderTest.java and test/jdk/java/net/httpclient/TimeoutResponseBodyTest.java both with -Xmixed and -Xcomp. Test-fix only, no risk,

This pull request has now been integrated.

Changeset: d8f45faf
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8f45faf5849e66b8f0e35e1d18ed0331a0cb1c2
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8374432: TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with -Xcomp

Reviewed-by: vyazici, dfuchs

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

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

From asteiner at openjdk.org  Thu Jan 15 13:25:15 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Thu, 15 Jan 2026 13:25:15 GMT
Subject: RFR: 8374802: Assert if UDP receive buffer is too small to hold
 capacity to avoid hanging test
Message-ID: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>

To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert.

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

Commit messages:
 - 8374802: Assert if UDP receive buffer is too small to hold capacity to avoid hanging test

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

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

From alanb at openjdk.org  Thu Jan 15 14:44:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jan 2026 14:44:10 GMT
Subject: RFR: 8374802: Assert if UDP receive buffer is too small to hold
 capacity to avoid hanging test
In-Reply-To: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
Message-ID: <DlKxQ7vaOCyXSgedyvJ24V1nawNK8b1JcSLiqVgV2Xg=.6141810f-76a4-4311-a7d4-7e94dd34bf57@github.com>

On Thu, 15 Jan 2026 13:17:30 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)

This test (and the equivalent for DatagramChannel) was initially created to work on macOS. We should check into the history to see how/when it was extended to work on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3755202889

From asteiner at openjdk.org  Thu Jan 15 15:31:41 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Thu, 15 Jan 2026 15:31:41 GMT
Subject: RFR: 8374802: Assert if UDP receive buffer is too small to hold
 capacity to avoid hanging test
In-Reply-To: <DlKxQ7vaOCyXSgedyvJ24V1nawNK8b1JcSLiqVgV2Xg=.6141810f-76a4-4311-a7d4-7e94dd34bf57@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <DlKxQ7vaOCyXSgedyvJ24V1nawNK8b1JcSLiqVgV2Xg=.6141810f-76a4-4311-a7d4-7e94dd34bf57@github.com>
Message-ID: <jHreJL1PBdfcnia2sEIDp_zev0_h8msw7rN4SDCJcR0=.e1ae960b-64fb-4b2b-9635-2b90e719a978@github.com>

On Thu, 15 Jan 2026 14:40:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> This test (and the equivalent for DatagramChannel) was initially created to work on macOS. We should check into the history to see how/when it was extended to work on all platforms.
> 
> BTW: No objection to changing the test, it's just the test `@summary` is outdated.

@AlanBateman: with this commit it was extended to run on all platforms: https://github.com/openjdk/jdk/commit/a096c0a83f900c05702f94c35adb51746c0683cd

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3755421174

From duke at openjdk.org  Fri Jan 16 05:51:09 2026
From: duke at openjdk.org (EunHyunsu)
Date: Fri, 16 Jan 2026 05:51:09 GMT
Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames
 with error code [v10]
In-Reply-To: <jEAy1apz4OrfuBZz2lWRWU8XYT34y8lribEogyys7Fk=.f83b012c-7820-460c-94f2-3fb312c670e4@github.com>
References: <E04reZHzsPSTntIds9JoDOtu9GMkTurgxN4uqXkVCWw=.7f41e52a-1e87-4557-b0e9-49dcd987cf4e@github.com>
 <Y_prH67VHpyVqsMDOOwBtoNfKMLRvD6wc9Y-mfDYoYk=.cec86ae6-cb3a-46ac-8258-ac8b290c4652@github.com>
 <o_50zI_38xcjsYV7_g6wYrvI6iR3SP9vuBc4Ja7T9CU=.011d9d2d-1e75-4f6a-9a03-9d54ff8ce90e@github.com>
 <LUV8kEwfrpyvY1Bo63JGWJNH7EB-0Fsy8FB02AvFriE=.c51e089b-f847-4fb6-9f8f-b0744c4d0065@github.com>
 <jEAy1apz4OrfuBZz2lWRWU8XYT34y8lribEogyys7Fk=.f83b012c-7820-460c-94f2-3fb312c670e4@github.com>
Message-ID: <dHUY9tYJBM6OnbKCPQ37_3peWjONePasRGgIjUbfysI=.2dca07a3-a0da-4269-a138-59bce241c0e1@github.com>

On Mon, 12 Jan 2026 06:15:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @djelinski   
>> I addressed the deadlock by moving `close(cause)` outside of stateLock, keeping the stream iteration synchronized while avoiding holding the lock during `close()`.
>> 
>> The change works in local testing, but I don?t have a way to validate this under CI conditions. I?m also unsure whether this is the best solution, so I?d appreciate any guidance or alternative suggestions.
>
> Hello @ehs208, looking at these issues, I think this might need a bit more work and I don't have a straightforward/easy suggestion to make right now and I will need to take a deeper look at the code and experiment with a few changes. Would it be OK, if I took over the work on this one? I will add you as a contributor for the help you have provided so far.

@jaikiran I see @dfuch suggested using AtomicLong to store lastProcessedStream at the connection level. Should I try implementing this approach, or would you prefer to handle it since you're taking over the work?

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

PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3758290122

From vyazici at openjdk.org  Fri Jan 16 08:16:10 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 16 Jan 2026 08:16:10 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name matches
 while mapping request path to context path
Message-ID: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>

Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by disallowing partial file name matches.


         |           Request path
 Context +------+-------+----------+---------
  path   | /foo | /foo/ | /foo/bar | /foobar
---------+------+-------+----------+---------
 /       |   Y  |   Y   |     Y    |    Y
 /foo/   |   N  |   Y   |     Y    |    N

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

Commit messages:
 - Do exact path prefix matching in `HttpServer`

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

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

From vyazici at openjdk.org  Fri Jan 16 08:16:11 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 16 Jan 2026 08:16:11 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path
In-Reply-To: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
Message-ID: <FN1e22F1l1Cjab4BbORdHdgr5d7ijXElACNF5P1GuEo=.addcb15f-c093-486f-920f-32038077d592@github.com>

On Fri, 16 Jan 2026 08:07:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by disallowing partial file name matches.
> 
> 
>          |           Request path
>  Context +------+-------+----------+---------
>   path   | /foo | /foo/ | /foo/bar | /foobar
> ---------+------+-------+----------+---------
>  /       |   Y  |   Y   |     Y    |    Y
>  /foo/   |   N  |   Y   |     Y    |    N

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpServer.java line 1:

> 1: /*

Recall that the issue was first reported in [JDK-8225479], and there, the decision was to introduce the `@apiNote` workaround you see here. I took the approach of adding an `@implNote` stating where we deviate from the `@apiNote`.

I am not really sure if the _"this would match requests"_ statement (note the _"would"_!) implies a conflict between the old `@apiNote` and the newly introduced `@implNote`. If so, this can bite use in the CSR review.

In short, I appreciate your feedback on how to massage the API docs.

[JDK-8225479]: https://bugs.openjdk.org/browse/JDK-8225479

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2697430212

From vyazici at openjdk.org  Fri Jan 16 08:18:59 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 16 Jan 2026 08:18:59 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path
In-Reply-To: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
Message-ID: <ERM6STVxCdfhIMZRzwAjoU2EeMN9EV7ls9S6LXP_TmU=.68835210-ff61-4dcc-aacf-e523ef39887e@github.com>

On Fri, 16 Jan 2026 08:07:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by disallowing partial file name matches.
> 
> 
>          |           Request path
>  Context +------+-------+----------+---------
>   path   | /foo | /foo/ | /foo/bar | /foobar
> ---------+------+-------+----------+---------
>  /       |   Y  |   Y   |     Y    |    Y
>  /foo/   |   N  |   Y   |     Y    |    N

test/jdk/java/net/httpclient/PlainProxyConnectionTest.java line 1:

> 1: /*

Surprisingly, this is *the only test* that failed due to this change, and, IMHO, this is a typo in the test. That is, the test author actually wanted to introduce the `x` prefix to the URI to exactly avoid the problem we're trying to solve in this PR, yet he/she unintentionally fell into the trap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2697436911

From alanb at openjdk.org  Fri Jan 16 11:45:15 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jan 2026 11:45:15 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size
In-Reply-To: <DlKxQ7vaOCyXSgedyvJ24V1nawNK8b1JcSLiqVgV2Xg=.6141810f-76a4-4311-a7d4-7e94dd34bf57@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <DlKxQ7vaOCyXSgedyvJ24V1nawNK8b1JcSLiqVgV2Xg=.6141810f-76a4-4311-a7d4-7e94dd34bf57@github.com>
Message-ID: <usv4RwvaA5WT7VxbKnmVSkBkwjBEXsIMjeWRbXC0BPQ=.09ac6239-3709-4f8d-89cf-3eb73e5ad7d9@github.com>

On Thu, 15 Jan 2026 14:40:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> This test (and the equivalent for DatagramChannel) was initially created to work on macOS. We should check into the history to see how/when it was extended to work on all platforms.
> 
> BTW: No objection to changing the test, it's just the test `@summary` is outdated.

> @AlanBateman: with this commit it was extended to run on all platforms: [a096c0a](https://github.com/openjdk/jdk/commit/a096c0a83f900c05702f94c35adb51746c0683cd)

Thanks for checking, the summary should have been updated when the test was changed and extended to run on all platforms. We can create a follow-up to fix that.

Can you update the copyright header? As you note, this just puts in the same check that is already in the DC test.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3759664296

From asteiner at openjdk.org  Fri Jan 16 13:00:09 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 16 Jan 2026 13:00:09 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size [v2]
In-Reply-To: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
Message-ID: <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>

> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)

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

  update copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29251/files
  - new: https://git.openjdk.org/jdk/pull/29251/files/0de47bec..6740f6e9

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

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

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

From asteiner at openjdk.org  Fri Jan 16 13:00:10 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 16 Jan 2026 13:00:10 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size
In-Reply-To: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
Message-ID: <lMUsn9EV2eRUBV3vou0kd6W00TNzEB2zoW005O9MFrU=.ad8cb527-bc74-47a8-ad27-71927e29b538@github.com>

On Thu, 15 Jan 2026 13:17:30 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)

Sure. Copyright header updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3759908970

From alanb at openjdk.org  Fri Jan 16 13:49:42 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jan 2026 13:49:42 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size [v2]
In-Reply-To: <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
Message-ID: <swy3AkNb_IOkaXnSrGU5nMCQ2vKwU86JY2Uuageqqio=.ab140a96-b109-484c-bbdf-933dd5407518@github.com>

On Fri, 16 Jan 2026 13:00:09 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

I assume you will confirm that the test passes on the main stream platforms before integrating this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29251#pullrequestreview-3670948093

From asteiner at openjdk.org  Fri Jan 16 14:00:15 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 16 Jan 2026 14:00:15 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size [v2]
In-Reply-To: <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
Message-ID: <o7qU7GKPd_v3Gi8gHeeXEXr8fGzToZ8XfWbv9C_f8AQ=.9d5995db-a40b-4f3a-b980-7596a8951e30@github.com>

On Fri, 16 Jan 2026 13:00:09 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

Yes, the test passes in our nightly tests at SAP on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3760137307

From ehs122100 at gmail.com  Sun Jan 18 15:34:41 2026
From: ehs122100 at gmail.com (Hyunsu Eun)
Date: Mon, 19 Jan 2026 00:34:41 +0900
Subject: 8371576: HttpURLConnection fails to connect when first DNS-resolved
 address is unreachable
Message-ID: <5093B94F-B529-4DE4-B81C-92CCB4B6B206@gmail.com>

Hi,

I'd like to contribute to JDK-8371576 [1], where HttpURLConnection fails immediately
if the first DNS-resolved IP address is unreachable, even when other valid addresses exist.

I analyzed the issue and identified the root cause in NetworkClient.doConnect():
- It uses new InetSocketAddress(server, port), which only attempts the first resolved address
- This affects HttpURLConnection, FTP, and other users of NetworkClient
- The modern HttpClient has a similar issue in PlainHttpConnection.connectAsync()

Proposed fix:
- Explicitly resolve all addresses via InetAddress.getAllByName()
- Attempt connections sequentially until one succeeds
- Distribute the timeout across attempts to preserve existing behavior
- Introduce a system property: jdk.net.enableDNSFallback (default: true)

This would address the legacy APIs. Since the modern HttpClient appears to have the same issue,
would you prefer to fix both in a single change or handle them separately?

I'm happy to work on this if the issue is available.

Thanks,  
Hyunsu Eun

[1] https://bugs.openjdk.org/browse/JDK-8371576

From duke at openjdk.org  Sun Jan 18 15:43:26 2026
From: duke at openjdk.org (EunHyunsu)
Date: Sun, 18 Jan 2026 15:43:26 GMT
Subject: RFR: 8328894: HttpResponse.body() returns null with https target
 and failed proxy authentication [v2]
In-Reply-To: <IkArQmBNveaatdh3Yqw-MpOGSihsbL5FMZPAtUA3ymY=.6e7566d0-199a-4809-9d96-160413033e49@github.com>
References: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
 <IkArQmBNveaatdh3Yqw-MpOGSihsbL5FMZPAtUA3ymY=.6e7566d0-199a-4809-9d96-160413033e49@github.com>
Message-ID: <h9lTSnRTeJZ0CIl6bH-ncN6RSfhIqbHWywszibFq4CI=.177e52ba-8c5e-4fb7-9741-8bde967cdd29@github.com>

On Sat, 6 Dec 2025 12:49:34 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> ### Summary
>>   This patch addresses the issue where `HttpResponse.body()` returns `null` for 407 responses when using HTTPS through a proxy, while HTTP requests correctly return the response body.
>> 
>>   ### Problem
>>   When an HTTPS request receives a 407 Proxy Authentication Required response, the response body is discarded during CONNECT tunnel establishment. This is inconsistent with HTTP behavior where the body is properly returned.
>> 
>>   **Root cause:**
>>   - HTTPS uses `MultiExchange<Void>` for CONNECT requests
>>   - The body is explicitly ignored via `ignoreBody()` on 407 responses
>>   - No mechanism exists to preserve the body for later retrieval
>> 
>>   ### Proposed Solution
>>   I propose the following changes to preserve and return the 407 response body:
>> 
>>   1. **PlainTunnelingConnection.java**: Change `MultiExchange<Void>` to `MultiExchange<byte[]>` and read the body on 407 responses instead of ignoring it
>> 
>>   2. **ProxyAuthenticationRequired.java**: Add `proxyResponseBody` field to carry the body bytes through the exception
>> 
>>   3. **Exchange.java**: Cache both the proxy response and body, then return them when the application calls `body()`
>> 
>>   ### Testing
>>   Added comprehensive test (`ProxyAuthHttpTest.java`) covering:
>>   - Basic HTTP and HTTPS 407 responses
>>   - Multiple `BodyHandler` types: `ofString()`, `ofByteArray()`, `ofInputStream()`, `ofLines()`
>>   - Response headers validation
>> 
>>   **Test results**: 38/38 passed
>> 
>>   ### Notes
>>   - This change only affects 407 responses; all other flows remain unchanged
>>   - The cached body is cleared after first use to prevent reuse
>>   - No changes to public APIs; internal implementation only
>> 
>>   I'd appreciate any feedback on this approach. If there's a better way to handle this, I'm happy to revise.
>
> EunHyunsu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - fix whitespace issue
>  - Merge branch 'master' into JDK-8328894
>  - 8328894: Add test for 407 response body with various handlers
>  - 8328894: Cache and return 407 response body to application
>  - 8328894: Add proxyResponseBody field to preserve 407 body
>  - 8328894: Read 407 response body in HTTPS CONNECT tunneling

Hi all,
I believe the RDP1 fork is complete now.
If anyone has a moment, I'd appreciate guidance on whether I should proceed with an updated patch or keep this on hold.

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

PR Comment: https://git.openjdk.org/jdk/pull/28232#issuecomment-3765420354

From duke at openjdk.org  Mon Jan 19 10:21:02 2026
From: duke at openjdk.org (duke)
Date: Mon, 19 Jan 2026 10:21:02 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size [v2]
In-Reply-To: <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
Message-ID: <OOAOCvMH366wKZgGT-55bk-6tE-Id5F9ejPqCnCPel4=.795ee258-9bf5-4b9c-b2f4-aaed5b06d987@github.com>

On Fri, 16 Jan 2026 13:00:09 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

@ansteiner 
Your change (at version 6740f6e96b8425e4b16d8e5d3f1993206fa21f38) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3767537096

From asteiner at openjdk.org  Mon Jan 19 13:58:05 2026
From: asteiner at openjdk.org (Andreas Steiner)
Date: Mon, 19 Jan 2026 13:58:05 GMT
Subject: Integrated: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size
In-Reply-To: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
Message-ID: <fF7zDFV-4EBsj3LG5QSdeJIko358dZCqJq7G2J9ug90=.e1c1f8d4-31b5-474e-9509-88401afa26b6@github.com>

On Thu, 15 Jan 2026 13:17:30 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)

This pull request has now been integrated.

Changeset: 6942bb2b
Author:    Andreas Steiner <asteiner at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6942bb2b313c2d81e95f692dd947733b1149e8b8
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8374802: java/net/DatagramSocket/SendReceiveMaxSize.java fails on AIX due to small default RCVBUF size

Reviewed-by: alanb

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

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

From dfuchs at openjdk.org  Mon Jan 19 15:47:34 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 19 Jan 2026 15:47:34 GMT
Subject: RFR: 8374802: java/net/DatagramSocket/SendReceiveMaxSize.java
 fails on AIX due to small default RCVBUF size [v2]
In-Reply-To: <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
References: <gskdHdAwNQTpvX3CVvZcmQo1GkDSgKdlA8KQtxYIcrc=.290a4256-e6c7-468d-b4bb-a7f895e86402@github.com>
 <LoKdZt6wIEeklBJD8Iq6Xh7b-ESgsV1SAScSwXtLXy4=.84a564bf-778d-46b9-8064-375a4a8894ad@github.com>
Message-ID: <vCI6CXX_IjdajUtPhzf42SAlKAOXFm0lsgjE1Z1aOpw=.b108484d-cab9-4bdb-ab30-2f2e3b57f05e@github.com>

On Fri, 16 Jan 2026 13:00:09 GMT, Andreas Steiner <asteiner at openjdk.org> wrote:

>> To avoid the test is hanging due to the too small receive buffer, check the receive buffer can hold the capacity. If not, assert. Like we do already in java/nio/channels/DatagramChannel/SendReceiveMaxSize.java (https://bugs.openjdk.org/browse/JDK-8313873)
>
> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

FWIW I did run this change in our CI as well and observed no related failure either.

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

PR Comment: https://git.openjdk.org/jdk/pull/29251#issuecomment-3768962027

From smonteith at openjdk.org  Tue Jan 20 09:37:08 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 20 Jan 2026 09:37:08 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
Message-ID: <uTpKLMgW_uKXr9vk2F5y8xjq33HBF4yLTvw0XFh8nt8=.617dded6-0b66-40dc-829a-0ae711a1d4b9@github.com>

On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> MemorySegments allocated from shared Arena from
>> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
>> 
>> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
>> 
>> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
>> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
>> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
>> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
>> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
>> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
>> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
>> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
>> 
>> After:
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
>> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
>> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
>> |    8  |    58...
>
> I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion.

> @stooart-mon This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a `/touch` or `/keepalive` command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

It's OK bot, I'm sure people are looking at this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3771899705

From abarashev at openjdk.org  Tue Jan 20 14:17:54 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 20 Jan 2026 14:17:54 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
Message-ID: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>

Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
https://datatracker.ietf.org/doc/html/rfc8879

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

Commit messages:
 - Merge branch 'master' into JDK-8372526
 - Correct log message. Reformat file.
 - Update unit test
 - Merge branch 'master' into JDK-8372526
 - Add DefaultCertCompression unit test
 - Update copyright year and bug number plus some small changes
 - Revert SSLLogger changes
 - Fix merge errors
 - Merge branch 'master' into JDK-8273042
 - Support ZLIB compression only
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e7432d57...f2ccafd0

Changes: https://git.openjdk.org/jdk/pull/28682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372526
  Stats: 1365 lines in 17 files changed: 1336 ins; 11 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From bchristi at openjdk.org  Tue Jan 20 20:31:18 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:31:18 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
Message-ID: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29331/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331

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

From bchristi at openjdk.org  Tue Jan 20 20:34:55 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:34:55 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
Message-ID: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29332/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332

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

From abarashev at openjdk.org  Tue Jan 20 20:57:08 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 20 Jan 2026 20:57:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v2]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1baiHDKLxm7F0ymn9mPmxcxuEjdy_wQfswRo5gwMVSk=.2a692a90-84b8-4c67-972f-ef6b30c8f490@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Cache compressed local certificates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/f2ccafd0..7e965242

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

  Stats: 60 lines in 1 file changed: 29 ins; 10 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From kcr at openjdk.org  Tue Jan 20 21:34:45 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:34:45 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <lgyZ6v95aJQ2wc93EdoJ-t0CX8-HASEbzT8M0yss3Qk=.f6545aa5-52ed-4849-ae60-8ff75fd4cd55@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505

From kcr at openjdk.org  Tue Jan 20 21:35:46 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:35:46 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <tAakA6ADGd9sqbZll-xqpgZDUV6VtWUgCSm3oJQlhV4=.93c63002-5987-481a-b194-341b5faaa3d5@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038

From prr at openjdk.org  Tue Jan 20 22:05:29 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:05:29 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <L7ot0RSGxYxlzRYGMKEMjILOCiC7wGYhsO7vVvEzPXc=.ba5698e7-be06-497e-8234-395f2cac7556@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562

From prr at openjdk.org  Tue Jan 20 22:08:39 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:08:39 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <R0Q7zCwwhcmbvB3Z-GT8SyVv88FiNpJE1sRGDKWVWKs=.1d63c771-76ba-455e-8c48-738cd1cae0f7@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706

From smarks at openjdk.org  Wed Jan 21 01:16:18 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:18 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489

From smarks at openjdk.org  Wed Jan 21 01:16:22 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:22 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <d4UEBfgDPeaTQ6MJmVaGLhkMF4MGbJjvaNc4UF0VUPc=.de637b15-3139-4dbf-b863-9d6355b07503@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880

From bchristi at openjdk.org  Wed Jan 21 01:33:46 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:46 GMT
Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2]
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <m6au9jDA--T9V-5h9StQxGa1b8s6tQMUQYjj1jGeods=.3d7846c9-f8de-46b2-ad4c-73626b6fdb15@github.com>

> This brings in cpu26_01 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29332/files
  - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:33:48 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:48 GMT
Subject: [jdk26] Integrated: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <bzGdXAI0-0khn6oK_-Lf3InoJyVt9CL5hoRFPXlHu_w=.3b3e93b5-7484-4499-aecf-80b589c1663a@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: 7ac780da
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:06 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:06 GMT
Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2]
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com>

> This brings in cpu26_01 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29331/files
  - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:09 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:09 GMT
Subject: Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <bxGQ21sSA_6fGAy2JNV_X9oo_Q5DnkUjXtfGEKwjJCw=.66feccd4-289e-49a9-bd8c-1accc12fced0@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: e25a5a48
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From vyazici at openjdk.org  Wed Jan 21 12:21:42 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 Jan 2026 12:21:42 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
Message-ID: <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>

> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by disallowing partial file name matches.
> 
> 
>          |           Request path
>  Context +------+-------+----------+---------
>   path   | /foo | /foo/ | /foo/bar | /foobar
> ---------+------+-------+----------+---------
>  /       |   Y  |   Y   |     Y    |    Y
>  /foo/   |   N  |   Y   |     Y    |    N

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

  Add property to switch between prefix matching schemes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29264/files
  - new: https://git.openjdk.org/jdk/pull/29264/files/f44d4b35..e80aabcb

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

  Stats: 543 lines in 6 files changed: 325 ins; 199 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/29264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29264/head:pull/29264

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

From vyazici at openjdk.org  Wed Jan 21 12:47:40 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 Jan 2026 12:47:40 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
 <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
Message-ID: <j16OkFHE-nP0FOdRyRuJUff3LbKGB9YdpxAvkTkDD-g=.09c9653f-62d0-4cab-b254-19ca7e83592e@github.com>

On Wed, 21 Jan 2026 12:21:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by requiring exact *path prefix matches*.
>> 
>> 
>>          |           Request path
>>  Context +------+-------+----------+---------
>>   path   | /foo | /foo/ | /foo/bar | /foobar
>> ---------+------+-------+----------+---------
>>  /       |   Y  |   Y   |     Y    |    Y
>>  /foo/   |   N  |   Y   |     Y    |    N
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add property to switch between prefix matching schemes

@Michael-Mc-Mahon, @dfuch, in e80aabcb7ab, I've added the `sun.net.httpserver.pathMatcher` property to switch between path-prefix and string-prefix matching schemes. See the following screenshots showcasing relevant parts:

### Module Summary page

<img width="1121" height="384" alt="Module Summary page" src="https://github.com/user-attachments/assets/c81944e6-64e7-411b-8f1b-385872fb844d" />

### `HttpServer` page

<img width="1116" height="722" alt="HttpServer page" src="https://github.com/user-attachments/assets/14abc3a6-9fe4-43b8-9973-b9e47e7dcdfd" />

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

PR Comment: https://git.openjdk.org/jdk/pull/29264#issuecomment-3777942776

From vyazici at openjdk.org  Wed Jan 21 12:47:43 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 Jan 2026 12:47:43 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <FN1e22F1l1Cjab4BbORdHdgr5d7ijXElACNF5P1GuEo=.addcb15f-c093-486f-920f-32038077d592@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
 <FN1e22F1l1Cjab4BbORdHdgr5d7ijXElACNF5P1GuEo=.addcb15f-c093-486f-920f-32038077d592@github.com>
Message-ID: <OS2ILSjCndf4tAPfG1zZbGWfIa7YKGXxO4knf8TV3XU=.2be37695-ff42-4e56-8688-9a9c1a59efd0@github.com>

On Fri, 16 Jan 2026 08:13:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add property to switch between prefix matching schemes
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpServer.java line 1:
> 
>> 1: /*
> 
> Recall that the issue was first reported in [JDK-8225479], and there, the decision was to introduce the `@apiNote` workaround you see here. I took the approach of adding an `@implNote` stating where we deviate from the `@apiNote`.
> 
> I am not really sure if the _"this would match requests"_ statement (note the _"would"_!) implies a conflict between the old `@apiNote` and the newly introduced `@implNote`. If so, this can bite use in the CSR review.
> 
> In short, I appreciate your feedback on how to massage the API docs.
> 
> [JDK-8225479]: https://bugs.openjdk.org/browse/JDK-8225479

Addressed in e80aabcb7ab.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2712413825

From kfarrell at openjdk.org  Wed Jan 21 16:52:08 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 21 Jan 2026 16:52:08 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <tb2p5UScm2-tC7p6jEEmiRMJ1GSTAWfFocWDIvuIELQ=.b51a5809-0e92-4495-a556-79fd65c83864@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

This backport is now required for another fix, could we please get this reviewed/integreated and I will backport to the older releases? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3779586006

From sshivang at openjdk.org  Wed Jan 21 17:03:23 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Wed, 21 Jan 2026 17:03:23 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <LPXWY0EsTQSPQjQNwh5DY9xCjj9EUcY52kGWgGWQgW8=.e225d2ea-a37c-4c1b-aef3-d18cf9724e04@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

I think now it should go in 26u?

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3779694290

From dfuchs at openjdk.org  Wed Jan 21 18:46:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Jan 2026 18:46:03 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <d1s45aDlcTye4sAV2kJHWtvfsoDFCIZuKDTHfXAoTZ0=.e21e82ad-dcf4-4ecc-ae6d-d106698b1937@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Yes I would prefer to see it go to 26u.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3780310809

From abarashev at openjdk.org  Wed Jan 21 19:24:17 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 21 Jan 2026 19:24:17 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Improve cache key checksum
 - Merge branch 'master' into JDK-8372526
 - Cache compressed local certificates
 - Merge branch 'master' into JDK-8372526
   
   # Conflicts:
   #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
 - Correct log message. Reformat file.
 - Update unit test
 - Merge branch 'master' into JDK-8372526
 - Add DefaultCertCompression unit test
 - Update copyright year and bug number plus some small changes
 - Revert SSLLogger changes
 - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39

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

Changes: https://git.openjdk.org/jdk/pull/28682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=02
  Stats: 1387 lines in 17 files changed: 1358 ins; 11 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From sshivang at openjdk.org  Thu Jan 22 03:35:24 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 22 Jan 2026 03:35:24 GMT
Subject: [jdk26] RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <1sjspoLu_R0ZMvos2_mMIm5k36kAxH0NPbXRWbtpXDU=.86e2c8eb-2b8e-4d94-bfb8-68bf26bcd7a2@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

Ok I will quickly do this in 26u and ask for review. Closing this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/29064#issuecomment-3782339473

From sshivang at openjdk.org  Thu Jan 22 03:35:24 2026
From: sshivang at openjdk.org (Shivangi Gupta)
Date: Thu, 22 Jan 2026 03:35:24 GMT
Subject: [jdk26] Withdrawn: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
References: <ZHyn_nf4rKYKdKYGdvC_hF0pQFpA3g_la4ckcfmMvq8=.1947be93-6895-42b4-9e06-225b360ff91d@github.com>
Message-ID: <Q4GMebawqxiQO_NlLyOMmocPK2Q0OwH_S-nEN7ODzWY=.c9ac2720-28df-426e-bd75-c4c4bb50deea@github.com>

On Tue, 6 Jan 2026 11:00:59 GMT, Shivangi Gupta <sshivang at openjdk.org> wrote:

> 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext"
> Straight Backport

This pull request has been closed without being integrated.

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

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

From vyazici at openjdk.org  Thu Jan 22 10:30:53 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 Jan 2026 10:30:53 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest to
 collect more diagnostic
Message-ID: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>

This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.

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

Commit messages:
 - Increase QUIC idle timeout

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

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

From dfuchs at openjdk.org  Thu Jan 22 10:35:58 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jan 2026 10:35:58 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic
In-Reply-To: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
Message-ID: <-rfSigDDN0WigiHy9gIXj3YeWpWo2fcRxyKW5RxgxjQ=.6d3288f7-6955-4c53-806f-dc2bfef592fc@github.com>

On Thu, 22 Jan 2026 10:24:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.

LGTM - with one minor comment.

test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8087112 8177935 8376089

In principle you only put the bug id in the `@bug` list if there's a product change that the bug verifies. So I would revert this line and put `noreg-self` on the JBS issue instead.

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

PR Review: https://git.openjdk.org/jdk/pull/29358#pullrequestreview-3691740485
PR Review Comment: https://git.openjdk.org/jdk/pull/29358#discussion_r2716288358

From vyazici at openjdk.org  Thu Jan 22 10:40:54 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 Jan 2026 10:40:54 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic [v2]
In-Reply-To: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
Message-ID: <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>

> This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.

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

  Remove `@bug` entry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29358/files
  - new: https://git.openjdk.org/jdk/pull/29358/files/9ea1a232..15e20a6c

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

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

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

From vyazici at openjdk.org  Thu Jan 22 10:40:56 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 Jan 2026 10:40:56 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic [v2]
In-Reply-To: <-rfSigDDN0WigiHy9gIXj3YeWpWo2fcRxyKW5RxgxjQ=.6d3288f7-6955-4c53-806f-dc2bfef592fc@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
 <-rfSigDDN0WigiHy9gIXj3YeWpWo2fcRxyKW5RxgxjQ=.6d3288f7-6955-4c53-806f-dc2bfef592fc@github.com>
Message-ID: <TLV-tb4ZMnNIRtnVX0Lyz0Aj8gaqSSNqAuch9yJPSwo=.0735c69b-8999-460a-aee6-c97ac66bed21@github.com>

On Thu, 22 Jan 2026 10:32:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove `@bug` entry
>
> test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8087112 8177935 8376089
> 
> In principle you only put the bug id in the `@bug` list if there's a product change that the bug verifies. So I would revert this line and put `noreg-self` on the JBS issue instead.

True. Removed in 15e20a6c537.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29358#discussion_r2716303804

From dfuchs at openjdk.org  Thu Jan 22 12:10:58 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jan 2026 12:10:58 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic [v2]
In-Reply-To: <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
 <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>
Message-ID: <QON_AuCY1ocnSEgiCv-TcI_WB33jN5NE0t4J7w_7NzI=.8b5ae27e-d83d-4c64-961e-814458a10444@github.com>

On Thu, 22 Jan 2026 10:40:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@bug` entry

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29358#pullrequestreview-3692134470

From jpai at openjdk.org  Thu Jan 22 12:16:26 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Jan 2026 12:16:26 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic [v2]
In-Reply-To: <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
 <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>
Message-ID: <ZPqycXpSSCyzO5TUWf9f4EM_bkcIq8CtoDjA9Ojk3uc=.ebf26305-f3f0-4aa9-bd1d-13d0a347ad34@github.com>

On Thu, 22 Jan 2026 10:40:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `@bug` entry

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29358#pullrequestreview-3692151632

From dfuchs at openjdk.org  Thu Jan 22 12:38:15 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jan 2026 12:38:15 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
Message-ID: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>

On Wed, 21 Jan 2026 19:24:17 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Improve cache key checksum
>  - Merge branch 'master' into JDK-8372526
>  - Cache compressed local certificates
>  - Merge branch 'master' into JDK-8372526
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>  - Correct log message. Reformat file.
>  - Update unit test
>  - Merge branch 'master' into JDK-8372526
>  - Add DefaultCertCompression unit test
>  - Update copyright year and bug number plus some small changes
>  - Revert SSLLogger changes
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 32:

> 30: import java.net.http.HttpRequest;
> 31: import java.net.http.HttpResponse;
> 32: import javax.net.ssl.SSLParameters;

Since this test is not using HttpsURLConnection but the new HttpClient it would be better to bring it to `test/jdk/java/net/httpclient`

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 58:

> 56:                         new URI("https://www.google.com/"))
> 57:                 .GET()
> 58:                 .build();

Maybe this should be a manual test since it's accessing a host on the public internet.
How difficult would it be to have a test that uses the jdk.net HttpServer instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2716718955
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2716722820

From dfuchs at openjdk.org  Thu Jan 22 15:53:06 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jan 2026 15:53:06 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows
Message-ID: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>

This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.

This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.

This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).

With that change, I have not been able to observe the test failing again.

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

Commit messages:
 - 8376118: java/net/httpclient/StreamingBody.java fails intermittently on Windows

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

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

From abarashev at openjdk.org  Thu Jan 22 16:20:33 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 16:20:33 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v4]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <7xzWKZ7pSQgNGkw52uy-y-MrEpd_h3Rwv9aZlo-qCCQ=.90f237c6-8a1f-452f-a5f3-46f9420d38f0@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Use CRC32C checksum instead of Adler32 to reduce the chance of collision

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/c859eb39..7dad5f1b

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

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

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

From abarashev at openjdk.org  Thu Jan 22 21:22:19 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:22:19 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v5]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <t5S0D-cD60SSAlNQC9WsBK0RWkVQC4obNbCg6OIo5s8=.840c1424-197e-4681-b9ef-94b9fb0b7695@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Move HttpsCompressedCert test to test/jdk/java/net/httpclient and make it manual

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/7dad5f1b..b53a5fca

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

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

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

From abarashev at openjdk.org  Thu Jan 22 21:25:54 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:25:54 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
 <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
Message-ID: <jTnbHt-qo_5er7PRFhHE_Wtt9HxCm55FtYPmZNfV0Nk=.2b2b7afa-aa02-4acd-9e51-4b25929b4678@github.com>

On Thu, 22 Jan 2026 12:33:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Improve cache key checksum
>>  - Merge branch 'master' into JDK-8372526
>>  - Cache compressed local certificates
>>  - Merge branch 'master' into JDK-8372526
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>>  - Correct log message. Reformat file.
>>  - Update unit test
>>  - Merge branch 'master' into JDK-8372526
>>  - Add DefaultCertCompression unit test
>>  - Update copyright year and bug number plus some small changes
>>  - Revert SSLLogger changes
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39
>
> test/jdk/java/net/httpclient/HttpsCompressedCert.java line 32:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Since this test is not using HttpsURLConnection but the new HttpClient it would be better to bring it to `test/jdk/java/net/httpclient`

Indeed, moved it to `test/jdk/java/net/httpclient`, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2718684416

From abarashev at openjdk.org  Thu Jan 22 21:30:10 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 22 Jan 2026 21:30:10 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v3]
In-Reply-To: <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <xt7nUl50aEDdGhu1hVfdERLdMLMoxsIXVIYKfwI-wR0=.509b0940-e218-4193-a825-eeb0a6a17430@github.com>
 <VublKY2XK48iwP0tzvpzK6O3Ej1VBmJ9u6Q0_IpXy5w=.e9f130a1-2af3-4881-ad28-7cfcaefde6f7@github.com>
Message-ID: <odMLhlpTATP9ddLWSFrpQ5oglsROYTkvaDUlQyxqRS4=.0c113cf8-6fa3-4392-af92-3264f09706ef@github.com>

On Thu, 22 Jan 2026 12:33:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Improve cache key checksum
>>  - Merge branch 'master' into JDK-8372526
>>  - Cache compressed local certificates
>>  - Merge branch 'master' into JDK-8372526
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
>>  - Correct log message. Reformat file.
>>  - Update unit test
>>  - Merge branch 'master' into JDK-8372526
>>  - Add DefaultCertCompression unit test
>>  - Update copyright year and bug number plus some small changes
>>  - Revert SSLLogger changes
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/aaca0a2c...c859eb39
>
> test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 58:
> 
>> 56:                         new URI("https://www.google.com/"))
>> 57:                 .GET()
>> 58:                 .build();
> 
> Maybe this should be a manual test since it's accessing a host on the public internet.
> How difficult would it be to have a test that uses the jdk.net HttpServer instead?

I made it manual, thanks! I'll work on `HttpServer` test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2718696868

From abarashev at openjdk.org  Fri Jan 23 03:33:52 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 03:33:52 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

 - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
 - Add back the library directive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/b53a5fca..ef0a8f04

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

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

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

From vyazici at openjdk.org  Fri Jan 23 08:29:46 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 08:29:46 GMT
Subject: RFR: 8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest
 to collect more diagnostic [v2]
In-Reply-To: <QON_AuCY1ocnSEgiCv-TcI_WB33jN5NE0t4J7w_7NzI=.8b5ae27e-d83d-4c64-961e-814458a10444@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
 <xXbR7IlOJLrRLOw2DLMO7FRm9k5FAHz59Qb6Mk6hTIo=.52ea2947-c1d1-457b-b441-e0392a2dd557@github.com>
 <QON_AuCY1ocnSEgiCv-TcI_WB33jN5NE0t4J7w_7NzI=.8b5ae27e-d83d-4c64-961e-814458a10444@github.com>
Message-ID: <Z_dXtNTXldwwNUegxT4y52QYayzr6q-dSZMBlS-QH6Q=.6cf64b31-c22c-4b6b-bb98-41832cef3295@github.com>

On Thu, 22 Jan 2026 12:08:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove `@bug` entry
>
> Marked as reviewed by dfuchs (Reviewer).

@dfuch, @jaikiran, thanks so much for the reviews.
Verified that, using 15e20a6c537, test passes on several platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/29358#issuecomment-3789025155

From vyazici at openjdk.org  Fri Jan 23 08:29:47 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 08:29:47 GMT
Subject: Integrated: 8376089: Increase QUIC idle timeout in
 H3FixedThreadPoolTest to collect more diagnostic
In-Reply-To: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
References: <F7O2uPLubRyvLZOBqYVYkA7mkd6zqxydYAxihww51bc=.e969e58f-5d3a-48ab-8453-dc613811832d@github.com>
Message-ID: <Z4o16gnO66AkwF0bE7HE3Kbh7e8Nr3klVg2-EmCXsqE=.9da0ec93-756c-4dd2-a2a9-1d480f727357@github.com>

On Thu, 22 Jan 2026 10:24:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> This test failed on Tier 7, but the failure could not be reproduced. Increase the QUIC idle timeout to a value higher than the JTreg on Tier 7 so that, if the client becomes wedged again, the JTreg timeout handlers can collect more diagnostic information.

This pull request has now been integrated.

Changeset: ca37dba4
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca37dba4d40bf3f71c5489829c893346faec1c56
Stats:     10 lines in 1 file changed: 8 ins; 0 del; 2 mod

8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest to collect more diagnostic

Reviewed-by: dfuchs, jpai

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

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

From jpai at openjdk.org  Fri Jan 23 09:32:30 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Jan 2026 09:32:30 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
Message-ID: <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>

On Fri, 23 Jan 2026 03:33:52 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
>  - Add back the library directive

src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 98:

> 96: 
> 97:         Map<Integer, Function<byte[], byte[]>> inflaters =
> 98:                 new LinkedHashMap<>(config.certInflaters.size());

Hello Artur, is this intentionally using the constructor which takes a `initialCapacity` or was it meant to be the number of expected mappings? If it's the latter, then there's `LinkedHashMap.newLinkedHashMap()` method https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/LinkedHashMap.html#newLinkedHashMap(int) which takes the expected number of mappings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2720415224

From vyazici at openjdk.org  Fri Jan 23 09:53:13 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 09:53:13 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows
In-Reply-To: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
Message-ID: <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>

On Thu, 22 Jan 2026 15:43:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
> 
> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
> 
> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
> 
> With that change, I have not been able to observe the test failing again.

In `newRequestBuilder`, I see we explicitly set the version (along with the discovery flag) only for HTTP/3. Shouldn't we ideally be doing this for all versions to ensure that, say, the HTTP/2 test indeed uses HTTP/2?

test/jdk/java/net/httpclient/StreamingBody.java line 32:

> 30:  * @run junit/othervm
> 31:  *       -Djdk.httpclient.HttpClient.log=trace,headers,requests
> 32:  *       StreamingBody

Suggestion:

Suggestion:

 *       ${test.main.class}

test/jdk/java/net/httpclient/StreamingBody.java line 94:

> 92:     private static boolean stopAfterFirstFailure() {
> 93:         return true;
> 94:     }

Any particular reason that this is not just a constant, but a method?

test/jdk/java/net/httpclient/StreamingBody.java line 103:

> 101:         long nan = now % 1000_000;
> 102:         return String.format("[%d s, %d ms, %d ns] ", secs, mill, nan);
> 103:     }

*Nit:* You can also be done with just `import static java.time.Instant.now`.

test/jdk/java/net/httpclient/StreamingBody.java line 135:

> 133:     /// wants to verify that HttpClient instances which are no
> 134:     /// longer strongly referenced are not garbage collected
> 135:     /// before pending HTTP request are finished. The test

Suggestion:

    /// before pending HTTP requests are finished. The test

test/jdk/java/net/httpclient/StreamingBody.java line 151:

> 149:         private final Thread runner;
> 150:         private volatile boolean stop;
> 151:         private final Random RANDOM = RandomFactory.getRandom();

1. This can be `static`
2. Doesn't this warrant a `@key randomness`?

test/jdk/java/net/httpclient/StreamingBody.java line 226:

> 224:                         .build()
> 225:                         .sendAsync(request, BodyHandlers.ofInputStream())
> 226:                         .join();

Any particular reason we prefer `sendAsync().join()` over `send()`?

test/jdk/java/net/httpclient/StreamingBody.java line 228:

> 226:                         .join();
> 227: 
> 228:                 String body = new String(response.body().readAllBytes(), UTF_8);

AFAIU, we use an `HttpResponse<InputStream>` and convert it to string _after_ the `HttpResponse` instantiation, instead of directly reaching for `HttpResponse<InputStream>`, because the former does not immediately finalize the request. This creates better odds to leak resources, which we're trying to stress in this test. Assuming my interpretation is correct, you might consider dropping a comment briefly explaining this rationale.

test/jdk/java/net/httpclient/StreamingBody.java line 300:

> 298:         out.println("\n=========================");
> 299:         try {
> 300:             out.printf("%n%sCreated %d servers and %d clients%n",

*Nit:* You might consider using `%s` instead of `%d`, since the latter renders numbers in localized form, and can produce surprising outputs. (@dfuch, this was a nice lesson I learned from you. ?)

test/jdk/java/net/httpclient/StreamingBody.java line 313:

> 311:     }
> 312: 
> 313:     static class MessageHandler implements HttpTestHandler {

You can replace this class with `EchoHandler`.

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

PR Review: https://git.openjdk.org/jdk/pull/29366#pullrequestreview-3696394502
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720247052
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720265502
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720273882
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720292028
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720290856
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720459391
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720481565
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720491459
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720485094

From dfuchs at openjdk.org  Fri Jan 23 10:23:04 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 10:23:04 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v2]
In-Reply-To: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
Message-ID: <IM7976tLOMiUXsYPHOSbSR39Lj10YfSgFMdiU46RMmQ=.b3e7ce48-b6f4-43fa-8d06-089c7295f301@github.com>

> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
> 
> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
> 
> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
> 
> With that change, I have not been able to observe the test failing again.

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

  Update test/jdk/java/net/httpclient/StreamingBody.java
  
  Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29366/files
  - new: https://git.openjdk.org/jdk/pull/29366/files/74e6cd59..796fd438

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

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

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

From dfuchs at openjdk.org  Fri Jan 23 10:23:07 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 10:23:07 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v2]
In-Reply-To: <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
Message-ID: <4Bg2zYVWJNyeu2M5slMhYOw08Q3-2PufQDynFEdff1E=.62b80860-841e-4d93-a04c-d1e0e73d7cb4@github.com>

On Fri, 23 Jan 2026 09:50:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> In `newRequestBuilder`, I see we explicitly set the version (along with the discovery flag) only for HTTP/3. Shouldn't we ideally be doing this for all versions to ensure that, say, the HTTP/2 test indeed uses HTTP/2?

The default version is HTTP/2 so there's no need to set the version at the request level if the version is not HTTP/3. HTTP/3 is the only version that requires an opt-in.

> test/jdk/java/net/httpclient/StreamingBody.java line 94:
> 
>> 92:     private static boolean stopAfterFirstFailure() {
>> 93:         return true;
>> 94:     }
> 
> Any particular reason that this is not just a constant, but a method?

Copy paste from other tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/29366#issuecomment-3789527251
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720605180

From dfuchs at openjdk.org  Fri Jan 23 10:31:14 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 10:31:14 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v3]
In-Reply-To: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
Message-ID: <hOOFwfkBFSpW3cxssUYPJuk06zrRDKDDLK3xZhzg9ms=.009bae90-6569-4f71-b96b-8ab328872a54@github.com>

> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
> 
> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
> 
> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
> 
> With that change, I have not been able to observe the test failing again.

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

  Update test/jdk/java/net/httpclient/StreamingBody.java
  
  Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29366/files
  - new: https://git.openjdk.org/jdk/pull/29366/files/796fd438..0f4d4141

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

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

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

From dfuchs at openjdk.org  Fri Jan 23 10:31:16 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 10:31:16 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v3]
In-Reply-To: <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
Message-ID: <xQwuJCZb7aeHz_iKms2P12es03KSZugtj_-NjLlxUpA=.7de57cc1-11c6-4d33-b5d3-e4257eb35051@github.com>

On Fri, 23 Jan 2026 08:49:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/net/httpclient/StreamingBody.java
>>   
>>   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>
> test/jdk/java/net/httpclient/StreamingBody.java line 103:
> 
>> 101:         long nan = now % 1000_000;
>> 102:         return String.format("[%d s, %d ms, %d ns] ", secs, mill, nan);
>> 103:     }
> 
> *Nit:* You can also be done with just `import static java.time.Instant.now`.

The goal here is to give a human-friendly approximation of the elapsed time since the test started, with seconds, millis, nanos. Instant is the wall clock so I'd rather not use that.

> test/jdk/java/net/httpclient/StreamingBody.java line 226:
> 
>> 224:                         .build()
>> 225:                         .sendAsync(request, BodyHandlers.ofInputStream())
>> 226:                         .join();
> 
> Any particular reason we prefer `sendAsync().join()` over `send()`?

Yes. we want to relinquish the reference to the HttpClient facade as soon as possible.

> test/jdk/java/net/httpclient/StreamingBody.java line 313:
> 
>> 311:     }
>> 312: 
>> 313:     static class MessageHandler implements HttpTestHandler {
> 
> You can replace this class with `EchoHandler`.

Maybe in future work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720616913
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720621950
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720630244

From dfuchs at openjdk.org  Fri Jan 23 10:51:04 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 10:51:04 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v4]
In-Reply-To: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
Message-ID: <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>

> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
> 
> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
> 
> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
> 
> With that change, I have not been able to observe the test failing again.

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

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29366/files
  - new: https://git.openjdk.org/jdk/pull/29366/files/0f4d4141..9524b9f1

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

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

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

From dfuchs at openjdk.org  Fri Jan 23 12:21:54 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 12:21:54 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v4]
In-Reply-To: <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <-OdRmy-k-kWyMxdLHVX7K2hfVBw6st2bWV9f0DyL5_E=.e7f9e32e-f071-42af-acde-4bf80b3d09f5@github.com>
Message-ID: <RYOntCEILZTT8UbRRDgeMYfn-2ZxpWYEYY_VHQ_Rp40=.c8454fd8-9783-40ac-be71-cc2a1062f51d@github.com>

On Fri, 23 Jan 2026 08:53:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> test/jdk/java/net/httpclient/StreamingBody.java line 151:
> 
>> 149:         private final Thread runner;
>> 150:         private volatile boolean stop;
>> 151:         private final Random RANDOM = RandomFactory.getRandom();
> 
> 1. This can be `static`
> 2. Doesn't this warrant a `@key randomness`?

Done.

> test/jdk/java/net/httpclient/StreamingBody.java line 228:
> 
>> 226:                         .join();
>> 227: 
>> 228:                 String body = new String(response.body().readAllBytes(), UTF_8);
> 
> AFAIU, we use an `HttpResponse<InputStream>` and convert it to string _after_ the `HttpResponse` instantiation, instead of directly reaching for `HttpResponse<InputStream>`, because the former does not immediately finalize the request. This creates better odds to leak resources, which we're trying to stress in this test. Assuming my interpretation is correct, you might consider dropping a comment briefly explaining this rationale.

Done

> test/jdk/java/net/httpclient/StreamingBody.java line 300:
> 
>> 298:         out.println("\n=========================");
>> 299:         try {
>> 300:             out.printf("%n%sCreated %d servers and %d clients%n",
> 
> *Nit:* You might consider using `%s` instead of `%d`, since the latter renders numbers in localized form, and can produce surprising outputs. (@dfuch, this was a nice lesson I learned from you. ?)

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720976934
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720978760
PR Review Comment: https://git.openjdk.org/jdk/pull/29366#discussion_r2720973799

From vyazici at openjdk.org  Fri Jan 23 12:42:52 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 23 Jan 2026 12:42:52 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v4]
In-Reply-To: <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
Message-ID: <Dvo9orzcrAjofDGuwWoXl-D_ce3cTeGILbMmAnMBMe0=.8b3398b0-7725-4489-b9c5-c0963c2ae502@github.com>

On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
>> 
>> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
>> 
>> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
>> 
>> With that change, I have not been able to observe the test failing again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29366#pullrequestreview-3697302731

From jpai at openjdk.org  Fri Jan 23 15:10:13 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Jan 2026 15:10:13 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v4]
In-Reply-To: <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
Message-ID: <Y9lfcfeE1RZ6b05mCckPIaec3C-FV66FDqPGeTuXAeY=.3e017eaf-fc77-407b-9077-fdaa147c226a@github.com>

On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
>> 
>> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
>> 
>> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
>> 
>> With that change, I have not been able to observe the test failing again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Hello Daniel, this looks OK to me. The GC trigger appears a slightly involved. Maybe we could have just done the following in that GCTrigger thread:


while (!stop) {
    ForceGC.waitFor(() -> false, 500); // keep initiating GC
}

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29366#pullrequestreview-3698003427

From abarashev at openjdk.org  Fri Jan 23 15:24:29 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 15:24:29 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v6]
In-Reply-To: <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <nAZwEBGOjjuzpDS-22fH9dZj1Mfup-ESeB-4MJjwzJ8=.29f59844-4fac-4b40-9785-e8f576482d14@github.com>
 <6cs-_wTI-PO4suA-EQSfzgqBbCwohpLzMGeY7I46IMA=.1d919135-157c-4c43-8b75-61db7ac6a6dd@github.com>
Message-ID: <nkAALZ2iFmmlHCOppaPFbk8PVEoneJE85RS6f5dOgJc=.b63aa3d7-4667-4e3e-a7e6-b8fa620d083f@github.com>

On Fri, 23 Jan 2026 09:29:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add COMPRESSED_CERTIFICATE to the QUIC list of expected TLS messages
>>  - Add back the library directive
>
> src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 98:
> 
>> 96: 
>> 97:         Map<Integer, Function<byte[], byte[]>> inflaters =
>> 98:                 new LinkedHashMap<>(config.certInflaters.size());
> 
> Hello Artur, is this intentionally using the constructor which takes a `initialCapacity` or was it meant to be the number of expected mappings? If it's the latter, then there's `LinkedHashMap.newLinkedHashMap()` method https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/LinkedHashMap.html#newLinkedHashMap(int) which takes the expected number of mappings.

That's basically the max possible size of that map. Currently it can be either 1 or 0. Thanks for pointing out this new method. I'll make a change so we avoid unnecessary reallocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2721665798

From dfuchs at openjdk.org  Fri Jan 23 16:17:45 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 23 Jan 2026 16:17:45 GMT
Subject: RFR: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows [v4]
In-Reply-To: <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
 <iPjENQEWp4PZXDXzT52Mrre_Z2KpwNO-CiBEFGMclJ0=.655de62b-3077-4062-9fc5-b529bc02da82@github.com>
Message-ID: <yCAzO67-ImIWBP33YksshDdzuK93EPgbAbvLpkyhLq4=.77072812-f9dc-4087-a92c-5feefbc6a47c@github.com>

On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
>> 
>> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
>> 
>> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
>> 
>> With that change, I have not been able to observe the test failing again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

> Hello Daniel, this looks OK to me. The GC trigger appears a slightly involved. Maybe we could have just done the following in that GCTrigger thread:
> 
> ```java
> while (!stop) {
>     ForceGC.waitFor(() -> false, 500); // keep initiating GC
> }
> ```

We don't want this thread to keep on invoking GC in a busy loop - so I'd prefer to keep the current implementation that triggers the GC a few times. FWIW with the current setting (the gcinterval of 500ms passed to GCTrigger) and when the test doesn't encounter unexpected slow downs I see that the System.gc() is triggerred ~ 4 times in the course of the test execution. Since I wasn't able to reproduce the test error with that settings I'd say we reached the sweet spot :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/29366#issuecomment-3791028660

From abarashev at openjdk.org  Fri Jan 23 17:24:02 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 23 Jan 2026 17:24:02 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v7]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1fvgSgXKXRZotuRbDAJm0SGdiy2vDboEatjbJXmI6g8=.aa3845b4-9d05-4a5d-b75a-335c4ad21e8f@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Use newLinkedHashMap to avoid unnecessary reallocation. Remove redundant "handshake" check point from logging.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/ef0a8f04..c0fd9b86

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

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

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

From jpai at openjdk.org  Mon Jan 26 10:14:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:14:24 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
Message-ID: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>

Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 

This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:


java.net.ConnectException: Connection refused: no further information


With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.

A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

Commit messages:
 - add bug id to the test
 - allow NULL for msg in NET_ThrowNew
 - introduce test

Changes: https://git.openjdk.org/jdk/pull/29409/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29409&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376290
  Stats: 157 lines in 4 files changed: 135 ins; 10 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29409/head:pull/29409

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

From alanb at openjdk.org  Mon Jan 26 10:38:12 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 10:38:12 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>

On Mon, 26 Jan 2026 09:54:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

src/java.base/windows/native/libnet/net_util_md.c line 165:

> 163:             jio_snprintf(fullMsg, sizeof(fullMsg), "%s: %s",
> 164:                              (char *)winsock_errors[i].errString, msg);
> 165:         }

Can you fix up the alignment of the 3rd param, it's a bit messed up with the edits.

test/jdk/java/nio/channels/Selector/FailedConnect.java line 49:

> 47:  * @run junit ${test.main.class}
> 48:  */
> 49: class FailedConnect {

Maybe rename to ConnectionRefusedMessage as this isn't a unit test for connect failing?

test/jdk/java/nio/channels/Selector/FailedConnect.java line 76:

> 74:             System.err.println("establishing connection to " + destAddr);
> 75:             boolean connected = sc.connect(destAddr);
> 76:             assertFalse(connected, "unexpectedly connected to " + destAddr);

I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727097372
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727105812
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727099761

From jpai at openjdk.org  Mon Jan 26 10:53:15 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:53:15 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
Message-ID: <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>

On Mon, 26 Jan 2026 10:32:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename test to ConnectionRefusedMessage
>>  - formatting
>
> src/java.base/windows/native/libnet/net_util_md.c line 165:
> 
>> 163:             jio_snprintf(fullMsg, sizeof(fullMsg), "%s: %s",
>> 164:                              (char *)winsock_errors[i].errString, msg);
>> 165:         }
> 
> Can you fix up the alignment of the 3rd param, it's a bit messed up with the edits.

Done - I updated it now to match the formatting in else block. Let me know if this requires any additional formatting change.

> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 76:
> 
>> (failed to retrieve contents of file, check the PR for context)
> I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.

Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?

> test/jdk/java/nio/channels/Selector/FailedConnect.java line 49:
> 
>> 47:  * @run junit ${test.main.class}
>> 48:  */
>> 49: class FailedConnect {
> 
> Maybe rename to ConnectionRefusedMessage as this isn't a unit test for connect failing?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727146106
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727142505
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727142942

From jpai at openjdk.org  Mon Jan 26 10:53:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 10:53:11 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <kjHgRIJjl2tXU-I27sBhtKBVTNXftnat1yPv6CA3hEU=.f85f403d-c729-42b7-82a7-198358a39f16@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

 - rename test to ConnectionRefusedMessage
 - formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/5ce54c2e..8d391779

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

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

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

From alanb at openjdk.org  Mon Jan 26 10:58:39 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 10:58:39 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v2]
In-Reply-To: <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
 <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
Message-ID: <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>

On Mon, 26 Jan 2026 10:48:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 76:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I think the test will have to retry if "connected" returns true as it's too easy to have interference between tests on the same host.
>
> Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?

Yes, I think I'd prefer if the test skipped if connected or retried.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727164187

From jpai at openjdk.org  Mon Jan 26 12:50:29 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 12:50:29 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  skip the test if the SocketChannel unexpectedly connects to the destination address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/8d391779..2e555591

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

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

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

From jpai at openjdk.org  Mon Jan 26 12:50:31 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 12:50:31 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c0DYOIBtcdaT-CMnTAP_7EbSAfPwgq1wt4DxiZKd6P8=.f008ab94-da37-4697-ac69-5292dad0947a@github.com>
 <OF_Hm1irvw3dwh5RBcIqt2X_amQzkoOA5VEC94bxwHI=.9690bffb-5311-4703-818a-4853af8c1d26@github.com>
 <h_SLapHU9Y3gtLUs7R0AF6caLex4_EjpqjkEBfAHx-I=.99ed6b3f-0ce0-4e2f-bb26-698d94eb4c48@github.com>
Message-ID: <X4dhu_dfdiBTwuL_vf-SBVRpyh8h2QLWlyJ8DFJY3vc=.10f3bf50-0377-4576-8d8f-428241b01208@github.com>

On Mon, 26 Jan 2026 10:55:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello Alan, do you mean there could be something that could be listening on these "restricted" ports, after we ensured in `findSuitableRefusedAddress()` that there wasn't anyone listening there?
>
> Yes, I think I'd prefer if the test skipped if connected or retried.

Done - I've updated the test to skip it if the SocketChannel connects to the destination address unexpectedly, at any point during the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727483729

From dfuchs at openjdk.org  Mon Jan 26 13:00:37 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 Jan 2026 13:00:37 GMT
Subject: Integrated: 8376118: java/net/httpclient/StreamingBody.java fails
 intermittently on Windows
In-Reply-To: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
References: <MoO2RVJa_Y1QBYzWGpUXnRpS8onOnre-iw2zzcXMR4M=.966463da-d695-4a72-80f3-d3169bddc6e7@github.com>
Message-ID: <cx1qJlyV03AJ8ZkXTgAnLMRjQwsNjKPejAbuaV-mmMc=.168b6842-1175-4330-973e-f4f90b87fd2a@github.com>

On Thu, 22 Jan 2026 15:43:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This test has been observed failing intermittently in the CI, either in JTreg timeout, where the test passes successfully after the timeout has fired but while the failure handlers are still executing, or with an `SSLHandshakeException` caused by `"An established connection was aborted by the software in your host machine"`.
> 
> This test creates 500 clients and relies on the GC to close them (by design), because it wants to catch bugs where clients would be GC'ed too early. However, relying on the GC to close the clients can put pressure on resource allocation on the machine, which we suspect is the cause for the slow down and the test failures. @Michael-Mc-Mahon suggested we could try to relieve the pressure by making explicit calls to `System.gc()`, in the hope to reclaim the abandonned clients earlier.
> 
> This changes implements the suggestion by making calls to `System.gc()` at random interval from a separate thread, and converts the test to JUnit, making it stop at the first failure (which otherwise has a frustrating tendency to disappear in the JTreg Output Overflow).
> 
> With that change, I have not been able to observe the test failing again.

This pull request has now been integrated.

Changeset: 8a9127fc
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a9127fc2d1f8c1cba952744e1a5a7533bb03537
Stats:     198 lines in 1 file changed: 163 ins; 6 del; 29 mod

8376118: java/net/httpclient/StreamingBody.java fails intermittently on Windows

Reviewed-by: vyazici, jpai

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

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

From dfuchs at openjdk.org  Mon Jan 26 13:18:54 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 Jan 2026 13:18:54 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received"
Message-ID: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>

When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.

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

Commit messages:
 - Copyright year + unused imports
 - 8376308: java/net/httpclient/CancelRequestTest.java fails intermittently with "Expected CancellationException not received"

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

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

From alanb at openjdk.org  Mon Jan 26 13:21:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 13:21:37 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
Message-ID: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>

On Mon, 26 Jan 2026 12:50:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip the test if the SocketChannel unexpectedly connects to the destination address

src/java.base/unix/native/libnet/net_util_md.c line 78:

> 76:             jio_snprintf(fullMsg, sizeof(fullMsg), "socket closed: %s", msg);
> 77:             JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", fullMsg);
> 78:         }

For for this PR but at some point I'd like to know if the EBADF handling is dead code. It shouldn't happen, at least not with the usages in sun.nio.ch/libnio but maybe there is something that I can't think of.

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:

> 88:                         // this test checks the exception message of a ConnectException, so it's
> 89:                         // OK to skip the test if something unexpectedly accepted the connection
> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);

Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727572402
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727576573

From jpai at openjdk.org  Mon Jan 26 13:34:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 13:34:03 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
Message-ID: <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>

On Mon, 26 Jan 2026 13:18:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip the test if the SocketChannel unexpectedly connects to the destination address
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:
> 
>> 88:                         // this test checks the exception message of a ConnectException, so it's
>> 89:                         // OK to skip the test if something unexpectedly accepted the connection
>> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);
> 
> Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.

The reason I used the exception type directly was it looked a bit odd to read something like:


boolean success = sc.finishConnect();
if (success) {
    // this test checks the exception message of a ConnectException, so it's
    // OK to skip the test if something unexpectedly accepted the connection
    assumeTrue(success, "unexpectedly connected to " + destAddr);
}
fail("ConnectException was not thrown");


but I don't have a strong preference here. I'll switch to using the `Assumptions.assumeXXX` API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727616602

From jpai at openjdk.org  Mon Jan 26 14:03:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:16 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  replace TestAbortedException with Assumptions.assumeTrue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/2e555591..c184f07a

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

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

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

From jpai at openjdk.org  Mon Jan 26 14:03:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:20 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
Message-ID: <mbl94wBSL4q17y0j1bELqvFOpoXVoIx7Glw7L-bm3tg=.570923a3-3579-4c00-bb3b-ec51787b6594@github.com>

On Mon, 26 Jan 2026 13:17: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:
>> 
>>   skip the test if the SocketChannel unexpectedly connects to the destination address
>
> src/java.base/unix/native/libnet/net_util_md.c line 78:
> 
>> 76:             jio_snprintf(fullMsg, sizeof(fullMsg), "socket closed: %s", msg);
>> 77:             JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", fullMsg);
>> 78:         }
> 
> For for this PR but at some point I'd like to know if the EBADF handling is dead code. It shouldn't happen, at least not with the usages in sun.nio.ch/libnio but maybe there is something that I can't think of.

I've added it to my TODO list and will file a JBS issue after investigating a bit more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727723238

From jpai at openjdk.org  Mon Jan 26 14:03:23 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jan 2026 14:03:23 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v3]
In-Reply-To: <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <xF4tNjgXJg1M9T7zG-4E4ul8DP1vEsGfwFOHTmlAp8A=.2cd0dd7b-2f5e-4f52-8ae8-4cd7ee139766@github.com>
 <Lb3RjbIP11qeT6c3WVzCnroumsFKu3yru0DoG5Xvrr4=.668725aa-f0aa-4743-9d05-048739755bce@github.com>
 <XNXbfpXI1493lm3uvdgFgjDUbi7IbU3hZP4AwamxDZY=.227c0e67-a116-4920-ad57-066d90a2ef82@github.com>
Message-ID: <mwv39ZxtAhfhdfup9UqCk_M14H4pltChUFqEobRllnU=.65ea9078-bea0-4459-bb60-c10f208313ae@github.com>

On Mon, 26 Jan 2026 13:31:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 90:
>> 
>>> 88:                         // this test checks the exception message of a ConnectException, so it's
>>> 89:                         // OK to skip the test if something unexpectedly accepted the connection
>>> 90:                         throw new TestAbortedException("unexpectedly connected to " + destAddr);
>> 
>> Could this use the assumptions API too? Only asking because we've now got a mix of assumptions API and TestAbortedException.
>
> The reason I used the exception type directly was it looked a bit odd to read something like:
> 
> 
> boolean success = sc.finishConnect();
> if (success) {
>     // this test checks the exception message of a ConnectException, so it's
>     // OK to skip the test if something unexpectedly accepted the connection
>     assumeTrue(success, "unexpectedly connected to " + destAddr);
> }
> fail("ConnectException was not thrown");
> 
> 
> but I don't have a strong preference here. I'll switch to using the `Assumptions.assumeXXX` API.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2727720793

From abarashev at openjdk.org  Mon Jan 26 17:43:16 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 26 Jan 2026 17:43:16 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v8]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <H1_Cmuze7aXkmSKJfG5fsgFVfMTKoC0rlekNA313gP4=.2ca4e35b-e986-4c04-8738-e038022ad882@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Move caching to CompressedCertificate. Add caching unit tests. Update benchmark test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/c0fd9b86..4f99f4fb

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

  Stats: 378 lines in 5 files changed: 322 ins; 25 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From alanb at openjdk.org  Mon Jan 26 19:37:12 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jan 2026 19:37:12 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
Message-ID: <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>

On Mon, 26 Jan 2026 14:03:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace TestAbortedException with Assumptions.assumeTrue

Marked as reviewed by alanb (Reviewer).

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 91:

> 89:                         assumeTrue(success, "unexpectedly connected to " + destAddr);
> 90:                     }
> 91:                     fail("ConnectException was not thrown");

The test is fine, I'm just curious why the assumeTrue is predicated on success being true, is this left over from the previous iteration? If it is removed then the fail goes away too.

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

PR Review: https://git.openjdk.org/jdk/pull/29409#pullrequestreview-3707652821
PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2728960365

From vyazici at openjdk.org  Mon Jan 26 20:23:14 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 26 Jan 2026 20:23:14 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java tests
 fail on EC2
Message-ID: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>

Fix tests using `AbstractConnectTimeout` by replacing the usage of an external host (i.e., `example.com`), which unexpectedly resolves to a real IP address on certain test hosts, with a custom `ServerSocket` bootstrapped by the test.

The initial PR contains 3 commits:

1. b06f2606c88 Replace external domain with a custom `ServerSocket` (i.e., _"the fix"_)
2. b9262c7ca01 Remove the need for multiple test files
3. d95a335db93 Migrate tests to JUnit

All commits (i.e., 1, 1+2, and 1+2+3) pass tests.

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

Commit messages:
 - Migrate tests to JUnit
 - Remove the need for multiple test files
 - Replace external domain with a custom `ServerSocket`

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

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

From abarashev at openjdk.org  Mon Jan 26 22:41:29 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 26 Jan 2026 22:41:29 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Allocate 24 bits for input size in cache key. Add unit tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/4f99f4fb..358840fc

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

  Stats: 197 lines in 5 files changed: 147 ins; 31 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From jpai at openjdk.org  Tue Jan 27 07:42:19 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 07:42:19 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

Jaikiran Pai 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 10 additional commits since the last revision:

 - merge latest from master branch
 - fix assumption in test
 - merge latest from master branch
 - replace TestAbortedException with Assumptions.assumeTrue
 - skip the test if the SocketChannel unexpectedly connects to the destination address
 - rename test to ConnectionRefusedMessage
 - formatting
 - add bug id to the test
 - allow NULL for msg in NET_ThrowNew
 - introduce test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/c184f07a..b57b088e

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

  Stats: 3279 lines in 133 files changed: 1600 ins; 833 del; 846 mod
  Patch: https://git.openjdk.org/jdk/pull/29409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29409/head:pull/29409

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

From jpai at openjdk.org  Tue Jan 27 07:42:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 07:42:21 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v4]
In-Reply-To: <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <MTlbO1-MgJv5l-of7IqLr-oBKa-AuAIOzOlwPwhOz7U=.ca7b26c0-118f-4701-82d2-9463ed51f1c2@github.com>
 <BTioWK4SuepADZCM28obMAYpVrMmFrhYmMl9AioYURs=.32d6b576-be68-4796-9cc9-7a875abc7c32@github.com>
Message-ID: <-hza3ECeKacPnF61JzqFczwINXQzF_m3qPcrEeQOvKo=.43548ae0-d65d-462c-8400-288154d7716e@github.com>

On Mon, 26 Jan 2026 19:33:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace TestAbortedException with Assumptions.assumeTrue
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 91:
> 
>> 89:                         assumeTrue(success, "unexpectedly connected to " + destAddr);
>> 90:                     }
>> 91:                     fail("ConnectException was not thrown");
> 
> The test is fine, I'm just curious why the assumeTrue is predicated on success being true, is this left over from the previous iteration? If it is removed then the fail goes away too.

Hello Alan, I got that assumeTrue call wrong in that previous update. What I really wanted there was to skip the test if finishConnect() returned true (i.e. if something unexpectedly accepted the connection). The test doesn't expect finishConnect() to complete normally with a return value of false, and if that happens then I wanted to fail the test. I've now updated the PR accordingly. Does this look reasonable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2730647640

From dfuchs at openjdk.org  Tue Jan 27 10:12:43 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 10:12:43 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2
In-Reply-To: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
Message-ID: <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>

On Mon, 26 Jan 2026 20:14:32 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fix tests using `AbstractConnectTimeout` by replacing the usage of an external host (i.e., `example.com`), which unexpectedly resolves to a real IP address on certain test hosts, with a custom `ServerSocket` bootstrapped by the test.
> 
> The initial PR contains 3 commits:
> 
> 1. b06f2606c88 Replace external domain with a custom `ServerSocket` (i.e., _"the fix"_)
> 2. b9262c7ca01 Remove the need for multiple test files
> 3. d95a335db93 Migrate tests to JUnit
> 
> All commits (i.e., 1, 1+2, and 1+2+3) pass tests.

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 67:

> 65:  * @run junit/othervm -Dtest.proxy ${test.main.class}
> 66:  * @run junit/othervm -Dtest.async ${test.main.class}
> 67:  * @run junit/othervm -Dtest.async -Dtest.proxy ${test.main.class}

Instead of several `@run lines` - can you create several `@test id=...` comments?

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 108:

> 106:                                 "Failed creating client socket %s/%s",
> 107:                                 (socketIndex + 1), socketCount);
> 108:                         throw new RuntimeException(message, ioe);

why not `UncheckedIOException`? alternatively a simple for loop ...

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 181:

> 179:             Duration requestTimeout)
> 180:             throws Exception {
> 181:         ProxySelector proxySelector = System.getProperty("test.proxy") != null ? PROXY_SELECTOR : NO_PROXY;

Can we use Boolean.getBoolean here? Or at least have some code that wouldn't evaluate `-Dtest.proxy=false` as `true`

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 183:

> 181:         ProxySelector proxySelector = System.getProperty("test.proxy") != null ? PROXY_SELECTOR : NO_PROXY;
> 182:         boolean async = System.getProperty("test.async") != null;
> 183:         if (async) {

Same here.

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 202:

> 200: 
> 201:         for (int i = 0; i < 2; i++) {
> 202:             System.err.printf("iteration %d%n", i);

I'd keep that in `out` rather than `err`. I kind of like having a short summary of what happened in stdout (rather than have it burried within the debug log and possibly lost in the output overflow).

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 291:

> 289:     private static void assertExceptionTypeAndCause(Throwable t) {
> 290:         if (!(t instanceof HttpConnectTimeoutException)) {
> 291:             t.printStackTrace(System.err);

Let's keep that in `out` too. For same reason.

test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 311:

> 309:         System.err.println("Headers: " + response.headers());
> 310:         System.err.println("Body: " + response.body());
> 311:     }

ditto

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731166234
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731177602
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731209131
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731211802
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731225093
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731229687
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731231475

From dfuchs at openjdk.org  Tue Jan 27 10:12:45 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 10:12:45 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2
In-Reply-To: <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
Message-ID: <8kKDKZmOTcZVgpuRUg8ph9XHORbWUtGxHatwnIGApoM=.e75f76be-9ec4-4c97-9529-ad665b0a508a@github.com>

On Tue, 27 Jan 2026 09:55:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Fix tests using `AbstractConnectTimeout` by replacing the usage of an external host (i.e., `example.com`), which unexpectedly resolves to a real IP address on certain test hosts, with a custom `ServerSocket` bootstrapped by the test.
>> 
>> The initial PR contains 3 commits:
>> 
>> 1. b06f2606c88 Replace external domain with a custom `ServerSocket` (i.e., _"the fix"_)
>> 2. b9262c7ca01 Remove the need for multiple test files
>> 3. d95a335db93 Migrate tests to JUnit
>> 
>> All commits (i.e., 1, 1+2, and 1+2+3) pass tests.
>
> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 108:
> 
>> 106:                                 "Failed creating client socket %s/%s",
>> 107:                                 (socketIndex + 1), socketCount);
>> 108:                         throw new RuntimeException(message, ioe);
> 
> why not `UncheckedIOException`? alternatively a simple for loop ...

Have you tried to uncondiotionnaly throw an exception here to see how it shows up in the test log? IIRC throwing in static initializer in test classes didn't give very user friendly diagnosis. But I have never seen how it looked like with junit :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731195802

From dfuchs at openjdk.org  Tue Jan 27 10:12:46 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 10:12:46 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2
In-Reply-To: <8kKDKZmOTcZVgpuRUg8ph9XHORbWUtGxHatwnIGApoM=.e75f76be-9ec4-4c97-9529-ad665b0a508a@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
 <8kKDKZmOTcZVgpuRUg8ph9XHORbWUtGxHatwnIGApoM=.e75f76be-9ec4-4c97-9529-ad665b0a508a@github.com>
Message-ID: <gSXXUiu4e0OshXuEmsq-RQcYoAqQifaS9aDSn0jhZDE=.aef1d559-d88b-424a-b3e3-47325f9be831@github.com>

On Tue, 27 Jan 2026 09:59:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 108:
>> 
>>> 106:                                 "Failed creating client socket %s/%s",
>>> 107:                                 (socketIndex + 1), socketCount);
>>> 108:                         throw new RuntimeException(message, ioe);
>> 
>> why not `UncheckedIOException`? alternatively a simple for loop ...
>
> Have you tried to uncondiotionnaly throw an exception here to see how it shows up in the test log? IIRC throwing in static initializer in test classes didn't give very user friendly diagnosis. But I have never seen how it looked like with junit :-)

Just to see if doing this during class initialization is OK - or if we should rather move that to a method annotated with `@BeforeAll`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2731201132

From msheppar at openjdk.org  Tue Jan 27 12:03:19 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 Jan 2026 12:03:19 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
Message-ID: <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>

On Tue, 27 Jan 2026 07:42:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai 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 10 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - fix assumption in test
>  - merge latest from master branch
>  - replace TestAbortedException with Assumptions.assumeTrue
>  - skip the test if the SocketChannel unexpectedly connects to the destination address
>  - rename test to ConnectionRefusedMessage
>  - formatting
>  - add bug id to the test
>  - allow NULL for msg in NET_ThrowNew
>  - introduce test

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:

> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
> 107:         // port 47 is reserved - there should be nothing listening on it
> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);

a general comment on the dest port selections below, 47, 51, 61.
These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment

As such, a comment in the test would be useful, such as,

// using ports 47, 51, 61 from the the IANA reserved port list, which
// are currently unassigned, on the assumption they will not used by
// a listening service

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2731678262

From djelinski at openjdk.org  Tue Jan 27 14:01:58 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jan 2026 14:01:58 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
Message-ID: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>

This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.

Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

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

Commit messages:
 - Remove excessive locking

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

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

From vyazici at openjdk.org  Tue Jan 27 14:42:15 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 Jan 2026 14:42:15 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2 [v2]
In-Reply-To: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
Message-ID: <DhCOjvHmAyhpgSXYkYL1_zPZZ5sOPbfZhcMcILF5h9A=.40403ad0-d85e-4e87-afc3-75727cbfccea@github.com>

> Fix tests using `AbstractConnectTimeout` by replacing the usage of an external host (i.e., `example.com`), which unexpectedly resolves to a real IP address on certain test hosts, with a custom `ServerSocket` bootstrapped by the test.
> 
> The initial PR contains 3 commits:
> 
> 1. b06f2606c88 Replace external domain with a custom `ServerSocket` (i.e., _"the fix"_)
> 2. b9262c7ca01 Remove the need for multiple test files
> 3. d95a335db93 Migrate tests to JUnit
> 
> All commits (i.e., 1, 1+2, and 1+2+3) pass tests.

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

  Apply review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29431/files
  - new: https://git.openjdk.org/jdk/pull/29431/files/466696c1..fc639467

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

  Stats: 118 lines in 1 file changed: 72 ins; 1 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/29431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29431/head:pull/29431

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

From vyazici at openjdk.org  Tue Jan 27 14:42:22 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 Jan 2026 14:42:22 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2 [v2]
In-Reply-To: <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
Message-ID: <-QJ9M0gbfGB4vIA4UkLX7U0m9uZRyLhtc6cpvShAOC0=.dbe58d3b-cdc1-4317-83eb-af1344f901f6@github.com>

On Tue, 27 Jan 2026 09:52:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 67:
> 
>> 65:  * @run junit/othervm -Dtest.proxy ${test.main.class}
>> 66:  * @run junit/othervm -Dtest.async ${test.main.class}
>> 67:  * @run junit/othervm -Dtest.async -Dtest.proxy ${test.main.class}
> 
> Instead of several `@run lines` - can you create several `@test id=...` comments?

Done in fc639467db1.

> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 181:
> 
>> 179:             Duration requestTimeout)
>> 180:             throws Exception {
>> 181:         ProxySelector proxySelector = System.getProperty("test.proxy") != null ? PROXY_SELECTOR : NO_PROXY;
> 
> Can we use Boolean.getBoolean here? Or at least have some code that wouldn't evaluate `-Dtest.proxy=false` as `true`

Done in fc639467db1.

> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 183:
> 
>> 181:         ProxySelector proxySelector = System.getProperty("test.proxy") != null ? PROXY_SELECTOR : NO_PROXY;
>> 182:         boolean async = System.getProperty("test.async") != null;
>> 183:         if (async) {
> 
> Same here.

Done in fc639467db1.

> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 202:
> 
>> 200: 
>> 201:         for (int i = 0; i < 2; i++) {
>> 202:             System.err.printf("iteration %d%n", i);
> 
> I'd keep that in `out` rather than `err`. I kind of like having a short summary of what happened in stdout (rather than have it burried within the debug log and possibly lost in the output overflow).

Done in fc639467db1.

> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 291:
> 
>> 289:     private static void assertExceptionTypeAndCause(Throwable t) {
>> 290:         if (!(t instanceof HttpConnectTimeoutException)) {
>> 291:             t.printStackTrace(System.err);
> 
> Let's keep that in `out` too. For same reason.

Done in fc639467db1.

> test/jdk/java/net/httpclient/ConnectTimeoutTest.java line 311:
> 
>> 309:         System.err.println("Headers: " + response.headers());
>> 310:         System.err.println("Body: " + response.body());
>> 311:     }
> 
> ditto

Done in fc639467db1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732325786
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732336903
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732337328
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732338140
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732338817
PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732339308

From vyazici at openjdk.org  Tue Jan 27 14:42:22 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 Jan 2026 14:42:22 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2 [v2]
In-Reply-To: <gSXXUiu4e0OshXuEmsq-RQcYoAqQifaS9aDSn0jhZDE=.aef1d559-d88b-424a-b3e3-47325f9be831@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <Zq492qI1ePaWIfYI2gFy-9CbVFoHfBpHQHy1EGSrYAk=.a3075beb-4547-470b-8b67-e3d739b6461a@github.com>
 <8kKDKZmOTcZVgpuRUg8ph9XHORbWUtGxHatwnIGApoM=.e75f76be-9ec4-4c97-9529-ad665b0a508a@github.com>
 <gSXXUiu4e0OshXuEmsq-RQcYoAqQifaS9aDSn0jhZDE=.aef1d559-d88b-424a-b3e3-47325f9be831@github.com>
Message-ID: <WTBYyJMTEkIwGDXwl92QUkh0a_BBTnBKKC_zXW4w_HE=.9ad21e5e-10a1-41dd-a930-127ef8c8d397@github.com>

On Tue, 27 Jan 2026 10:01:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Have you tried to uncondiotionnaly throw an exception here to see how it shows up in the test log? IIRC throwing in static initializer in test classes didn't give very user friendly diagnosis. But I have never seen how it looked like with junit :-)
>
> Just to see if doing this during class initialization is OK - or if we should rather move that to a method annotated with `@BeforeAll`.

> why not `UncheckedIOException`?

Because one less `import` line.

> Have you tried to uncondiotionnaly throw an exception here to see how it shows up in the test log? IIRC throwing in static initializer in test classes didn't give very user friendly diagnosis.

Verified that it is all good on JTreg+JUnit output.

> alternatively a simple for loop

Done in fc639467db1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29431#discussion_r2732335223

From vyazici at openjdk.org  Tue Jan 27 15:02:35 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 Jan 2026 15:02:35 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>

On Tue, 27 Jan 2026 13:54:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 331:

> 329:             }
> 330:             ByteBuffer buffer = current();
> 331:             if (buffer == QuicStreamReader.EOF) {

Assume `current()` has failed and called `close(io)`, which registered `error`. If `buffer == EOF` (line 331) doesn't hold ? which, AFAICT, it can ? we will return `buffer.get() & 0xFF`. I guess this would be unexpected, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732440952

From dfuchs at openjdk.org  Tue Jan 27 15:39:11 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 15:39:11 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <U08B-Vdgf4XyAA7frTqdpejTLAWB6YGtcZIqKopNixI=.d42947d0-5846-4c66-bd17-68108c9d2f79@github.com>

On Tue, 27 Jan 2026 13:54:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 329:

> 327:             if (closed) {
> 328:                 throw new IOException("Stream is closed");
> 329:             }

No sure we want that. If there is some unread data we want to read it first.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 329:

> 327:             if (closed) {
> 328:                 throw new IOException("Stream is closed");
> 329:             }

No sure we want that. If there is some unread data we want to read it first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732601433
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732606107

From dfuchs at openjdk.org  Tue Jan 27 15:48:51 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 15:48:51 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>

On Tue, 27 Jan 2026 13:54:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 320:

> 318:                     close(io);
> 319:                     var error = this.error;
> 320:                     if (error != null) throw error;

we should use the lock around these two lines.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 334:

> 332:                 if (closed) {
> 333:                     throw new IOException("Stream is closed");
> 334:                 }

we should not do that if this.error != null.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 347:

> 345:             if (closed) {
> 346:                 throw new IOException("Stream is closed");
> 347:             }

Same here - we should read off any remaining data first.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 355:

> 353:                         if (closed) {
> 354:                             throw new IOException("Stream is closed");
> 355:                         }

ditto - we should not replace the exception that was passed to close(), if any.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 358:

> 356:                         var error = this.error;
> 357:                         if (error == null) return -1;
> 358:                         throw error;

these lines should be protected by the lock.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 371:

> 369:         public void close() throws IOException {
> 370:             if (closed) return;
> 371:             closed = true;

these lines should be protected by the lock.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 379:

> 377:         void close(IOException io) {
> 378:             if (error != null) return;
> 379:             error = io;

close can be asynchronous. We should keep the lock here - or use synchronized.

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

PR Review: https://git.openjdk.org/jdk/pull/29448#pullrequestreview-3711923100
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732633330
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732614669
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732617261
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732646645
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732653698
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732656061
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732623273

From jpai at openjdk.org  Tue Jan 27 15:55:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 15:55:11 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

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

  update code comment in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29409/files
  - new: https://git.openjdk.org/jdk/pull/29409/files/b57b088e..2ad911f9

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

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

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

From jpai at openjdk.org  Tue Jan 27 15:55:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jan 2026 15:55:16 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
 <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
Message-ID: <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>

On Tue, 27 Jan 2026 12:00:44 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Jaikiran Pai 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 10 additional commits since the last revision:
>> 
>>  - merge latest from master branch
>>  - fix assumption in test
>>  - merge latest from master branch
>>  - replace TestAbortedException with Assumptions.assumeTrue
>>  - skip the test if the SocketChannel unexpectedly connects to the destination address
>>  - rename test to ConnectionRefusedMessage
>>  - formatting
>>  - add bug id to the test
>>  - allow NULL for msg in NET_ThrowNew
>>  - introduce test
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:
> 
>> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
>> 107:         // port 47 is reserved - there should be nothing listening on it
>> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);
> 
> a general comment on the dest port selections below, 47, 51, 61.
> These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment
> 
> As such, a comment in the test would be useful, such as,
> 
> // using ports 47, 51, 61 from the the IANA reserved port list, which
> // are currently unassigned, on the assumption they will not used by
> // a listening service

Done, I've used your suggestion and updated that comment to be more descriptive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2732676508

From msheppar at openjdk.org  Tue Jan 27 16:24:38 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 Jan 2026 16:24:38 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v5]
In-Reply-To: <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <c3SMWxhpTwdBfwa1MjqlM6n8Ii-MMFaOAl_cvF_ajRQ=.09819a48-7174-47a0-8eab-7c3c41c54498@github.com>
 <GeQRZMc97BESTvztKeNPh-tdkL-Towl-xn9eqXsgHKo=.58a36ff6-0079-4103-81ad-2d48f1369338@github.com>
 <q3OR1IYg-kwz4tv_Kcn7-9nT1a7uPcGb17bqBnK_kic=.e0a09b00-1995-451a-b3ac-e4517d7a8ec5@github.com>
Message-ID: <NAiCOiATtX7bKN0ySbnh0u1M3Vc-AsI0TNrDVMPQHW4=.cdbf4abf-1e95-4973-9188-4e9b0480bd71@github.com>

On Tue, 27 Jan 2026 15:49:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:
>> 
>>> 106:         final InetAddress loopbackAddr = InetAddress.getLoopbackAddress();
>>> 107:         // port 47 is reserved - there should be nothing listening on it
>>> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 47);
>> 
>> a general comment on the dest port selections below, 47, 51, 61.
>> These are currently marked as reserved in the IANA port list, but if you look at the /etc/services file, on macos, you will see that there is a legacy assignment
>> 
>> As such, a comment in the test would be useful, such as,
>> 
>> // using ports 47, 51, 61 from the the IANA reserved port list, which
>> // are currently unassigned, on the assumption they will not used by
>> // a listening service
>
> Done, I've used your suggestion and updated that comment to be more descriptive.

cheers ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2732819153

From jvernee at openjdk.org  Tue Jan 27 16:57:35 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jan 2026 16:57:35 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3806333930

From xuelei at openjdk.org  Tue Jan 27 16:57:43 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 27 Jan 2026 16:57:43 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
Message-ID: <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>

On Mon, 26 Jan 2026 22:41:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allocate 24 bits for input size in cache key. Add unit tests.

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:

> 980:             boolean enableCertificateCompression) {
> 981:         this.enableCertificateCompression = enableCertificateCompression;
> 982:     }

Is there a plan to support brotli compression algorithm in OpenJDK?  It is the only supported algorithm in browser Chrome.

If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences.  The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.

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

PR Review: https://git.openjdk.org/jdk/pull/28682#pullrequestreview-3712350928
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2732956812

From djelinski at openjdk.org  Tue Jan 27 17:19:00 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jan 2026 17:19:00 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <Ni9WIZIaRW_M822jmdCqMNyf-0t_Hhe1mzSlkYYZsqM=.acf9bc68-8c8a-4237-ad74-f9842b22c933@github.com>

On Tue, 27 Jan 2026 13:54:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

Thanks @vy @dfuch for the reviews.

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

PR Review: https://git.openjdk.org/jdk/pull/29448#pullrequestreview-3712406311

From djelinski at openjdk.org  Tue Jan 27 17:19:08 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jan 2026 17:19:08 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
Message-ID: <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>

On Tue, 27 Jan 2026 15:41:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 320:
> 
>> 318:                     close(io);
>> 319:                     var error = this.error;
>> 320:                     if (error != null) throw error;
> 
> we should use the lock around these two lines.

I'll revisit that.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 329:
> 
>> 327:             if (closed) {
>> 328:                 throw new IOException("Stream is closed");
>> 329:             }
> 
> No sure we want that. If there is some unread data we want to read it first.

The InputStream spec states that `read` throws `IOException` if the stream was closed. Note that we no longer set `closed = true` on error.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 334:
> 
>> 332:                 if (closed) {
>> 333:                     throw new IOException("Stream is closed");
>> 334:                 }
> 
> we should not do that if this.error != null.

I'd say that `closed` has a higher priority than `error`, because `closed` means that the stream was closed by the user.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 358:
> 
>> 356:                         var error = this.error;
>> 357:                         if (error == null) return -1;
>> 358:                         throw error;
> 
> these lines should be protected by the lock.

That's not necessary. If we received an EOF, either the InputStream is closed, or the QUIC stream is finished, or it is reset. The closed case was already handled above, and EOF and reset are mutually exclusive.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 371:
> 
>> 369:         public void close() throws IOException {
>> 370:             if (closed) return;
>> 371:             closed = true;
> 
> these lines should be protected by the lock.

I don't think it's needed. The worst thing that could happen is that we will log twice.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 379:
> 
>> 377:         void close(IOException io) {
>> 378:             if (error != null) return;
>> 379:             error = io;
> 
> close can be asynchronous. We should keep the lock here - or use synchronized.

I'll update the code so that these lines will only be called in response to stream reset, once per stream, in a sequential scheduler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732995462
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2732997859
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733011677
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733022002
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733025721
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733028936

From djelinski at openjdk.org  Tue Jan 27 17:19:11 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jan 2026 17:19:11 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest
In-Reply-To: <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>
Message-ID: <uXvpV4b2PYyIUOWEqdRSYWhzcfTDydGRkYKoBs_Kh9E=.23afb179-5ead-4cbe-8376-bd437a6a108c@github.com>

On Tue, 27 Jan 2026 15:00:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 331:
> 
>> 329:             }
>> 330:             ByteBuffer buffer = current();
>> 331:             if (buffer == QuicStreamReader.EOF) {
> 
> Assume `current()` has failed and called `close(io)`, which registered `error`. If `buffer == EOF` (line 331) doesn't hold ? which, AFAICT, it can ? we will return `buffer.get() & 0xFF`. I guess this would be unexpected, right?

Right. I'll change that; nothing in the `InputStream` spec states that the stream must be left in an unusable state after an exception, so I'll just stop setting the error here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733008147

From abarashev at openjdk.org  Tue Jan 27 17:27:43 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 27 Jan 2026 17:27:43 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
Message-ID: <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>

On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allocate 24 bits for input size in cache key. Add unit tests.
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> 
>> 980:             boolean enableCertificateCompression) {
>> 981:         this.enableCertificateCompression = enableCertificateCompression;
>> 982:     }
> 
> Is there a plan to support brotli compression algorithm in OpenJDK?  It is the only supported algorithm in browser Chrome.
> 
> If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences.  The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.

Yes, strangely Chrome supports only brotli although I didn't see any difference in compression ration between zlib and brotli when manually testing certificate compression. We may add support for more algorithms in the future, but for now it's zlib only.
Generally speaking, it's the certificate's metadata that is being compressed, the keys are high-entropy data difficult to compress. PQC certificates don?t compress well, most likely because of lower metadata to keys ratio.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369

From djelinski at openjdk.org  Tue Jan 27 18:54:52 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jan 2026 18:54:52 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Do not reset stream when read is interrupted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29448/files
  - new: https://git.openjdk.org/jdk/pull/29448/files/2504e170..a8a5415c

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

  Stats: 34 lines in 2 files changed: 10 ins; 15 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/29448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29448/head:pull/29448

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

From dfuchs at openjdk.org  Tue Jan 27 19:10:58 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 19:10:58 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
Message-ID: <PV8JgXl3G1yIGF13s9iK9rJgH2l5InhQaT9TyVP2dCA=.004f1afb-7c2c-4b7d-b354-4eaaee47d9a4@github.com>

On Tue, 27 Jan 2026 15:38:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not reset stream when read is interrupted
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 347:
> 
>> 345:             if (closed) {
>> 346:                 throw new IOException("Stream is closed");
>> 347:             }
> 
> Same here - we should read off any remaining data first.

OK - you should resolve this thread now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733439760

From dfuchs at openjdk.org  Tue Jan 27 19:11:01 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 19:11:01 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
 <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
Message-ID: <rMZgwKqmZ_hhOBlj-QqkJCjIPeXLcXAcyTHpKAqnlko=.4c32264c-97e9-4216-b0f6-36b9ed06fc57@github.com>

On Tue, 27 Jan 2026 17:10:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 371:
>> 
>>> 369:         public void close() throws IOException {
>>> 370:             if (closed) return;
>>> 371:             closed = true;
>> 
>> these lines should be protected by the lock.
>
> I don't think it's needed. The worst thing that could happen is that we will log twice.

and add EOF twice

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733443550

From dfuchs at openjdk.org  Tue Jan 27 19:10:55 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jan 2026 19:10:55 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
Message-ID: <Wven6q3THpto3OLZnYIR2cbhNP8Gy9dbzaRxq_TI1bA=.a504d146-dff2-405b-bc28-1174e02b83f4@github.com>

On Tue, 27 Jan 2026 18:54:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not reset stream when read is interrupted

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 337:

> 335:             ByteBuffer buffer = current();
> 336:             if (buffer == QuicStreamReader.EOF) {
> 337:                 return -1;

I don't think that's correct. If we get an error we set the error flag AND add EOF to the buffer list to unblock the reader. Therefore, you must check whether error == null before returning -1 - I believe you should restore lines 334-336 here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2733435912

From djelinski at openjdk.org  Wed Jan 28 08:23:25 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Jan 2026 08:23:25 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <uXvpV4b2PYyIUOWEqdRSYWhzcfTDydGRkYKoBs_Kh9E=.23afb179-5ead-4cbe-8376-bd437a6a108c@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>
 <uXvpV4b2PYyIUOWEqdRSYWhzcfTDydGRkYKoBs_Kh9E=.23afb179-5ead-4cbe-8376-bd437a6a108c@github.com>
Message-ID: <HskQ-c3eJ1u2QFFrmMGhisRqqVfaNxl_0PuG3STL4CM=.7543f8d0-d3ad-406f-86f8-3a46968e2cc7@github.com>

On Tue, 27 Jan 2026 17:06:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 331:
>> 
>>> 329:             }
>>> 330:             ByteBuffer buffer = current();
>>> 331:             if (buffer == QuicStreamReader.EOF) {
>> 
>> Assume `current()` has failed and called `close(io)`, which registered `error`. If `buffer == EOF` (line 331) doesn't hold ? which, AFAICT, it can ? we will return `buffer.get() & 0xFF`. I guess this would be unexpected, right?
>
> Right. I'll change that; nothing in the `InputStream` spec states that the stream must be left in an unusable state after an exception, so I'll just stop setting the error here.

Changed; the InterruptedIOException does not set `error` anymore, so if the caller of `read()` chooses to clear the interrupted status, it's possible to keep reading from the stream after the exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2735398793

From djelinski at openjdk.org  Wed Jan 28 08:23:30 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Jan 2026 08:23:30 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <Wven6q3THpto3OLZnYIR2cbhNP8Gy9dbzaRxq_TI1bA=.a504d146-dff2-405b-bc28-1174e02b83f4@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <Wven6q3THpto3OLZnYIR2cbhNP8Gy9dbzaRxq_TI1bA=.a504d146-dff2-405b-bc28-1174e02b83f4@github.com>
Message-ID: <gY6XpZ6JW0r70dFbK0kAtoSofZ35vIC44TZJDlJIwU8=.5f772244-b7f9-44a3-a31e-522d6dd02760@github.com>

On Tue, 27 Jan 2026 19:05:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not reset stream when read is interrupted
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 337:
> 
>> 335:             ByteBuffer buffer = current();
>> 336:             if (buffer == QuicStreamReader.EOF) {
>> 337:                 return -1;
> 
> I don't think that's correct. If we get an error we set the error flag AND add EOF to the buffer list to unblock the reader. Therefore, you must check whether error == null before returning -1 - I believe you should restore lines 334-336 here.

I'm checking that in the `current()` method now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2735392441

From djelinski at openjdk.org  Wed Jan 28 08:23:32 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Jan 2026 08:23:32 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <rMZgwKqmZ_hhOBlj-QqkJCjIPeXLcXAcyTHpKAqnlko=.4c32264c-97e9-4216-b0f6-36b9ed06fc57@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
 <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
 <rMZgwKqmZ_hhOBlj-QqkJCjIPeXLcXAcyTHpKAqnlko=.4c32264c-97e9-4216-b0f6-36b9ed06fc57@github.com>
Message-ID: <cMJturh97wCtpw3TlqS95tjLmfKiAP2m2vcgIhnT3BU=.67457b1d-24d8-4cef-a881-28659e7e05b6@github.com>

On Tue, 27 Jan 2026 19:07:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I don't think it's needed. The worst thing that could happen is that we will log twice.
>
> and add EOF twice

This is not a problem; as soon as we read EOF, nothing else will ever be read from the queue, and the queue can be expected to be GCed soon after.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2735390799

From dfuchs at openjdk.org  Wed Jan 28 11:03:51 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:03:51 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
 <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
Message-ID: <1h_NPaxqvIABym5-u5TVwSBZPhJLzWxiqJKXFpBMRfw=.b5351aa8-27ad-4d4a-8f1e-efc24a8a1056@github.com>

On Tue, 27 Jan 2026 17:07:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 334:
>> 
>>> 332:                 if (closed) {
>>> 333:                     throw new IOException("Stream is closed");
>>> 334:                 }
>> 
>> we should not do that if this.error != null.
>
> I'd say that `closed` has a higher priority than `error`, because `closed` means that the stream was closed by the user.

OK. We can revisit later if we see that the `error` throwable should have appeared in the log but doesn't.

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 358:
>> 
>>> 356:                         var error = this.error;
>>> 357:                         if (error == null) return -1;
>>> 358:                         throw error;
>> 
>> these lines should be protected by the lock.
>
> That's not necessary. If we received an EOF, either the InputStream is closed, or the QUIC stream is finished, or it is reset. The closed case was already handled above, and EOF and reset are mutually exclusive.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736099443
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736101814

From dfuchs at openjdk.org  Wed Jan 28 11:03:54 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:03:54 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <cMJturh97wCtpw3TlqS95tjLmfKiAP2m2vcgIhnT3BU=.67457b1d-24d8-4cef-a881-28659e7e05b6@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <7_CRa-vgIHH7IbHqaB_o3UphgBaQQfbgMd0rPfzGojI=.d9af7852-cb1f-479b-a28e-62476345cc6a@github.com>
 <Ya8A19_xnbMxxNK94KuSSegWVbZKQzoj3aCvPGCJ7-c=.f7883599-dffa-4812-96b1-ee396f546b0c@github.com>
 <rMZgwKqmZ_hhOBlj-QqkJCjIPeXLcXAcyTHpKAqnlko=.4c32264c-97e9-4216-b0f6-36b9ed06fc57@github.com>
 <cMJturh97wCtpw3TlqS95tjLmfKiAP2m2vcgIhnT3BU=.67457b1d-24d8-4cef-a881-28659e7e05b6@github.com>
Message-ID: <v7bVj2o9hmcZay1QxoLQDdwqKeq3_7MOqF4SmzKy4JM=.9284ec99-a032-4567-8f47-7897cb3d3eca@github.com>

On Wed, 28 Jan 2026 08:18:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> and add EOF twice
>
> This is not a problem; as soon as we read EOF, nothing else will ever be read from the queue, and the queue can be expected to be GCed soon after.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736103624

From dfuchs at openjdk.org  Wed Jan 28 11:10:44 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:10:44 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
Message-ID: <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>

On Tue, 27 Jan 2026 18:54:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not reset stream when read is interrupted

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 327:

> 325:                     var io = new InterruptedIOException();
> 326:                     Thread.currentThread().interrupt();
> 327:                     io.initCause(e);

Maybe we should set `closed = true` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736120591

From dfuchs at openjdk.org  Wed Jan 28 11:10:46 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:10:46 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <HskQ-c3eJ1u2QFFrmMGhisRqqVfaNxl_0PuG3STL4CM=.7543f8d0-d3ad-406f-86f8-3a46968e2cc7@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>
 <uXvpV4b2PYyIUOWEqdRSYWhzcfTDydGRkYKoBs_Kh9E=.23afb179-5ead-4cbe-8376-bd437a6a108c@github.com>
 <HskQ-c3eJ1u2QFFrmMGhisRqqVfaNxl_0PuG3STL4CM=.7543f8d0-d3ad-406f-86f8-3a46968e2cc7@github.com>
Message-ID: <EQPyNdxve_DckMT_pK2HK_jT6wnqkDm9H5JqBXQ6j5E=.b77a8880-539f-466e-b732-73c6fe333635@github.com>

On Wed, 28 Jan 2026 08:20:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Right. I'll change that; nothing in the `InputStream` spec states that the stream must be left in an unusable state after an exception, so I'll just stop setting the error here.
>
> Changed; the InterruptedIOException does not set `error` anymore, so if the caller of `read()` chooses to clear the interrupted status, it's possible to keep reading from the stream after the exception.

Maybe we should set `close = true` when we catch InterruptedException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736121269

From dfuchs at openjdk.org  Wed Jan 28 11:10:50 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:10:50 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <gY6XpZ6JW0r70dFbK0kAtoSofZ35vIC44TZJDlJIwU8=.5f772244-b7f9-44a3-a31e-522d6dd02760@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <Wven6q3THpto3OLZnYIR2cbhNP8Gy9dbzaRxq_TI1bA=.a504d146-dff2-405b-bc28-1174e02b83f4@github.com>
 <gY6XpZ6JW0r70dFbK0kAtoSofZ35vIC44TZJDlJIwU8=.5f772244-b7f9-44a3-a31e-522d6dd02760@github.com>
Message-ID: <vIeEcCJvzohjHV0mB2dnsiM_Xzg0WZ7ybJ0YQxtZFAs=.ee66b768-2cc6-4dc9-9e76-eaa4b28b601c@github.com>

On Wed, 28 Jan 2026 08:18:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 337:
>> 
>>> 335:             ByteBuffer buffer = current();
>>> 336:             if (buffer == QuicStreamReader.EOF) {
>>> 337:                 return -1;
>> 
>> I don't think that's correct. If we get an error we set the error flag AND add EOF to the buffer list to unblock the reader. Therefore, you must check whether error == null before returning -1 - I believe you should restore lines 334-336 here.
>
> I'm checking that in the `current()` method now.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736128219

From dfuchs at openjdk.org  Wed Jan 28 11:55:28 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 11:55:28 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>
Message-ID: <8uKjEQwhe-Q2LvJLPCxxxhzug0NQyr-t6oA5naG0B0g=.be776330-54a6-46d3-bbd1-02db7143dc97@github.com>

On Wed, 28 Jan 2026 11:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not reset stream when read is interrupted
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 327:
> 
>> 325:                     var io = new InterruptedIOException();
>> 326:                     Thread.currentThread().interrupt();
>> 327:                     io.initCause(e);
> 
> Maybe we should set `closed = true` here.

Hmmm.... and if we set closed=true maybe ask the underlying stream to stop sending... and maybe reset the sending part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736285661

From alanb at openjdk.org  Wed Jan 28 12:48:48 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jan 2026 12:48:48 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
Message-ID: <yXB2islIXhb8ql97kCtu_U0W_YUuebVW3zbmHJse-Hw=.faae5d2f-b50d-4e81-a8fd-c064b8c3a640@github.com>

On Tue, 27 Jan 2026 15:55:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update code comment in test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29409#pullrequestreview-3716522015

From djelinski at openjdk.org  Wed Jan 28 13:21:02 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Jan 2026 13:21:02 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <8uKjEQwhe-Q2LvJLPCxxxhzug0NQyr-t6oA5naG0B0g=.be776330-54a6-46d3-bbd1-02db7143dc97@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>
 <8uKjEQwhe-Q2LvJLPCxxxhzug0NQyr-t6oA5naG0B0g=.be776330-54a6-46d3-bbd1-02db7143dc97@github.com>
Message-ID: <FHDofZn7nyvcbp7342SoVpHKrenCJmIoZlEXbrXZ0ms=.f71f3d34-fde3-4010-961a-9fef639683b7@github.com>

On Wed, 28 Jan 2026 11:52:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 327:
>> 
>>> 325:                     var io = new InterruptedIOException();
>>> 326:                     Thread.currentThread().interrupt();
>>> 327:                     io.initCause(e);
>> 
>> Maybe we should set `closed = true` here.
>
> Hmmm.... and if we set closed=true maybe ask the underlying stream to stop sending... and maybe reset the sending part.

I guess we should also throw a `ClosedByInterruptException` then. This way we will mimic the SocketChannel behavior. Note that the InputStream spec does not require closing the stream on interrupt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2736603544

From dfuchs at openjdk.org  Wed Jan 28 15:03:48 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Jan 2026 15:03:48 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <FHDofZn7nyvcbp7342SoVpHKrenCJmIoZlEXbrXZ0ms=.f71f3d34-fde3-4010-961a-9fef639683b7@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>
 <8uKjEQwhe-Q2LvJLPCxxxhzug0NQyr-t6oA5naG0B0g=.be776330-54a6-46d3-bbd1-02db7143dc97@github.com>
 <FHDofZn7nyvcbp7342SoVpHKrenCJmIoZlEXbrXZ0ms=.f71f3d34-fde3-4010-961a-9fef639683b7@github.com>
Message-ID: <57W1qiXAMmhmZU0D2j25t7ltf9GHENMCYHpkl87HARw=.b274c70c-9610-4cd3-bdb1-17d829128744@github.com>

On Wed, 28 Jan 2026 13:18:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hmmm.... and if we set closed=true maybe ask the underlying stream to stop sending... and maybe reset the sending part.
>
> I guess we should also throw a `ClosedByInterruptException` then. This way we will mimic the SocketChannel behavior. Note that the InputStream spec does not require closing the stream on interrupt.

That would require more surgery :-) OK - so if you think we don't need to terminally close the stream I'm not opposed to that. The caller will get the exception and it's likely that it will cause the exchange to be terminated at a higher level anyway. This is our test server - its only purpose is to serve our tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2737048128

From abarashev at openjdk.org  Wed Jan 28 16:53:59 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 16:53:59 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Force cache limit per compression algorithm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/358840fc..b96442a9

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

  Stats: 17 lines in 2 files changed: 10 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From xuelei.f at gmail.com  Wed Jan 28 16:40:31 2026
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 28 Jan 2026 08:40:31 -0800
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
 <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
Message-ID: <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>

On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org>
wrote:

> On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
> wrote:
>
> >> Artur Barashev has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Allocate 24 bits for input size in cache key. Add unit tests.
> >
> > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> >
> >> 980:             boolean enableCertificateCompression) {
> >> 981:         this.enableCertificateCompression =
> enableCertificateCompression;
> >> 982:     }
> >
> > Is there a plan to support brotli compression algorithm in OpenJDK?  It
> is the only supported algorithm in browser Chrome.
> >
> > If there is a need to support more than one compression algorithms in
> the future, it might be better to provide an option to customize the
> algorithms selection, including preferences.  The flexibility could provide
> better interoperability if a vendor does not support compression algorithm
> properly.
>
> Yes, strangely Chrome supports only brotli although I didn't see any
> difference in compression ration between zlib and brotli when manually
> testing certificate compression. We may add support for more algorithms in
> the future, but for now it's zlib only.


Once there is a need to support more algorithms, this API may not be
applicable for some cases especially when there are compatibility impact.
It might be good to consider the API to support multiple algorithms from
day zero.

Just my $0.02.

Thanks,
Xuelei


> Generally speaking, it's the certificate's metadata that is being
> compressed, the keys are high-entropy data difficult to compress. PQC
> certificates don?t compress well, most likely because of lower metadata to
> keys ratio.



>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20260128/7e41c352/attachment-0001.htm>

From xuelei.f at gmail.com  Wed Jan 28 16:53:15 2026
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 28 Jan 2026 08:53:15 -0800
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v9]
In-Reply-To: <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <1n7cM37Rd8vlEbxnZzaQhyxHveEQ5jeqNJKzwqYipTk=.299583c9-8c2c-4119-ad19-f9ec56a7173e@github.com>
 <POSv-RUqpERiVlfaGtotSgK1XeszOIyfD617E6pHWKc=.b8829e93-3346-42e0-87e5-a0b83d9f43a5@github.com>
 <k7wMtNwusu5--8vfdjMTwC0rQIqIoXUtT3UXkg20LwE=.caba1a91-89dc-4839-be22-58e5e18c4c5c@github.com>
 <CAPJ=zzgOGmNafGz_P4syheqAxvbsxfSUstsQmGv85NY-c5pC=w@mail.gmail.com>
Message-ID: <CAPJ=zziYQkqZFBt9mnPfXBWL+GWL2AydLMCiHDntvomSoCmdLw@mail.gmail.com>

>
>> Yes, strangely Chrome supports only brotli although I didn't see any
>> difference in compression ration between zlib and brotli when manually
>> testing certificate compression.
>
>
Did you have a chance to compress certification path with multiple
certificates?  It is said Brotli has better ratio.

It is said decompression is fas for Brotli.  An entry may cache certificate
compression and thus decompression performance could play a role for the
algorithm selection in practice.

Xuelei



>>
>> -------------
>>
>> PR Review Comment:
>> https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20260128/82032b40/attachment.htm>

From abarashev at openjdk.org  Wed Jan 28 17:54:42 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 17:54:42 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <DafAw81Tvi_4p9zpQV1TqT98zQ1rBL6cNLzw7JoT1uk=.a8628088-2256-44d7-98b2-83e16f9c7369@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> > > Yes, strangely Chrome supports only brotli although I didn't see any
> > > difference in compression ration between zlib and brotli when manually
> > > testing certificate compression.
> 
> Did you have a chance to compress certification path with multiple certificates? It is said Brotli has better ratio.
> 
> It is said decompression is fas for Brotli. An entry may cache certificate compression and thus decompression performance could play a role for the algorithm selection in practice.
> 
> Xuelei
> 
> > 
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/82032b40/attachment.htm>

- Yes, I tested 3-certificate "EC" and "ML-DSA" chains in DER format. There is no significant difference with default compression settings between gzip and brotli:
   -  1771  EC_chain.der
   -  1029  EC_chain.der.br
   -  1006  EC_chain.der.gz
   - 16992  ML-DSA_chain.der
   - 16487  ML-DSA_chain.der.br
   - 16555  ML-DSA_chain.der.gz
- Decompression is generally much faster than compression for any algorithm, so while brotli decompression is faster than ZLIB it's not going to be a major performance factor.

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

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812856696

From abarashev at openjdk.org  Wed Jan 28 18:00:57 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 28 Jan 2026 18:00:57 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <sLa5fs-1hgDfzxSjJB3jBCSc-eQ1iAG3sSZh-GZlgTI=.e7e92fc9-0d6a-4cc2-a5d9-6b12307a9447@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org> wrote:
> 
> > On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
> > wrote:
> > > > Artur Barashev has updated the pull request incrementally with one
> > > > additional commit since the last revision:
> > > > Allocate 24 bits for input size in cache key. Add unit tests.
> > > 
> > > 
> > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:
> > > > 980:             boolean enableCertificateCompression) {
> > > > 981:         this.enableCertificateCompression =
> > > > enableCertificateCompression;
> > > > 982:     }
> > > 
> > > 
> > > Is there a plan to support brotli compression algorithm in OpenJDK?  It
> > > is the only supported algorithm in browser Chrome.
> > > If there is a need to support more than one compression algorithms in
> > > the future, it might be better to provide an option to customize the
> > > algorithms selection, including preferences.  The flexibility could provide
> > > better interoperability if a vendor does not support compression algorithm
> > > properly.
> > 
> > 
> > Yes, strangely Chrome supports only brotli although I didn't see any
> > difference in compression ration between zlib and brotli when manually
> > testing certificate compression. We may add support for more algorithms in
> > the future, but for now it's zlib only.
> 
> Once there is a need to support more algorithms, this API may not be applicable for some cases especially when there are compatibility impact. It might be good to consider the API to support multiple algorithms from day zero.
> 
> Just my $0.02.
> 
> Thanks, Xuelei
> 
> > Generally speaking, it's the certificate's metadata that is being
> > compressed, the keys are high-entropy data difficult to compress. PQC
> > certificates don?t compress well, most likely because of lower metadata to
> > keys ratio.
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/7e41c352/attachment.htm>

I know original design had callback functions for custom deflators/inflators, but it was decided to support only internally implemented ZLIB for now. We may add callbacks at the later time if there is a demand for it. Current API only enables/disables the certificate compression overall, there shouldn't be any compatibly issues with future callback function mechanism if we decide to support it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812904883

From vyazici at openjdk.org  Wed Jan 28 20:13:40 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 28 Jan 2026 20:13:40 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received"
In-Reply-To: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
Message-ID: <4OcnfHFkHgj3ff9759ANH5N6z9bQoBq_dNpyrkxbiz8=.c7716bea-4aa1-4f62-aad1-eca95aa69a61@github.com>

On Mon, 26 Jan 2026 13:09:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.

test/jdk/java/net/httpclient/CancelRequestTest.java line 97:

> 95: 
> 96:     private static final Random random = RandomFactory.getRandom();
> 97:     private static final ConcurrentHashMap<String, Semaphore> semaphores

Our `Semaphore` usage has two stages:

1. wait ? used by the server handler to acquire permit to write the response
2. advance ? used by the test method to allow the server handler to advance

Can we simplify the design by replacing the usage of `Semaphore` with `CountDownLatch`? This will also avoid the need for a magical `RELEASE_ALL` constant.

test/jdk/java/net/httpclient/CancelRequestTest.java line 396:

> 394:                 throw new AssertionError("Expected CancellationException not received");
> 395:             } catch (ExecutionException x) {
> 396:                 sem.release(RELEASE_ALL);

Have you considered having a single `sem.release(RELEASE_ALL)` in a `finally` block?

Note that this comment applies to more places in the change set.

test/jdk/java/net/httpclient/CancelRequestTest.java line 497:

> 495:                         out.println(now() + "cancelled " + cf1);
> 496:                     };
> 497:                     if (async) Thread.ofVirtual().start(cancel);

Instead of involving virtual threads ? which, IMHO, enlarges the ground for potential problems ? can't we use `Executors.newThreadPerTaskExecutor` while initializing `executor`?

test/jdk/java/net/httpclient/CancelRequestTest.java line 790:

> 788:                         out.printf(now() + "Server wrote %d bytes%n", req.length);
> 789:                     }
> 790:                     if (sem != null) {

Can `sem` ever be null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2738420131
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2738323038
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2738370457
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2738428108

From mullan at openjdk.org  Wed Jan 28 21:29:08 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 28 Jan 2026 21:29:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
Message-ID: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 966:

> 964: 
> 965:     /**
> 966:      * Sets whether TLS certificate compression should be enabled.

I think we should also specify what this enables, the name of the extension. I would also add an @spec label with RFC 8879. Also consider adding a sentence or two (perhaps as an API note) that this signals to the peer that it supports compression and that both sides need to support the underlying extension and compression format in order for it to be actually used. 

Also, I would probably add an Implementation Note specifying that the SunJSSE provider only supports zlib compression, and that other JSSE providers may not support this method.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:

> 977:      * @since 27
> 978:      */
> 979:     public void setEnableCertificateCompression(

Need to specify the default value in the constructor.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 985:

> 983: 
> 984:     /**
> 985:      * Returns whether TLS certificate compression should be enabled

Missing period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738642563
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738595313
PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2738598539

From abarashev at openjdk.org  Thu Jan 29 02:14:51 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:14:51 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <uApZ_GHW_dTqG_vKDuMNpIB33Y56_Qc0CGjp1ubooGU=.cc477e87-3d98-4424-af0e-afe848680ad9@github.com>

On Wed, 28 Jan 2026 21:02:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 985:
> 
>> 983: 
>> 984:     /**
>> 985:      * Returns whether TLS certificate compression should be enabled
> 
> Missing period.

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739445115

From abarashev at openjdk.org  Thu Jan 29 02:19:38 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:19:38 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>

On Wed, 28 Jan 2026 21:01:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:
> 
>> 977:      * @since 27
>> 978:      */
>> 979:     public void setEnableCertificateCompression(
> 
> Need to specify the default value in the constructor.

The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739453252

From abarashev at openjdk.org  Thu Jan 29 02:52:55 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:52:55 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v11]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <z0wPRFf8DgVZ1IRRhDggSrSckgwWQ0RPbsaMkpS3pwU=.ac82a54d-9a9d-4c9e-af7e-a53c5b11ecdd@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Update javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/b96442a9..2c911b0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28682&range=09-10

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

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

From abarashev at openjdk.org  Thu Jan 29 02:52:58 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 02:52:58 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
Message-ID: <wa9NzhMhD0PylqkiPAc_L9_7s7Qi6QLlwm-Gi-8JCyw=.f7fee6b5-0e52-4bd0-a9b6-6bb997116e71@github.com>

On Wed, 28 Jan 2026 21:16:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force cache limit per compression algorithm
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 966:
> 
>> 964: 
>> 965:     /**
>> 966:      * Sets whether TLS certificate compression should be enabled.
> 
> I think we should also specify what this enables, the name of the extension. I would also add an @spec label with RFC 8879. Also consider adding a sentence or two (perhaps as an API note) that this signals to the peer that it supports compression and that both sides need to support the underlying extension and compression format in order for it to be actually used. 
> 
> Also, I would probably add an Implementation Note specifying that the SunJSSE provider only supports zlib compression, and that other JSSE providers may not support this method.

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2739563146

From jpai at openjdk.org  Thu Jan 29 06:34:01 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 06:34:01 GMT
Subject: RFR: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows [v6]
In-Reply-To: <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
 <lKkUv8uwiU6L7WNA-gw1ypoX3QluTdyKFqBwHgzvqQs=.249d1c62-f468-4677-adc9-95bf9bc672a4@github.com>
Message-ID: <5--xWYYld1y2kY1cZxquk8_i77ZBC_I9xelhdtcsyKM=.e3b2351a-f10f-43c1-a8a7-695b7eb077c8@github.com>

On Tue, 27 Jan 2026 15:55:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update code comment in test

Thank you Alan and Mark for the reviews. tier1, tier2 and tier3 tests completed normally with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/29409#issuecomment-3815752184

From jpai at openjdk.org  Thu Jan 29 06:36:59 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 06:36:59 GMT
Subject: Integrated: 8376290: SocketChannel.finishConnect() contains confusing
 "getsockopt" in exception message for a failed connect() on Windows
In-Reply-To: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
References: <kmfrlLfyed3QcaClFsAXjmVcQImN3Dg7GDRQMik3fLQ=.d6cb43fe-2968-4719-8e4f-2f4e4bea01e4@github.com>
Message-ID: <gFRge28NAgRpTn4M3vV9XTJlp2zewOuJZIE0LxAooN4=.17af47ce-ffb8-4192-8ead-cbd4a49e8a68@github.com>

On Mon, 26 Jan 2026 09:54:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the confusing "getsockopt" text from the exception reported on Windows when `SocketChannel.finishConnect()` raises an exception due to a failed `connect()`? 
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in that issue, this looks like an oversight when changes were done for https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older versions the exception reported on Windows was:
> 
> 
> java.net.ConnectException: Connection refused: no further information
> 
> 
> With the current proposed changes in this PR, the exception will now be `java.net.ConnectException: Connection refused` which matches what we report on *nix platforms.
> 
> A new jtreg test has been added to reproduce the original text and verify the change. tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 19c6fdf1
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19c6fdf11b01308e9f99ce5666bfffcfbc453de3
Stats:     163 lines in 4 files changed: 141 ins; 10 del; 12 mod

8376290: SocketChannel.finishConnect() contains confusing "getsockopt" in exception message for a failed connect() on Windows

Reviewed-by: alanb

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

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

From smonteith at openjdk.org  Thu Jan 29 09:03:47 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Thu, 29 Jan 2026 09:03:47 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Mg3vPu8exFTKO4FiJAudoCLbAU27lxZk_iUWmSrlY9w=.273cdbaf-0c19-4b27-b7df-5c583f732988@github.com>
Message-ID: <5izV9DyV060gChX8G_D1BvaYq6AJ2u9abAH8HmSIMKU=.a903cdd2-ec1c-4d4d-8c87-6dac4a8e32a8@github.com>

On Tue, 27 Jan 2026 16:54:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things

Thanke @JornVernee , appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3816372109

From dfuchs at openjdk.org  Thu Jan 29 10:25:19 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 10:25:19 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received"
In-Reply-To: <4OcnfHFkHgj3ff9759ANH5N6z9bQoBq_dNpyrkxbiz8=.c7716bea-4aa1-4f62-aad1-eca95aa69a61@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <4OcnfHFkHgj3ff9759ANH5N6z9bQoBq_dNpyrkxbiz8=.c7716bea-4aa1-4f62-aad1-eca95aa69a61@github.com>
Message-ID: <RtpXhQSMFKEGYuuGDmctcw15t5cIKJE4D4CWqxGzbfc=.55a73fdb-8b05-4981-807d-124d6a11dcc9@github.com>

On Wed, 28 Jan 2026 20:08:45 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> test/jdk/java/net/httpclient/CancelRequestTest.java line 97:
> 
>> 95: 
>> 96:     private static final Random random = RandomFactory.getRandom();
>> 97:     private static final ConcurrentHashMap<String, Semaphore> semaphores
> 
> Our `Semaphore` usage has two stages:
> 
> 1. wait ? used by the server handler to acquire permit to write the response
> 2. advance ? used by the test method to allow the server handler to advance
> 
> Can we simplify the design by replacing the usage of `Semaphore` with `CountDownLatch`? This will also avoid the need for a magical `RELEASE_ALL` constant.

Good idea. I will have to re-test extensively.

> test/jdk/java/net/httpclient/CancelRequestTest.java line 497:
> 
>> 495:                         out.println(now() + "cancelled " + cf1);
>> 496:                     };
>> 497:                     if (async) Thread.ofVirtual().start(cancel);
> 
> Instead of involving virtual threads ? which, IMHO, enlarges the ground for potential problems ? can't we use `Executors.newThreadPerTaskExecutor` while initializing `executor`?

I'd rather use a virtual thread here. The code executed is fairly simple: interrupt the main thread or cancel a completable future. The alternative is to revert to using the thread pool executor. As I said the change to using virtual thread was somewhat gratuitous (eliminated one possible failure reason while searching for the real root cause).

> test/jdk/java/net/httpclient/CancelRequestTest.java line 790:
> 
>> 788:                         out.printf(now() + "Server wrote %d bytes%n", req.length);
>> 789:                     }
>> 790:                     if (sem != null) {
> 
> Can `sem` ever be null?

Yes. Client and server run at their own pace. It could be that when the server reaches here the request has already been cancelled from the client side and the next test has removed all semaphores from the map before adding its own.
It could also be that the server will never reach here because the stream reset has already been processed and os.write() has thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2740885121
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2740903205
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2740938416

From dfuchs at openjdk.org  Thu Jan 29 11:25:02 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 11:25:02 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
Message-ID: <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>

> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.

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

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29415/files
  - new: https://git.openjdk.org/jdk/pull/29415/files/51dd06eb..4fa0b27a

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

  Stats: 39 lines in 1 file changed: 4 ins; 9 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/29415.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29415/head:pull/29415

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

From vyazici at openjdk.org  Thu Jan 29 11:56:43 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 29 Jan 2026 11:56:43 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
Message-ID: <zww7PU1Yw1BLRwKWf5vWNJ7b0s9xHhkHc2QsnsYQiTs=.8cdf2099-6ceb-4ccb-a082-e9d16d71b9a2@github.com>

On Thu, 29 Jan 2026 11:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29415#pullrequestreview-3722242743

From dfuchs at openjdk.org  Thu Jan 29 12:09:20 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 12:09:20 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2 [v2]
In-Reply-To: <DhCOjvHmAyhpgSXYkYL1_zPZZ5sOPbfZhcMcILF5h9A=.40403ad0-d85e-4e87-afc3-75727cbfccea@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <DhCOjvHmAyhpgSXYkYL1_zPZZ5sOPbfZhcMcILF5h9A=.40403ad0-d85e-4e87-afc3-75727cbfccea@github.com>
Message-ID: <9dGM7ksNY9Z0GmYOvPcUVYt2BVY-VCQZ8jPOKlYsNTU=.53634745-991d-42d1-bf21-973bec518cb3@github.com>

On Tue, 27 Jan 2026 14:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix tests using `AbstractConnectTimeout` by replacing the usage of an external host (i.e., `example.com`), which unexpectedly resolves to a real IP address on certain test hosts, with a custom `ServerSocket` bootstrapped by the test.
>> 
>> The initial PR contains 3 commits:
>> 
>> 1. b06f2606c88 Replace external domain with a custom `ServerSocket` (i.e., _"the fix"_)
>> 2. b9262c7ca01 Remove the need for multiple test files
>> 3. d95a335db93 Migrate tests to JUnit
>> 
>> All commits (i.e., 1, 1+2, and 1+2+3) pass tests.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback

It's a bit unfortunate that we don't have a means to test this reliably on windows. Do we really need to allow for backlog + 512 sockets? Can we go with backlog + 8 instead?

If we're now using the loopback there should no longer be any "No route to host" or "Unresolved address" exceptions, should it?

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

PR Review: https://git.openjdk.org/jdk/pull/29431#pullrequestreview-3722287890

From vyazici at openjdk.org  Thu Jan 29 12:26:31 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 29 Jan 2026 12:26:31 GMT
Subject: RFR: 8375352: java/net/httpclient/ConnectTimeoutWithProxy*.java
 tests fail on EC2 [v2]
In-Reply-To: <9dGM7ksNY9Z0GmYOvPcUVYt2BVY-VCQZ8jPOKlYsNTU=.53634745-991d-42d1-bf21-973bec518cb3@github.com>
References: <5ECL8gNTVKZNvagyEz0BlcMc98MSkURgcLBgY9g_mQ8=.9fafad14-8b91-4355-84d7-76c5ed21d31e@github.com>
 <DhCOjvHmAyhpgSXYkYL1_zPZZ5sOPbfZhcMcILF5h9A=.40403ad0-d85e-4e87-afc3-75727cbfccea@github.com>
 <9dGM7ksNY9Z0GmYOvPcUVYt2BVY-VCQZ8jPOKlYsNTU=.53634745-991d-42d1-bf21-973bec518cb3@github.com>
Message-ID: <at3-_3rColG9K_EHAyNiPMht1rT24BiJXk7bt4KG71o=.747d2f96-c0f2-42a9-ae89-391c92f698aa@github.com>

On Thu, 29 Jan 2026 12:05:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It's a bit unfortunate that we don't have a means to test this reliably on windows. Do we really need to allow for backlog + 512 sockets? Can we go with backlog + 8 instead?

`backlog + 2` already works in all supported platforms. 512 is a hard limit to give up on exhausting the admission queue. In practice, max. 2 extra sockets do the job.

> If we're now using the loopback there should no longer be any "No route to host" or "Unresolved address" exceptions, should it?

I'd guess so ? hard to say for all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/29431#issuecomment-3817318841

From djelinski at openjdk.org  Thu Jan 29 12:40:55 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 29 Jan 2026 12:40:55 GMT
Subject: RFR: 8373604: Operations on peer reset tokens are slow
Message-ID: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>

This PR changes the implementation of remapping stateless reset tokens to avoid using linear-time operations.

No new tests. Existing tier1 and tier2 tests continue to pass.

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

Commit messages:
 - Use constant-time functions with peerIssuedResetTokens
 - Use peerConnectionId function consistently
 - Use local copy of peerConnectionId

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

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

From dfuchs at openjdk.org  Thu Jan 29 12:53:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 12:53:03 GMT
Subject: RFR: 8373604: Operations on peer reset tokens are slow
In-Reply-To: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>
References: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>
Message-ID: <iZQcBD6T9iP0Nffuwyra9Oyjdbvexg1TyMacRRVJa8o=.a7f584f5-c1f4-469a-8b8b-a73613ee290c@github.com>

On Thu, 29 Jan 2026 11:44:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR changes the implementation of remapping stateless reset tokens to avoid using linear-time operations.
> 
> No new tests. Existing tier1 and tier2 tests continue to pass.

The change looks reasonable. Please make sure to give it a good shake in the CI before pushing.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29484#pullrequestreview-3722506309

From mullan at openjdk.org  Thu Jan 29 13:30:41 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 29 Jan 2026 13:30:41 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
 <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
Message-ID: <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>

On Thu, 29 Jan 2026 02:17:02 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 979:
>> 
>>> 977:      * @since 27
>>> 978:      */
>>> 979:     public void setEnableCertificateCompression(
>> 
>> Need to specify the default value in the constructor.
>
> The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`

The defaults are listed in the SSLParameters ctor: https://download.java.net/java/early_access/jdk26/docs/api/java.base/javax/net/ssl/SSLParameters.html#%3Cinit%3E()

So I think the default for this new param should also be listed if the application is creating the `SSLParameters` and not the provider implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2741648461

From abarashev at openjdk.org  Thu Jan 29 13:57:57 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 13:57:57 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v12]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <B9Yj-v4kk_FfOCre_YSwTet5ErQUB3oqfdeDaADpgkc=.266a53af-663c-445b-8a9c-c45c1dddb822@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Use newSoftMemoryCache for LRU mechanism and EqualByteArray to avoid any chance of collision

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/2c911b0a..82d5d62f

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

  Stats: 516 lines in 6 files changed: 213 ins; 291 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28682/head:pull/28682

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

From abarashev at openjdk.org  Thu Jan 29 14:38:19 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 14:38:19 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v10]
In-Reply-To: <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <frBnFAB-GtlxekHfRT6p4SOt9r3lO1Zz56CVGt1I0o4=.9303782e-518c-4619-bbd8-221062abe5c4@github.com>
 <8HTjzIgiPnUgH2CVnCprS2MLd8ocEz8Tzx0rChJGWKk=.34c5f8d1-e923-409b-9d8f-c3398d27f877@github.com>
 <_rzv0U2YCmViu8Rg4SaZfqhr5THzV65DHD2w5oBbOag=.3094eaab-8967-4efa-8284-4dac174798b0@github.com>
 <VUxcre337JywdXRtDUAhfiy4hd0A7e2o6Ygc5jH1XvY=.6661a731-1da2-4c49-987a-c84faff98bbf@github.com>
Message-ID: <8toAKagwhzr9_aOXQ5U3Y8hPQLZ3nqW7pkQs9fK_mjI=.12315e81-d7a4-4953-b983-95c4670bdcfe@github.com>

On Thu, 29 Jan 2026 13:28:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The convention in `SSLParameters` is not to specify the default values: the rest of set methods in this file don't mention it. In our particular case the default value is the value of `jdk.tls.enableCertificateCompression` system property, and if such value is not set then it's `true`
>
> The defaults are listed in the SSLParameters ctor: https://download.java.net/java/early_access/jdk26/docs/api/java.base/javax/net/ssl/SSLParameters.html#%3Cinit%3E()
> 
> So I think the default for this new param should also be listed if the application is creating the `SSLParameters` and not the provider implementation.

Oh, indeed! Good catch, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2741973089

From abarashev at openjdk.org  Thu Jan 29 14:46:05 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 14:46:05 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Update javadoc: specify default value for enableCertificateCompression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/82d5d62f..8b0261c1

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

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

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

From djelinski at openjdk.org  Thu Jan 29 14:53:18 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 29 Jan 2026 14:53:18 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Send stop_sending if the InputStream is closed
 - Close the stream atomically

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29448/files
  - new: https://git.openjdk.org/jdk/pull/29448/files/a8a5415c..52230a48

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

  Stats: 33 lines in 1 file changed: 13 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29448/head:pull/29448

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

From djelinski at openjdk.org  Thu Jan 29 14:56:33 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 29 Jan 2026 14:56:33 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v2]
In-Reply-To: <57W1qiXAMmhmZU0D2j25t7ltf9GHENMCYHpkl87HARw=.b274c70c-9610-4cd3-bdb1-17d829128744@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <8uIhJSwI-Ztv8oQJcStpYWc794AA02VBLRbi-Hin7U0=.bbf99ec8-1c70-42ab-8cd2-1b8abc54f619@github.com>
 <4ApC-I2outys1Uop9weWDAWfy5scCnGn3h6aEW1_F_Q=.15660028-8b29-4128-a30f-ee48236552c2@github.com>
 <8uKjEQwhe-Q2LvJLPCxxxhzug0NQyr-t6oA5naG0B0g=.be776330-54a6-46d3-bbd1-02db7143dc97@github.com>
 <FHDofZn7nyvcbp7342SoVpHKrenCJmIoZlEXbrXZ0ms=.f71f3d34-fde3-4010-961a-9fef639683b7@github.com>
 <57W1qiXAMmhmZU0D2j25t7ltf9GHENMCYHpkl87HARw=.b274c70c-9610-4cd3-bdb1-17d829128744@github.com>
Message-ID: <yiW7L0_aNvjVtZ_OBJDnrZgNR9Z5ZRZ_j6AHgrbxF4M=.6f64b4c3-4376-46ff-a537-26fe2e32437b@github.com>

On Wed, 28 Jan 2026 15:00:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I guess we should also throw a `ClosedByInterruptException` then. This way we will mimic the SocketChannel behavior. Note that the InputStream spec does not require closing the stream on interrupt.
>
> That would require more surgery :-) OK - so if you think we don't need to terminally close the stream I'm not opposed to that. The caller will get the exception and it's likely that it will cause the exchange to be terminated at a higher level anyway. This is our test server - its only purpose is to serve our tests.

Now we send stop_sending too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742057029

From djelinski at openjdk.org  Thu Jan 29 14:56:37 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 29 Jan 2026 14:56:37 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <EQPyNdxve_DckMT_pK2HK_jT6wnqkDm9H5JqBXQ6j5E=.b77a8880-539f-466e-b732-73c6fe333635@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <gBqtzVl0_RkLp7WIzp-s4GM4lPSVWaaW2eP0aFHpFEw=.ec8a43e8-20ca-4e34-bd46-11e63c60bad7@github.com>
 <uXvpV4b2PYyIUOWEqdRSYWhzcfTDydGRkYKoBs_Kh9E=.23afb179-5ead-4cbe-8376-bd437a6a108c@github.com>
 <HskQ-c3eJ1u2QFFrmMGhisRqqVfaNxl_0PuG3STL4CM=.7543f8d0-d3ad-406f-86f8-3a46968e2cc7@github.com>
 <EQPyNdxve_DckMT_pK2HK_jT6wnqkDm9H5JqBXQ6j5E=.b77a8880-539f-466e-b732-73c6fe333635@github.com>
Message-ID: <jBe6zuPZY3ObqROJtxcETEPOpjtVWyKMwumsvN80ouE=.3c81b9f0-c9e9-4696-9f5d-8a97db6ca0c6@github.com>

On Wed, 28 Jan 2026 11:05:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Changed; the InterruptedIOException does not set `error` anymore, so if the caller of `read()` chooses to clear the interrupted status, it's possible to keep reading from the stream after the exception.
>
> Maybe we should set `close = true` when we catch InterruptedException.

Changed; now resetting the stream and closing it are practically equivalent, They only differ in the exception thrown from `read`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742062638

From jpai at openjdk.org  Thu Jan 29 14:59:49 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 14:59:49 GMT
Subject: RFR: 8227493: Return a more useful error message from
 lookupAllHostAddr if getaddrinfo results in EAI_SYSTEM error [v3]
In-Reply-To: <9rj3kbSMf6arPXL3pgov5XqdvOaQpB19TCo3V-rl89U=.dd267c34-f958-4f75-a794-4e5398cef32c@github.com>
References: <9rj3kbSMf6arPXL3pgov5XqdvOaQpB19TCo3V-rl89U=.dd267c34-f958-4f75-a794-4e5398cef32c@github.com>
Message-ID: <CHjoMgtTZT-4ifjJpgn1L-WP719xDNa-7Mex729OKfM=.9f2218dd-624e-463e-990a-1df18a03efa4@github.com>

> Can I please get a review of this minor enhancement to the error text that is reported if the `getaddrinfo()` native call returns the `EAI_SYSTEM` error? This addresses https://bugs.openjdk.org/browse/JDK-8227493.
> 
> The `java.net.InetAddress` class, in its implementation for resolving addresses for a host name, calls the `getaddrinfo()` native call on *nix platforms. If `getaddrinfo()` returns an error then we use the `gai_strerror()` native call to convert the error number into an error string that is then propagated to the application. Among other errors, the `getaddrinfo()` is specified to return the error code `EAI_SYSTEM` which as per its documentation represents
> 
>> EAI_SYSTEM        system error returned in errno
> 
> So calling `gai_strerror()` merely returns a generic "System error" text. The real underlying error is present in the `errno` and that has more useful information. 
> 
> The commit in this PR checks the error for `EAI_SYSTEM` and if it matches then it additionally gets the error text corresponding to `errno`. So the error text that gets propagated will now be "System error: Illegal byte sequence", assuming `EILSEQ` was the underlying `errno` for the `getaddrinfo` call (my use of `EILSEQ` in this example is arbitrary and it's merely to show what the error text will look like after this change).
> 
> Given the nature of this change no new test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - merge latest from master branch
 - fix size computation
 - 8227493: lookupAllHostAddr does not handle EAI_SYSTEM correctly

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

Changes: https://git.openjdk.org/jdk/pull/22484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22484&range=02
  Stats: 42 lines in 4 files changed: 30 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22484/head:pull/22484

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

From dfuchs at openjdk.org  Thu Jan 29 15:02:42 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 15:02:42 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
 <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
Message-ID: <nU1R_EABc6kuyC2-NkRCRlA3ksXI9WWGelXEyx6inXg=.498ab0dc-eec8-47ca-b380-ba05a5998dd3@github.com>

On Wed, 21 Jan 2026 12:21:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by requiring exact *path prefix matches*.
>> 
>> 
>>          |           Request path
>>  Context +------+-------+----------+---------
>>   path   | /foo | /foo/ | /foo/bar | /foobar
>> ---------+------+-------+----------+---------
>>  /       |   Y  |   Y   |     Y    |    Y
>>  /foo/   |   N  |   Y   |     Y    |    N
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add property to switch between prefix matching schemes

src/jdk.httpserver/share/classes/module-info.java line 110:

> 108:  *
> 109:  * The path matching scheme used to route requests to context handlers.
> 110:  * Following list of values are allowed by this property.</p>

Suggestion:

 * The property can be configured with one of the following values:</p>

src/jdk.httpserver/share/classes/module-info.java line 120:

> 118:  * but not {@code /foobar}.</dd>
> 119:  * <dt>{@code stringPrefix}</dt>
> 120:  * <dd>Request path string must begin with the context path string. For

Suggestion:

 * <dd>The request path string must begin with the context path string. For

test/jdk/com/sun/net/httpserver/ContextPathMatcherPathPrefixTest.java line 52:

> 50: 
> 51: /*
> 52:  * @test id=withProperty

Suggestion:

 * @test id=withPathPrefix

test/jdk/com/sun/net/httpserver/ContextPathMatcherPathPrefixTest.java line 72:

> 70:  *      ${test.main.class}
> 71:  */
> 72: 

Could we simply have another test comment to test with `-Dsun.net.httpserver.pathMatcher=stringPrefix` instead of having a separate test class?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742049052
PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742053310
PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742059613
PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742064650

From jpai at openjdk.org  Thu Jan 29 15:03:38 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 29 Jan 2026 15:03:38 GMT
Subject: RFR: 8227493: Return a more useful error message from
 lookupAllHostAddr if getaddrinfo results in EAI_SYSTEM error [v3]
In-Reply-To: <CHjoMgtTZT-4ifjJpgn1L-WP719xDNa-7Mex729OKfM=.9f2218dd-624e-463e-990a-1df18a03efa4@github.com>
References: <9rj3kbSMf6arPXL3pgov5XqdvOaQpB19TCo3V-rl89U=.dd267c34-f958-4f75-a794-4e5398cef32c@github.com>
 <CHjoMgtTZT-4ifjJpgn1L-WP719xDNa-7Mex729OKfM=.9f2218dd-624e-463e-990a-1df18a03efa4@github.com>
Message-ID: <T4ntcQl1WioPli5GXhsk_HZhJQY-ZagIm6yte5qr-ls=.8b1d0196-1618-46f9-ad55-12290103511e@github.com>

On Thu, 29 Jan 2026 14:59:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this minor enhancement to the error text that is reported if the `getaddrinfo()` native call returns the `EAI_SYSTEM` error? This addresses https://bugs.openjdk.org/browse/JDK-8227493.
>> 
>> The `java.net.InetAddress` class, in its implementation for resolving addresses for a host name, calls the `getaddrinfo()` native call on *nix platforms. If `getaddrinfo()` returns an error then we use the `gai_strerror()` native call to convert the error number into an error string that is then propagated to the application. Among other errors, the `getaddrinfo()` is specified to return the error code `EAI_SYSTEM` which as per its documentation represents
>> 
>>> EAI_SYSTEM        system error returned in errno
>> 
>> So calling `gai_strerror()` merely returns a generic "System error" text. The real underlying error is present in the `errno` and that has more useful information. 
>> 
>> The commit in this PR checks the error for `EAI_SYSTEM` and if it matches then it additionally gets the error text corresponding to `errno`. So the error text that gets propagated will now be "System error: Illegal byte sequence", assuming `EILSEQ` was the underlying `errno` for the `getaddrinfo` call (my use of `EILSEQ` in this example is arbitrary and it's merely to show what the error text will look like after this change).
>> 
>> Given the nature of this change no new test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - merge latest from master branch
>  - fix size computation
>  - 8227493: lookupAllHostAddr does not handle EAI_SYSTEM correctly

I wasn't able to take this PR to completion, the last time I opened it. I have now refreshed it with the latest set of changes. Can I please get a review afresh please? tier testing is currently in progress with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/22484#issuecomment-3818250450

From dfuchs at openjdk.org  Thu Jan 29 15:17:09 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 15:17:09 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
Message-ID: <VVHIUvKKQBHBSfJrx878FG8GkF49BbQhNBzplO0O3Ug=.4fd0eb73-e45d-4a99-9242-3e27039dc5cf@github.com>

On Thu, 29 Jan 2026 14:53:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Send stop_sending if the InputStream is closed
>  - Close the stream atomically

I am not opposed to the proposed changes. I agree they will fix the issue. However please give them a good shake in the CI before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29448#pullrequestreview-3723345985

From michaelm at openjdk.org  Thu Jan 29 15:22:19 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 Jan 2026 15:22:19 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
 <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
Message-ID: <IuOeoS0CD49bK8qbWznvB9bivyGCSeVC9S2uhkcUDT0=.a5da68ca-289a-434b-9f71-a1910013d0c8@github.com>

On Wed, 21 Jan 2026 12:21:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by requiring exact *path prefix matches*.
>> 
>> 
>>          |           Request path
>>  Context +------+-------+----------+---------
>>   path   | /foo | /foo/ | /foo/bar | /foobar
>> ---------+------+-------+----------+---------
>>  /       |   Y  |   Y   |     Y    |    Y
>>  /foo/   |   N  |   Y   |     Y    |    N
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add property to switch between prefix matching schemes

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpServer.java line 287:

> 285:      * this context path matches request paths {@code /foo},
> 286:      * {@code /foo/bar}, or {@code /foobar}. Others may use <em>path prefix
> 287:      * matching</em> where {@code /foo} matches only request paths

Suggestion:

     * matching</em> where {@code /foo} matches request paths

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742167398

From michaelm at openjdk.org  Thu Jan 29 15:38:44 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 Jan 2026 15:38:44 GMT
Subject: RFR: 8272758: Improve HttpServer to avoid partial file name
 matches while mapping request path to context path [v2]
In-Reply-To: <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
References: <H4g1IbcPLM949qLk_2dfyWQ9m2LxaL9MaOS23c6284k=.8eb2adbf-6c23-47ad-9880-a1dc0f0db3c7@github.com>
 <p0inW9WUao01_9-VfRZrq6FWly7oMIHc0b71WcDKRLY=.472740cb-1f9d-431c-bcb7-18e9e5254712@github.com>
Message-ID: <mr9lWhfPStafSawf1Fz-SvqZzhEawhX5td0NVk6g_T8=.fb6e718e-cf94-4a37-bfc1-133c9fdb160f@github.com>

On Wed, 21 Jan 2026 12:21:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. Replace this surprising behaviour with a safer approach by requiring exact *path prefix matches*.
>> 
>> 
>>          |           Request path
>>  Context +------+-------+----------+---------
>>   path   | /foo | /foo/ | /foo/bar | /foobar
>> ---------+------+-------+----------+---------
>>  /       |   Y  |   Y   |     Y    |    Y
>>  /foo/   |   N  |   Y   |     Y    |    N
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add property to switch between prefix matching schemes

src/jdk.httpserver/share/classes/sun/net/httpserver/ContextList.java line 201:

> 199:                 }
> 200: 
> 201:                 // Is it a path-prefix match?

Suggestion:

                // Is it a path-prefix match? Either the context ends with '/'
                // or the request contains a '/' implying that it does

or words to the same effect. The behavior is quite subtle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29264#discussion_r2742260337

From dfuchs at openjdk.org  Thu Jan 29 15:40:25 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 15:40:25 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
Message-ID: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>

The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.

In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

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

Commit messages:
 - 8376031: HttpsURLConnection.getServerCertificates() throws "java.lang.IllegalStateException: connection not yet open" for the HEAD method

Changes: https://git.openjdk.org/jdk/pull/29489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376031
  Stats: 481 lines in 4 files changed: 388 ins; 79 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/29489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29489/head:pull/29489

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

From dfuchs at openjdk.org  Thu Jan 29 16:29:51 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 16:29:51 GMT
Subject: RFR: 8227493: Return a more useful error message from
 lookupAllHostAddr if getaddrinfo results in EAI_SYSTEM error [v3]
In-Reply-To: <CHjoMgtTZT-4ifjJpgn1L-WP719xDNa-7Mex729OKfM=.9f2218dd-624e-463e-990a-1df18a03efa4@github.com>
References: <9rj3kbSMf6arPXL3pgov5XqdvOaQpB19TCo3V-rl89U=.dd267c34-f958-4f75-a794-4e5398cef32c@github.com>
 <CHjoMgtTZT-4ifjJpgn1L-WP719xDNa-7Mex729OKfM=.9f2218dd-624e-463e-990a-1df18a03efa4@github.com>
Message-ID: <SNBx3yBaQZYpmUW7UBM9w4gi0NXa-8_A_l1HWEzC8HQ=.b09a745c-a5f9-477e-bf5f-f2cb52cccc8f@github.com>

On Thu, 29 Jan 2026 14:59:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this minor enhancement to the error text that is reported if the `getaddrinfo()` native call returns the `EAI_SYSTEM` error? This addresses https://bugs.openjdk.org/browse/JDK-8227493.
>> 
>> The `java.net.InetAddress` class, in its implementation for resolving addresses for a host name, calls the `getaddrinfo()` native call on *nix platforms. If `getaddrinfo()` returns an error then we use the `gai_strerror()` native call to convert the error number into an error string that is then propagated to the application. Among other errors, the `getaddrinfo()` is specified to return the error code `EAI_SYSTEM` which as per its documentation represents
>> 
>>> EAI_SYSTEM        system error returned in errno
>> 
>> So calling `gai_strerror()` merely returns a generic "System error" text. The real underlying error is present in the `errno` and that has more useful information. 
>> 
>> The commit in this PR checks the error for `EAI_SYSTEM` and if it matches then it additionally gets the error text corresponding to `errno`. So the error text that gets propagated will now be "System error: Illegal byte sequence", assuming `EILSEQ` was the underlying `errno` for the `getaddrinfo` call (my use of `EILSEQ` in this example is arbitrary and it's merely to show what the error text will look like after this change).
>> 
>> Given the nature of this change no new test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - merge latest from master branch
>  - fix size computation
>  - 8227493: lookupAllHostAddr does not handle EAI_SYSTEM correctly

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22484#pullrequestreview-3723767768

From xuelei at openjdk.org  Thu Jan 29 17:17:42 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 29 Jan 2026 17:17:42 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
Message-ID: <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>

On Thu, 29 Jan 2026 14:46:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadoc: specify default value for enableCertificateCompression

src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:

> 146:         // the deflated certificate data in a memory cache statically and avoid
> 147:         // compressing local certificates repeatedly for every handshake.
> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =

I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2742697277

From vyazici at openjdk.org  Thu Jan 29 18:16:47 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 29 Jan 2026 18:16:47 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
Message-ID: <q1uXT11W6axGVUXwNnetLj7wAzn1Bjjc7Z_6ycpnBVM=.17ab6416-f9ce-409b-947c-04664b6ce6bc@github.com>

On Thu, 29 Jan 2026 14:53:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Send stop_sending if the InputStream is closed
>  - Close the stream atomically

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 336:

> 334:                     Thread.currentThread().interrupt();
> 335:                     io.initCause(e);
> 336:                     throw io;

Can we simplify this loop as follows?

Suggestion:

            while (true) {
                Object reason = closeReason.get();
                if (reason == Boolean.TRUE) {
                    throw new IOException("Stream is closed");
                } else if (reason instanceof IOException ioe) {
                    throw new IOException(ioe);
                }
                if (current != null && (current.hasRemaining() || current == QuicStreamReader.EOF)) {
                    return current;
                }
                try {
                    if (debug.on())
                        debug.log("Taking buffer from queue");
                    // Blocking call
                    current = requestBodyQueue.take();
                } catch (InterruptedException e) {
                    var io = new InterruptedIOException();
                    Thread.currentThread().interrupt();
                    io.initCause(e);
                    throw io;

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 368:

> 366:         @Override
> 367:         public void close() throws IOException {
> 368:             if (closeReason.getAndSet(Boolean.TRUE) == Boolean.TRUE) return;

Shouldn't this be `!compareAndSet(null, TRUE)`? Otherwise we allow changing the state from `FAILED` to `CLOSED`, which, AFAICT, is not intended.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 371:

> 369:             if (debug.on())
> 370:                 debug.log("Closing request body input stream");
> 371:             requestBodyQueue.add(QuicStreamReader.EOF);

Do we need `requestBodyQueue.add(QuicStreamReader.EOF)` here and in `resetStream`, given `read()` will propagate the non-null `closeReason` thrown by `current()` anyway, and `current()` is the only reader of `requestBodyQueue`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742919788
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742812024
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742823607

From abarashev at openjdk.org  Thu Jan 29 18:17:49 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 29 Jan 2026 18:17:49 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
Message-ID: <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>

On Thu, 29 Jan 2026 17:15:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update javadoc: specify default value for enableCertificateCompression
>
> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:
> 
>> 146:         // the deflated certificate data in a memory cache statically and avoid
>> 147:         // compressing local certificates repeatedly for every handshake.
>> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =
> 
> I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance, without using static field?

Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2742923390

From dfuchs at openjdk.org  Thu Jan 29 18:22:58 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jan 2026 18:22:58 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <q1uXT11W6axGVUXwNnetLj7wAzn1Bjjc7Z_6ycpnBVM=.17ab6416-f9ce-409b-947c-04664b6ce6bc@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
 <q1uXT11W6axGVUXwNnetLj7wAzn1Bjjc7Z_6ycpnBVM=.17ab6416-f9ce-409b-947c-04664b6ce6bc@github.com>
Message-ID: <_sZVrLj0FYyE2Y2E-0l09xMtw07zfiAqhXVBr4vY7zg=.4429c5b8-2a32-48cd-b8a7-605b2235a3b3@github.com>

On Thu, 29 Jan 2026 17:46:49 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Send stop_sending if the InputStream is closed
>>  - Close the stream atomically
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 368:
> 
>> 366:         @Override
>> 367:         public void close() throws IOException {
>> 368:             if (closeReason.getAndSet(Boolean.TRUE) == Boolean.TRUE) return;
> 
> Shouldn't this be `!compareAndSet(null, TRUE)`? Otherwise we allow changing the state from `FAILED` to `CLOSED`, which, AFAICT, is not intended.

If it fails, and then you call close(), then it should be closed, regardless on whether it failed before?

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 371:
> 
>> 369:             if (debug.on())
>> 370:                 debug.log("Closing request body input stream");
>> 371:             requestBodyQueue.add(QuicStreamReader.EOF);
> 
> Do we need `requestBodyQueue.add(QuicStreamReader.EOF)` here and in `resetStream`, given `read()` will propagate the non-null `closeReason` thrown by `current()` anyway, and `current()` is the only reader of `requestBodyQueue`?

Yes. The read() call might be blocked taking from the queue (when the queue is empty) at the time of reset/close - which can happen asynchronously. This is the only way to wakeup the reader so that read() gets unblocked and throws.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742933385
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2742940995

From abarashev at openjdk.org  Fri Jan 30 01:59:10 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 01:59:10 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v14]
In-Reply-To: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
Message-ID: <7CXUTIVrF6uQSUav5jVkDnLQe5ZpzMSW1wJzAaVp5i4=.352169f7-883d-486a-9f13-a6b50fb5f898@github.com>

> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
> https://datatracker.ietf.org/doc/html/rfc8879

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

  Increase cache size to be on the safe side

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28682/files
  - new: https://git.openjdk.org/jdk/pull/28682/files/8b0261c1..6b23c05f

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

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

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

From djelinski at openjdk.org  Fri Jan 30 09:03:56 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 09:03:56 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v4]
In-Reply-To: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
Message-ID: <XeAqtaQQHlUM-Pfh7qZCuIAppNIAmcoR-RYTxRenGBI=.618cadb1-602a-4efe-9395-7f5eb5ad53f5@github.com>

> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
> 
> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  remove duplicate code in current()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29448/files
  - new: https://git.openjdk.org/jdk/pull/29448/files/52230a48..4ffa3e48

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

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

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

From djelinski at openjdk.org  Fri Jan 30 09:09:01 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 09:09:01 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v3]
In-Reply-To: <_sZVrLj0FYyE2Y2E-0l09xMtw07zfiAqhXVBr4vY7zg=.4429c5b8-2a32-48cd-b8a7-605b2235a3b3@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <1xrn7Q5ErMxktO1KB75pRB0rUNHMMhiW7JHR0-tu5Mc=.03b539c7-1bb1-48ae-a13e-0db9b19dfcd2@github.com>
 <q1uXT11W6axGVUXwNnetLj7wAzn1Bjjc7Z_6ycpnBVM=.17ab6416-f9ce-409b-947c-04664b6ce6bc@github.com>
 <_sZVrLj0FYyE2Y2E-0l09xMtw07zfiAqhXVBr4vY7zg=.4429c5b8-2a32-48cd-b8a7-605b2235a3b3@github.com>
Message-ID: <B7RB2Oa4RBZGLSGVz16Yzz8g-r8_KqVPmj4vDUQuQsM=.d05e3dba-f812-4629-8b84-c9b2874d3f7e@github.com>

On Thu, 29 Jan 2026 18:17:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 368:
>> 
>>> 366:         @Override
>>> 367:         public void close() throws IOException {
>>> 368:             if (closeReason.getAndSet(Boolean.TRUE) == Boolean.TRUE) return;
>> 
>> Shouldn't this be `!compareAndSet(null, TRUE)`? Otherwise we allow changing the state from `FAILED` to `CLOSED`, which, AFAICT, is not intended.
>
> If it fails, and then you call close(), then it should be closed, regardless on whether it failed before?

Right. Also, read after close may be a user error, so I think we want to report that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2745303774

From dfuchs at openjdk.org  Fri Jan 30 09:52:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 09:52:03 GMT
Subject: RFR: 8376479: Http3 test server thread deadlock in
 ThrowingPublishersInRequest [v4]
In-Reply-To: <XeAqtaQQHlUM-Pfh7qZCuIAppNIAmcoR-RYTxRenGBI=.618cadb1-602a-4efe-9395-7f5eb5ad53f5@github.com>
References: <bmBKURoEWjfB8NKuJc_LDFGvt2a4fyMUr0suKQVNg2A=.d1e90b31-e637-4437-9014-4ce25fea6ce8@github.com>
 <XeAqtaQQHlUM-Pfh7qZCuIAppNIAmcoR-RYTxRenGBI=.618cadb1-602a-4efe-9395-7f5eb5ad53f5@github.com>
Message-ID: <6w_a5eLlEzRPAWeYmcNUE3_ZP8czGNlWXLip2jk4sN4=.ab017e13-fce5-4f11-90a8-2913e89f06cb@github.com>

On Fri, 30 Jan 2026 09:03:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This fixes a deadlock between the thread that reads from the RequestBodyInputStream and the thread that tries to close it in response to a stream reset. See the linked JBS ticket for details.
>> 
>> Tier1 and tier2 tests continue to pass. I verified that with this change there are no busy threads at the end of the test.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate code in current()

Good simplification.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http3/Http3ServerStreamImpl.java line 310:

> 308:                         throw new IOException("Stream is closed");
> 309:                     } else {
> 310:                         throw new IOException((IOException)reason);

I would only do this if current == EOF - but it's probably OK to throw immediately. If the stream is being reset before we have read all the bytes, it's probably OK to throw immediately. We know that we have all the bytes when the stream is in DATA_RECVD. We may receive a RESET when in this state, and in this case IIRC the spec allows to switch to RESET_READ and drop the data. If the RESET comes before DATA_RECVD and we have data in the queue we can throw immediately as there is no point in processing the received data anyway. So in all cases throwing immediately is reasonable.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29448#pullrequestreview-3727327202
PR Review Comment: https://git.openjdk.org/jdk/pull/29448#discussion_r2745461815

From djelinski at openjdk.org  Fri Jan 30 11:02:56 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 11:02:56 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
Message-ID: <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>

On Thu, 29 Jan 2026 11:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

test/jdk/java/net/httpclient/CancelRequestTest.java line 342:

> 340:     private static CountDownLatch addLatchFor(HttpRequest req) {
> 341:         // release left over latches
> 342:         releaseLatches();

`releaseLatches()` calls `latches.clear()`. We will effectively only have one latch in the map at a time. Is that what you intended?

test/jdk/java/net/httpclient/CancelRequestTest.java line 789:

> 787:                                 requestLatch, t.getRequestURI());
> 788:                         try {
> 789:                             requestLatch.await();

Can we remove the Thread.sleep above now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745712780
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745718556

From dfuchs at openjdk.org  Fri Jan 30 11:07:20 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 11:07:20 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
 <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>
Message-ID: <Gx2VwiEqq-kFsedE2P6Z5H5SyNxR8_6WKZEm4-s1oMA=.3531442a-d3d2-4393-aaef-23ce81f2fcc1@github.com>

On Fri, 30 Jan 2026 10:56:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> test/jdk/java/net/httpclient/CancelRequestTest.java line 342:
> 
>> 340:     private static CountDownLatch addLatchFor(HttpRequest req) {
>> 341:         // release left over latches
>> 342:         releaseLatches();
> 
> `releaseLatches()` calls `latches.clear()`. We will effectively only have one latch in the map at a time. Is that what you intended?

Yes - we don't know what the key is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745735136

From dfuchs at openjdk.org  Fri Jan 30 11:15:05 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 11:15:05 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
 <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>
Message-ID: <Nn8hepUgq9Etklfop6r_IBsOxLhj4ssOAc1nscdF92Y=.85d90e0f-6981-4f65-a898-97fcd8ed7c4c@github.com>

On Fri, 30 Jan 2026 10:58:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> test/jdk/java/net/httpclient/CancelRequestTest.java line 789:
> 
>> 787:                                 requestLatch, t.getRequestURI());
>> 788:                         try {
>> 789:                             requestLatch.await();
> 
> Can we remove the Thread.sleep above now?

I'd rather not. The thread.sleep() is here to introduce some more entropy on where the client might be when the cancellation becomes effective. There's more chance that it won't have received all the data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745758838

From dfuchs at openjdk.org  Fri Jan 30 11:20:26 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 11:20:26 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <Gx2VwiEqq-kFsedE2P6Z5H5SyNxR8_6WKZEm4-s1oMA=.3531442a-d3d2-4393-aaef-23ce81f2fcc1@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
 <zOLxTLrNqhnxuNgyeRVkvSwSqoPAS1xPOLwdM3PrAj8=.0d08be68-9861-432b-adf2-182a79672c93@github.com>
 <Gx2VwiEqq-kFsedE2P6Z5H5SyNxR8_6WKZEm4-s1oMA=.3531442a-d3d2-4393-aaef-23ce81f2fcc1@github.com>
Message-ID: <w_9UK4_0QofCk1UKp5eV1K38Md2SIa9yVlekZ2mDuKQ=.9f978606-7d54-454e-b9c1-93be26a5ca15@github.com>

On Fri, 30 Jan 2026 11:04:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/CancelRequestTest.java line 342:
>> 
>>> 340:     private static CountDownLatch addLatchFor(HttpRequest req) {
>>> 341:         // release left over latches
>>> 342:         releaseLatches();
>> 
>> `releaseLatches()` calls `latches.clear()`. We will effectively only have one latch in the map at a time. Is that what you intended?
>
> Yes - we don't care what the key is.

All we care is that the server side, when it runs, picks up the right latch, and not the one left over from the previous test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745779607

From djelinski at openjdk.org  Fri Jan 30 11:42:18 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 11:42:18 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
Message-ID: <FscXmrgIzCzWJYdrMijLEkAA_tgkaPBLoLqnyheO2ZA=.88576dba-5179-4085-bcc9-4e5ec912c1b3@github.com>

On Thu, 29 Jan 2026 11:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

test/jdk/java/net/httpclient/CancelRequestTest.java line 785:

> 783:                         out.printf(now() + "Server wrote %d bytes%n", req.length);
> 784:                     }
> 785:                     if (requestLatch != null) {

This check might hide test bugs. Please remove.

test/jdk/java/net/httpclient/CancelRequestTest.java line 797:

> 795:                 }
> 796:             } catch (Throwable e) {
> 797:                 out.println(now() + "HTTPSlowHandler: unexpected exception: " + e);

Preexisting, but we get an IOException here frequently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745818707
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745847493

From dfuchs at openjdk.org  Fri Jan 30 12:03:20 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 12:03:20 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <FscXmrgIzCzWJYdrMijLEkAA_tgkaPBLoLqnyheO2ZA=.88576dba-5179-4085-bcc9-4e5ec912c1b3@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
 <FscXmrgIzCzWJYdrMijLEkAA_tgkaPBLoLqnyheO2ZA=.88576dba-5179-4085-bcc9-4e5ec912c1b3@github.com>
Message-ID: <MiBHckIw_EPLCOJycJEIN6vrSQptNQ8W2pHtkgBtjjU=.80c15a50-e18d-46b6-8684-794efd86dacd@github.com>

On Fri, 30 Jan 2026 11:30:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> test/jdk/java/net/httpclient/CancelRequestTest.java line 785:
> 
>> 783:                         out.printf(now() + "Server wrote %d bytes%n", req.length);
>> 784:                     }
>> 785:                     if (requestLatch != null) {
> 
> This check might hide test bugs. Please remove.

It does not. It is not a test bug to have `null` here. The request can be cancelled on the client side and the client might be sending the next request by the time the server reaches here. We don't want the server to wait if the client request has already been cancelled. It is not even guaranteed that the handler will be invoked. The request might have been cancelled before that.

> test/jdk/java/net/httpclient/CancelRequestTest.java line 797:
> 
>> 795:                 }
>> 796:             } catch (Throwable e) {
>> 797:                 out.println(now() + "HTTPSlowHandler: unexpected exception: " + e);
> 
> Preexisting, but we get an IOException here frequently.

True.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745925292
PR Review Comment: https://git.openjdk.org/jdk/pull/29415#discussion_r2745929544

From djelinski at openjdk.org  Fri Jan 30 12:48:21 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 12:48:21 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
Message-ID: <0moSIEr5zpoHmXkPDvXqMyhtHgBLW6hSIeldKJv5TK0=.fe04efe0-71e0-4547-a50a-03682d88f157@github.com>

On Thu, 29 Jan 2026 11:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29415#pullrequestreview-3728105619

From djelinski at openjdk.org  Fri Jan 30 13:47:56 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 13:47:56 GMT
Subject: RFR: 8373604: Operations on peer reset tokens are slow
In-Reply-To: <iZQcBD6T9iP0Nffuwyra9Oyjdbvexg1TyMacRRVJa8o=.a7f584f5-c1f4-469a-8b8b-a73613ee290c@github.com>
References: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>
 <iZQcBD6T9iP0Nffuwyra9Oyjdbvexg1TyMacRRVJa8o=.a7f584f5-c1f4-469a-8b8b-a73613ee290c@github.com>
Message-ID: <_9byRKx1bOoZQrNflYJnSC_It-91N9wd3xbQJgbncyA=.7c65cca9-5b9b-4811-aeb3-7bb92e9a7f54@github.com>

On Thu, 29 Jan 2026 12:50:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR changes the implementation of remapping stateless reset tokens to avoid using linear-time operations.
>> 
>> No new tests. Existing tier1 and tier2 tests continue to pass.
>
> The change looks reasonable. Please make sure to give it a good shake in the CI before pushing.

Thanks @dfuch for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/29484#issuecomment-3823832201

From djelinski at openjdk.org  Fri Jan 30 13:47:56 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 13:47:56 GMT
Subject: Integrated: 8373604: Operations on peer reset tokens are slow
In-Reply-To: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>
References: <3tezQypilhD4AkL8nux7Awqdi5oTgo-H3ZUk_AjeHl8=.7749a89d-eaa9-47dc-b6c5-75d2ba8d291a@github.com>
Message-ID: <N31ECQoAQAT_jTdKEyKKzHUPVLXGAq4kWXGbnu86euM=.7a6a9974-f9c1-4b41-b8ef-fb736d3c3b59@github.com>

On Thu, 29 Jan 2026 11:44:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR changes the implementation of remapping stateless reset tokens to avoid using linear-time operations.
> 
> No new tests. Existing tier1 and tier2 tests continue to pass.

This pull request has now been integrated.

Changeset: df8c4d6d
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df8c4d6d12dacd0adfcf8c711c8671913d805309
Stats:     63 lines in 4 files changed: 42 ins; 0 del; 21 mod

8373604: Operations on peer reset tokens are slow

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.org  Fri Jan 30 14:25:05 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 14:25:05 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v3]
In-Reply-To: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
Message-ID: <V6l2beIcL99jsPGa6bUEpjXL7ya0vD_B7HJxWtE_CSk=.2c88e5dc-29ef-4bc8-be7d-b082942e10a7@github.com>

> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.

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 CancelRequestTest-Sem-8376308
 - Review feedback: IOExceptions are not unexpected
 - Review feedback
 - Copyright year + unused imports
 - 8376308: java/net/httpclient/CancelRequestTest.java fails intermittently with "Expected CancellationException not received"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29415/files
  - new: https://git.openjdk.org/jdk/pull/29415/files/4fa0b27a..effad463

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

  Stats: 8607 lines in 279 files changed: 5101 ins; 2120 del; 1386 mod
  Patch: https://git.openjdk.org/jdk/pull/29415.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29415/head:pull/29415

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

From dfuchs at openjdk.org  Fri Jan 30 14:25:07 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 14:25:07 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v2]
In-Reply-To: <0moSIEr5zpoHmXkPDvXqMyhtHgBLW6hSIeldKJv5TK0=.fe04efe0-71e0-4547-a50a-03682d88f157@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <sV7dqkhJRZolsX7WNx-e9MD-3TIQ3HkQZwXFtmrq_Do=.484befe8-6261-466f-9dbf-9335395c7387@github.com>
 <0moSIEr5zpoHmXkPDvXqMyhtHgBLW6hSIeldKJv5TK0=.fe04efe0-71e0-4547-a50a-03682d88f157@github.com>
Message-ID: <UVgVT-g5KPK4zZGHDdLGGzkoi8PRc99PF1W81APEQhM=.2ef6229f-84c7-4025-8ea1-f9831d32228e@github.com>

On Fri, 30 Jan 2026 12:45:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> Marked as reviewed by djelinski (Reviewer).

@djelinski I fixed the issue with stack traces being printed for expected exceptions. If you could have a look again?
Those exceptions stacks were in fact printed twice: once in the handler and once in the HttpServerAdapters infrastructure. Fortunately the latter can be switched off by adding an "X-expect-exception:" header, and the former have now been supressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/29415#issuecomment-3824026244

From djelinski at openjdk.org  Fri Jan 30 14:54:24 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jan 2026 14:54:24 GMT
Subject: RFR: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received" [v3]
In-Reply-To: <V6l2beIcL99jsPGa6bUEpjXL7ya0vD_B7HJxWtE_CSk=.2c88e5dc-29ef-4bc8-be7d-b082942e10a7@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
 <V6l2beIcL99jsPGa6bUEpjXL7ya0vD_B7HJxWtE_CSk=.2c88e5dc-29ef-4bc8-be7d-b082942e10a7@github.com>
Message-ID: <1jataW83xfLdUtJwt-DuxZE33D7rXFPSCFbU2BewBo8=.7e54c2b9-f39d-409a-85b4-004fb51f29fd@github.com>

On Fri, 30 Jan 2026 14:25:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
>> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.
>
> 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 CancelRequestTest-Sem-8376308
>  - Review feedback: IOExceptions are not unexpected
>  - Review feedback
>  - Copyright year + unused imports
>  - 8376308: java/net/httpclient/CancelRequestTest.java fails intermittently with "Expected CancellationException not received"

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29415#pullrequestreview-3728791028

From duke at openjdk.org  Fri Jan 30 15:27:53 2026
From: duke at openjdk.org (Brett Okken)
Date: Fri, 30 Jan 2026 15:27:53 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
In-Reply-To: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
References: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
Message-ID: <7Hd_5rWqKTqFPX9qF5e4oLRydMelUQsJ3s8CQ6AJczQ=.b068bbe6-820f-4ff4-932f-83686bf12870@github.com>

On Thu, 29 Jan 2026 15:32:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.
> 
> In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

I am not an official reviewer, but changes look good to me.
The "snapshot" build passes the reproducer posted with the issue.

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

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

PR Review: https://git.openjdk.org/jdk/pull/29489#pullrequestreview-3728939814

From dfuchs at openjdk.org  Fri Jan 30 15:34:03 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 15:34:03 GMT
Subject: RFR: 8376031: HttpsURLConnection.getServerCertificates() throws
 "java.lang.IllegalStateException: connection not yet open" for the HEAD method
In-Reply-To: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
References: <dR0upqPEpJY5DoqLkFAgvOrQY5K8by_G-pG-PdG0Uvo=.a9036e97-4409-4839-81bb-c5d6f45a5b9f@github.com>
Message-ID: <ueyhHaAlpKszhuQcjqed8sfgfKF6geHHPn23E5MecHc=.249585ac-e32d-4e6b-b883-c9aac5a021fb@github.com>

On Thu, 29 Jan 2026 15:32:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The issue here is that `HttpURLConnection` is automatically disconnected (`HttpClient` is set to `null`, `connected` is set to `false`) when a response with no response body bytes is received. This happens before a fake empty body input stream is returned to the user. That behaviour also occurs with any method for which `content-length: 0` is returned (GET, POST, custom, anything), and with any status code (204, 304) for which there is no body.
> 
> In this case, the proposed fix is to store the `SSLSession` in the `AbstractDelegateHttpsURLConnection` subclass until such a time where `disconnect()` is explicitely closed. Information pertaining to SSL, such as server certificates, can be extracted from the saved `SSLSession`.

Thank you Brett! Much appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/29489#issuecomment-3824329058

From dfuchs at openjdk.org  Fri Jan 30 15:48:01 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jan 2026 15:48:01 GMT
Subject: Integrated: 8376308: java/net/httpclient/CancelRequestTest.java fails
 intermittently with "Expected CancellationException not received"
In-Reply-To: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
References: <phSI9hyJGGWyw4eJn7kvvVLsP-CQ7zzeLtNXo0dq-ZI=.aa69a03f-7bb3-4d5d-abf6-cf3fb33f6a60@github.com>
Message-ID: <heq7YcR6MOcTHKgPyQYdx4wxoM90RuoSHo8Hy_F62vk=.2c05dfc7-8a00-4478-9c63-5e72973ce270@github.com>

On Mon, 26 Jan 2026 13:09:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When using async mode, and if the "wrong" test/client thread gets suspended at the wrong time there's a small time window in which the server might be able to send its reply before the request is cancelled.
> This can be avoided by having the server handler wait on a semaphore until the cancellation exception has been propagated to the caller on the client side.

This pull request has now been integrated.

Changeset: 96180b9c
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96180b9c56a03f6d7cb22c0618ed7d946beae6bf
Stats:     92 lines in 1 file changed: 52 ins; 1 del; 39 mod

8376308: java/net/httpclient/CancelRequestTest.java fails intermittently with "Expected CancellationException not received"

Reviewed-by: djelinski, vyazici

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

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

From xuelei at openjdk.org  Fri Jan 30 17:37:08 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 30 Jan 2026 17:37:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
Message-ID: <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>

On Thu, 29 Jan 2026 18:15:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:
>> 
>>> 146:         // the deflated certificate data in a memory cache statically and avoid
>>> 147:         // compressing local certificates repeatedly for every handshake.
>>> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =
>> 
>> I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance, without using static field?
>
> Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.

I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.

The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747291754

From abarashev at openjdk.org  Fri Jan 30 18:16:08 2026
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 30 Jan 2026 18:16:08 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
 <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
Message-ID: <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>

On Fri, 30 Jan 2026 17:33:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.
>
> I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.
> 
> The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.

Yes, good point, it is different, I've done similar research. I'll look closer into this, thanks! Some problems I can see with this approach though:

-  Such caching won't work with a 3rd party `X509ExtendedKeyManager` implementations.
- `CertificateMessage` is not just a single certificate, it's the list of certificate entries plus certificate_request_context. Logically such cache doesn't belong to a KeyManager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747427885

From xuelei at openjdk.org  Fri Jan 30 19:41:49 2026
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 30 Jan 2026 19:41:49 GMT
Subject: RFR: 8372526: Add support for ZLIB TLS Certificate Compression
 [v13]
In-Reply-To: <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>
References: <oGDbmt6ne49-t7Ak1I3clv9Wcp15K8sv9tXfLYSRHOc=.d6780638-fc1c-4b11-aaf9-e4f113f513a6@github.com>
 <Ya1nGJJrCO5IkdqhYTIeS85I4q3cna_fEtn81uYLv5E=.c3aec247-3b4e-41f8-829e-6e1b813edb5b@github.com>
 <Ag1zV75rDv2o_pyZR_B4LFplmVfibBbrSXNCpMZmuTk=.1d45afbd-a37b-4114-8b02-f6779452c2a8@github.com>
 <KqBPy_GpoXAcWuMOvtAomVx-Y2rZV7NVceSY7gvR6-0=.371b2bcf-1f61-4074-9982-c534b3a2c108@github.com>
 <uDEn8dr5KZLPtyh3Sl0y6d8ASDfMQnGZwb4Gy-OSrvQ=.5eac767c-e8a7-4c6f-b151-77acb469b631@github.com>
 <BSiZLYb9AvpYpzDFckUcigX62Q_nGO_k1ygGRIAVoeI=.e13ae5df-93cf-4343-885f-00201438e740@github.com>
Message-ID: <sp1YClqkeK454SE1GYDn2jTq1nxaxGbmLkZOljhCcK0=.e8e5ffc0-a01e-4196-b32b-a4dd13926df2@github.com>

On Fri, 30 Jan 2026 18:13:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.
>> 
>> The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.
>
> Yes, good point, it is different, I've done similar research. I'll look closer into this, thanks! Some problems I can see with this approach though:
> 
> -  Such caching won't work with a 3rd party `X509ExtendedKeyManager` implementations.
> - `CertificateMessage` is not just a single certificate, it's the list of certificate entries plus certificate_request_context. Logically such cache doesn't belong to a KeyManager.

Yes, a tricky case.  Thank you @artur-oracle for considering this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747699841