From aturbanov at openjdk.org  Sun Mar  1 20:52:23 2026
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 1 Mar 2026 20:52:23 GMT
Subject: RFR: 8378565: Refactor test/jdk/java/net/httpclient/http3/*.java
 TestNG tests to JUnit
In-Reply-To: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
References: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
Message-ID: <leZrNJpySdf-0d73m8BVS-GcqXOiKCLKfMbOE8nPi-4=.c5069b36-2660-4d32-b9b6-05059d5f2df5@github.com>

On Tue, 24 Feb 2026 14:21:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a followup from https://github.com/openjdk/jdk/pull/29850, this time converting all (but one) TestNG tests under `test/jdk/java/net/httpclient/http3/` to use JUnit

test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java line 109:

> 107:     static final String MAIN_RESPONSE_BODY = "the main response body";
> 108: 
> 109:     private static HttpTestServer  server;

Suggestion:

    private static HttpTestServer server;

test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java line 83:

> 81:     static final String MAIN_RESPONSE_BODY = "the main response body";
> 82: 
> 83:     private static HttpTestServer  server;

Suggestion:

    private static HttpTestServer server;

test/jdk/java/net/httpclient/http3/H3PushCancel.java line 97:

> 95:     static final String MAIN_RESPONSE_BODY = "the main response body";
> 96: 
> 97:     private static HttpTestServer  server;

Suggestion:

    private static HttpTestServer server;

test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java line 113:

> 111:     static final int REQUESTS = 5;
> 112: 
> 113:     private static HttpTestServer  server;

Suggestion:

    private static HttpTestServer server;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29893#discussion_r2869786113
PR Review Comment: https://git.openjdk.org/jdk/pull/29893#discussion_r2869786587
PR Review Comment: https://git.openjdk.org/jdk/pull/29893#discussion_r2869786861
PR Review Comment: https://git.openjdk.org/jdk/pull/29893#discussion_r2869786322

From djelinski at openjdk.org  Mon Mar  2 10:58:57 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Mar 2026 10:58:57 GMT
Subject: RFR: 8378927: H3MultipleConnectionsToSameHost.java#with-continuations
 intermittent fails
Message-ID: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>

Raise the QUIC connection timeout in the H3MultipleConnectionsToSameHost test above the jtreg timeout.

The test failed with a QUIC connection timeout, but the reason for the timeout was not found in the logs. This kind of failure is usually caused by one of:
- packet loss; when that happens, the congestion controller slows down the sending rate until the connection times out,
- threading issues like races / deadlocks
- overloaded machine; the threads might not get enough CPU time to respond before the timeout expires.

Increasing the QUIC connection timeout should mitigate the packet loss and CPU issues, and will provide additional information like thread / core dumps to help with diagnosing threading issues.

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

Commit messages:
 - Raise QUIC connection timeout above jtreg timeout

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

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

From djelinski at openjdk.org  Mon Mar  2 12:09:29 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Mar 2026 12:09:29 GMT
Subject: RFR: 8378786: PeerConnectionId::cloneBuffer should use absolute
 bulk get [v2]
In-Reply-To: <y0KLQwq9uMxXmDuJ7gC4k7QlDF9aGfFGUjeM7eIiiBk=.f73e1f43-4a7c-4768-a4be-2488df126a77@github.com>
References: <RqK65GiLNE5XN4ClX_V2jy81aPEaw01oG8SH__OcZ1I=.341a5413-b12f-4206-9d54-ffa0fe6aca94@github.com>
 <y0KLQwq9uMxXmDuJ7gC4k7QlDF9aGfFGUjeM7eIiiBk=.f73e1f43-4a7c-4768-a4be-2488df126a77@github.com>
Message-ID: <Y_4I4x7XxcBIQCdR-twwMuhtTNma8BxmPGCY40VekwQ=.006c3f35-098a-4470-83fc-e8a776e6464c@github.com>

On Fri, 27 Feb 2026 16:03:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> PeerConnectionId has a constructor that takes a ByteBuffer containing the peer connection id bytes. This constructor extracts the connection id bytes from the given byte buffer and makes a private copy for itself. However, while doing so, it uses a relative bulk get instead of an absolute bulk get, which causes the original byte buffer position to move to the limit.
>> 
>> This is causing trouble on the server side, this is the only place where that constructor is used without making a slice of the original buffer first. In some circumstances (if the connection id is not found) it can cause the first initial packet to get dropped after creating the connection. This went unnoticed because the client will then retransmit that packet, and the connection id will be found the next time around.
>> 
>> Though the issue is in product source code it only affects the server side used by httpclient tests. 
>> 
>> The proposed change first adds some assert statements to `QuicConnectionImpl::internalProcessIncoming` and ensure that the connection will get closed if the assert fires. This made it possible to reproduce and surface the issue quite easily using existing httpclient tests: a lot of tests started failing with that change ([this is done by the first commit in this PR](https://github.com/openjdk/jdk/pull/29956/changes/b81ce5d405054b06afdf70738119916bba08ce72)).
>> The [second commit](https://github.com/openjdk/jdk/pull/29956/changes/108660362d4fa78e61c784931fe6d45e002381dc) fixes the issue by making `PeerConnectionId::cloneBuffer` use an absolute bulk get instead of a relative bulk get. The absolute bulk get ensures that the position of the input buffer is not moved while copying it.
>> 
>> I am marking the issue as `noreg-hard` - though it could be very easily verified by undoing the second commit, recompiling the JDK, and running the test with that. Then add the second commit, recompile, and see that all tests are passing.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: add comment

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29956#pullrequestreview-3875804672

From djelinski at openjdk.org  Mon Mar  2 12:09:30 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Mar 2026 12:09:30 GMT
Subject: RFR: 8378786: PeerConnectionId::cloneBuffer should use absolute
 bulk get [v2]
In-Reply-To: <xxprK-6FNEII3g7uhu35MApo2KmKRc2HhHno0dKJvSM=.4b8cb0da-cdf4-4b33-89fc-ecad26d44b92@github.com>
References: <RqK65GiLNE5XN4ClX_V2jy81aPEaw01oG8SH__OcZ1I=.341a5413-b12f-4206-9d54-ffa0fe6aca94@github.com>
 <GdKRJ0Ga05crODtsoi3xfVbyAusdeTMs5Kyz0jJnNI0=.c2567249-149d-4f41-889d-f83d120cea3c@github.com>
 <SwKsMX_GV9kiNjsZGt_t6RCzsBmGYGu0wexuU3b9_nQ=.a36f528e-edfe-414d-a8ea-9aed12ce0905@github.com>
 <-bE-cApE8jZPNha-kom3z_Zoi9rRtMFjMF2AfmC72dQ=.2cdaff8e-eaac-48da-a3f3-91f59af20b40@github.com>
 <xxprK-6FNEII3g7uhu35MApo2KmKRc2HhHno0dKJvSM=.4b8cb0da-cdf4-4b33-89fc-ecad26d44b92@github.com>
Message-ID: <PiZlSmIDNLMp3dsq8yt2LaKVL5zvXm2Sz2Ijnsfd-s0=.537e079c-9f18-4273-a01e-62632cccb372@github.com>

On Fri, 27 Feb 2026 15:58:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see. I'm assuming this is the most economic ? in terms of, not just LoC, but also complexity ? way to inform tests about this unexpected condition.
>
> yes - otherwise you would have to read the logs in order to notice the stack trace there, because simply dropping the packet will typically not make the test to fail (it did not in our case, hence the reason it went unnoticed).

We should probably have a list of exception types that should *not* close the exception instead. But that probably deserves a separate ticket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29956#discussion_r2872081744

From dfuchs at openjdk.org  Mon Mar  2 13:08:10 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 13:08:10 GMT
Subject: RFR: 8378565: Refactor test/jdk/java/net/httpclient/http3/*.java
 TestNG tests to JUnit [v2]
In-Reply-To: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
References: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
Message-ID: <nt_TkXNNUoUdpE2Yzyipd1gjqxgG2FTYV1l_CauXnew=.99c7f0d5-bfc5-48ae-9207-c53b2bb564a0@github.com>

> This is a followup from https://github.com/openjdk/jdk/pull/29850, this time converting all (but one) TestNG tests under `test/jdk/java/net/httpclient/http3/` to use JUnit

Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:

 - Update test/jdk/java/net/httpclient/http3/H3PushCancel.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29893/files
  - new: https://git.openjdk.org/jdk/pull/29893/files/ea078e4c..a90de6d8

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

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

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

From djelinski at openjdk.org  Mon Mar  2 13:09:28 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Mar 2026 13:09:28 GMT
Subject: RFR: 8378180: Compiling OpenJDK with C23 C-Compiler gives warning:
 initialization discards =?UTF-8?B?4oCYY29uc3TigJk=?= qualifier from pointer
 target type
In-Reply-To: <ZMgHMVJXCvSHKIQczEV88lEQge9p2IKAlF7g7x_bYwQ=.cc24304d-25ab-4aa9-bba7-ae4023820c0a@github.com>
References: <ZMgHMVJXCvSHKIQczEV88lEQge9p2IKAlF7g7x_bYwQ=.cc24304d-25ab-4aa9-bba7-ae4023820c0a@github.com>
Message-ID: <l-PEEHisDI_Uvg8G95OjiCwGNSN606U5YOJOYPgITVM=.ae9a4e76-83a7-4266-85b2-652105476474@github.com>

On Thu, 26 Feb 2026 04:26:43 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> Hi all, this is a quick patch to fix a build issue I encountered when updating my Linux system. [Glibc 2.43](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html) changes the definition of some string related functions to return `const char*` when provided a `const char*` parameter, rather than the previous behavior of returning `char*`. I've fixed this by applying the `const` modifier, and casting to `char*` when needed. This should be backwards-compatible since assigning a non-const pointer to const is an implicit conversion. Thoughts and comments would be appreciated on whether this is the best way to fix this issue. Thanks!

src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 230:

> 228: 
> 229: static int initDebPackage(void* desc, const char* str) {
> 230:     char* colonChrPos = (char*) strchr(str, ':');

`str` should really be `char*` instead; it's modified in line 232 below. Once you change `str`'s type, you will no longer need a cast here.

You'll also need to modify the `popenCallbackType` type to remove `const`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29929#discussion_r2872329859

From ehs122100 at gmail.com  Mon Mar  2 13:35:41 2026
From: ehs122100 at gmail.com (Hyunsu Eun)
Date: Mon, 2 Mar 2026 22:35:41 +0900
Subject: [External] : HttpCookie: Unparseable Expires attribute causes
 immediate expiration
Message-ID: <8F8D7B02-513F-445E-8E40-FBC90F64CBE0@gmail.com>

Hi,

It seems that java.net.HttpCookie treats cookies with an
unparseable Expires attribute as immediately expired.

According to RFC 6265 (section 5.2.1), if the Expires value
fails to parse as a cookie date, the attribute should be ignored.
In that case, the cookie should remain a session cookie rather
than being treated as expired.

From reading the implementation, this appears to stem from
HttpCookie.expiryDate2DeltaSeconds() returning 0 when parsing
fails, after which maxAge is set to 0.

Would this be considered a bug?

I can provide a small reproducer if helpful, and would be
happy to file a JBS issue and prepare a patch if appropriate.

Thanks,
Hyunsu Eun

From syan at openjdk.org  Mon Mar  2 13:59:13 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 2 Mar 2026 13:59:13 GMT
Subject: RFR: 8378927:
 H3MultipleConnectionsToSameHost.java#with-continuations intermittent fails
In-Reply-To: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>
References: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>
Message-ID: <aUBiJeeHqe2kUq6Ur6M5pbZqNhaEf5DDyOVM4SboN2o=.c48a584f-242c-440a-af47-9be29dc3f012@github.com>

On Mon, 2 Mar 2026 10:51:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Raise the QUIC connection timeout in the H3MultipleConnectionsToSameHost test above the jtreg timeout.
> 
> The test failed with a QUIC connection timeout, but the reason for the timeout was not found in the logs. This kind of failure is usually caused by one of:
> - packet loss; when that happens, the congestion controller slows down the sending rate until the connection times out,
> - threading issues like races / deadlocks
> - overloaded machine; the threads might not get enough CPU time to respond before the timeout expires.
> 
> Increasing the QUIC connection timeout should mitigate the packet loss and CPU issues, and will provide additional information like thread / core dumps to help with diagnosing threading issues.

After apply the proposed patch, test seems more ronustness.

The useNioSelector intermittent fails "Connection closed by server peer: INTERNAL_ERROR". Maybe this intermittent was not introdued by the propsoed patch.

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

PR Review: https://git.openjdk.org/jdk/pull/29993#pullrequestreview-3876396171

From dfuchs at openjdk.org  Mon Mar  2 14:02:46 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 14:02:46 GMT
Subject: RFR: 8378927:
 H3MultipleConnectionsToSameHost.java#with-continuations intermittent fails
In-Reply-To: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>
References: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>
Message-ID: <Nvfl3rG_lyX0f4WZPZFnfdOR5G8E9ecArmhaQv2Y-J4=.2d5e97b8-287f-41dc-9ac2-4771784275e2@github.com>

On Mon, 2 Mar 2026 10:51:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Raise the QUIC connection timeout in the H3MultipleConnectionsToSameHost test above the jtreg timeout.
> 
> The test failed with a QUIC connection timeout, but the reason for the timeout was not found in the logs. This kind of failure is usually caused by one of:
> - packet loss; when that happens, the congestion controller slows down the sending rate until the connection times out,
> - threading issues like races / deadlocks
> - overloaded machine; the threads might not get enough CPU time to respond before the timeout expires.
> 
> Increasing the QUIC connection timeout should mitigate the packet loss and CPU issues, and will provide additional information like thread / core dumps to help with diagnosing threading issues.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29993#pullrequestreview-3876414522

From dfuchs at openjdk.org  Mon Mar  2 14:13:40 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 14:13:40 GMT
Subject: RFR: 8378565: Refactor test/jdk/java/net/httpclient/http3/*.java
 TestNG tests to JUnit [v2]
In-Reply-To: <5EU1xO_ONyVCbBe-RqjiLWMHU7ThhVomGrScCtikPp4=.6b9c8b4f-1103-4460-a465-b16710e1f674@github.com>
References: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
 <5EU1xO_ONyVCbBe-RqjiLWMHU7ThhVomGrScCtikPp4=.6b9c8b4f-1103-4460-a465-b16710e1f674@github.com>
Message-ID: <XrGsVRpXxW4i-5UbdM_nORFnU78wrFfAP9tWQPu_Ce4=.c82a8d10-39eb-40c4-bc37-d147c44cc18b@github.com>

On Fri, 27 Feb 2026 13:13:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update test/jdk/java/net/httpclient/http3/H3PushCancel.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> @dfuch, LGTM. The conversion is performed with minimal changes. This extremely helped with the review. Thanks so much.
> 
> I'm assuming that
> 
> 1. You've checked the touched files in an IDE and verified that there are no unused imports, etc.
> 2. Tier 1-2 is clear.
> 3. Copyright years of the touched files are updated accordingly.

@vy if you could re-review - there's only a couple whitespace changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/29893#issuecomment-3984647285

From dfuchs at openjdk.org  Mon Mar  2 14:16:39 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 14:16:39 GMT
Subject: Integrated: 8378786: PeerConnectionId::cloneBuffer should use absolute
 bulk get
In-Reply-To: <RqK65GiLNE5XN4ClX_V2jy81aPEaw01oG8SH__OcZ1I=.341a5413-b12f-4206-9d54-ffa0fe6aca94@github.com>
References: <RqK65GiLNE5XN4ClX_V2jy81aPEaw01oG8SH__OcZ1I=.341a5413-b12f-4206-9d54-ffa0fe6aca94@github.com>
Message-ID: <L-xpF4MLVA1CEHiWd364iRjVU_CW5LtKh3Vqnodn3FQ=.6d774b4e-d078-4554-9d43-cddc9dfc0b97@github.com>

On Fri, 27 Feb 2026 11:47:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> PeerConnectionId has a constructor that takes a ByteBuffer containing the peer connection id bytes. This constructor extracts the connection id bytes from the given byte buffer and makes a private copy for itself. However, while doing so, it uses a relative bulk get instead of an absolute bulk get, which causes the original byte buffer position to move to the limit.
> 
> This is causing trouble on the server side, this is the only place where that constructor is used without making a slice of the original buffer first. In some circumstances (if the connection id is not found) it can cause the first initial packet to get dropped after creating the connection. This went unnoticed because the client will then retransmit that packet, and the connection id will be found the next time around.
> 
> Though the issue is in product source code it only affects the server side used by httpclient tests. 
> 
> The proposed change first adds some assert statements to `QuicConnectionImpl::internalProcessIncoming` and ensure that the connection will get closed if the assert fires. This made it possible to reproduce and surface the issue quite easily using existing httpclient tests: a lot of tests started failing with that change ([this is done by the first commit in this PR](https://github.com/openjdk/jdk/pull/29956/changes/b81ce5d405054b06afdf70738119916bba08ce72)).
> The [second commit](https://github.com/openjdk/jdk/pull/29956/changes/108660362d4fa78e61c784931fe6d45e002381dc) fixes the issue by making `PeerConnectionId::cloneBuffer` use an absolute bulk get instead of a relative bulk get. The absolute bulk get ensures that the position of the input buffer is not moved while copying it.
> 
> I am marking the issue as `noreg-hard` - though it could be very easily verified by undoing the second commit, recompiling the JDK, and running the test with that. Then add the second commit, recompile, and see that all tests are passing.

This pull request has now been integrated.

Changeset: 373ad02d
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/373ad02d3a1fefcd3e1b3b90f594ab7a2cacfd9f
Stats:     21 lines in 2 files changed: 18 ins; 0 del; 3 mod

8378786: PeerConnectionId::cloneBuffer should use absolute bulk get

Reviewed-by: vyazici, djelinski

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

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

From dfuchs at openjdk.org  Mon Mar  2 14:16:47 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 14:16:47 GMT
Subject: Integrated: 8378595: Refactor miscellaneous tests under
 test/jdk/java/net/httpclient from TestNG to JUnit
In-Reply-To: <8m8ulq9SHhLioHX_nPLDCz4FEBc2u4U-2hvZpX1Dk8k=.b14a0a0c-c5ff-4d5f-b1ef-e4fccc4a0c35@github.com>
References: <8m8ulq9SHhLioHX_nPLDCz4FEBc2u4U-2hvZpX1Dk8k=.b14a0a0c-c5ff-4d5f-b1ef-e4fccc4a0c35@github.com>
Message-ID: <6FUg96-vpMrYtLdKy10QPZL_BBAxsX1roEtxvDpLmGs=.71efae22-f697-40a5-8c27-7916df805c1a@github.com>

On Tue, 24 Feb 2026 18:09:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> A small changeset to convert TestNG tests under `test/jdk/java/net/httpclient/security`, `test/jdk/java/net/httpclient/offline`, and `test/jdk/java/net/httpclient/PathSubscriber` to JUnit.

This pull request has now been integrated.

Changeset: 2c3e4f08
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c3e4f08fa3f15fa37b59dff89b6039ac1051a6d
Stats:     174 lines in 7 files changed: 40 ins; 23 del; 111 mod

8378595: Refactor miscellaneous tests under test/jdk/java/net/httpclient from TestNG to JUnit

Reviewed-by: syan, vyazici

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

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

From djelinski at openjdk.org  Mon Mar  2 14:45:31 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Mar 2026 14:45:31 GMT
Subject: RFR: 8378927:
 H3MultipleConnectionsToSameHost.java#with-continuations intermittent fails
In-Reply-To: <aUBiJeeHqe2kUq6Ur6M5pbZqNhaEf5DDyOVM4SboN2o=.c48a584f-242c-440a-af47-9be29dc3f012@github.com>
References: <GIolPVEhV1wgCQDXlc77iRoVHXEa4WFnUkrdA1RACgM=.56437712-835e-4151-b7ea-25b424da87a5@github.com>
 <aUBiJeeHqe2kUq6Ur6M5pbZqNhaEf5DDyOVM4SboN2o=.c48a584f-242c-440a-af47-9be29dc3f012@github.com>
Message-ID: <3zU4iP1SVi4G3Ryq4FrFuSECa6zpEFg3ltztvWTM61s=.295a19b9-58f6-450d-8fdd-d25f8792bd43@github.com>

On Mon, 2 Mar 2026 13:56:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> The useNioSelector intermittent fails "Connection closed by server peer: INTERNAL_ERROR". Maybe this intermittent was not introdued by the propsoed patch.

Thanks for testing! INTERNAL_ERROR is usually sent in response to an unexpected exception. Could you check the test log for exceptions or for any additional failure information (possibly in a line containing `entering closing state`)?

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

PR Comment: https://git.openjdk.org/jdk/pull/29993#issuecomment-3984818679

From vyazici at openjdk.org  Mon Mar  2 14:58:36 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Mar 2026 14:58:36 GMT
Subject: RFR: 8378565: Refactor test/jdk/java/net/httpclient/http3/*.java
 TestNG tests to JUnit [v2]
In-Reply-To: <nt_TkXNNUoUdpE2Yzyipd1gjqxgG2FTYV1l_CauXnew=.99c7f0d5-bfc5-48ae-9207-c53b2bb564a0@github.com>
References: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
 <nt_TkXNNUoUdpE2Yzyipd1gjqxgG2FTYV1l_CauXnew=.99c7f0d5-bfc5-48ae-9207-c53b2bb564a0@github.com>
Message-ID: <LeclQqonbdsFOD6rDWmhQmQYOvTZZ0gR9kgOdleGACg=.476beba7-6ea8-4fb7-b39a-0aa83c2d24ab@github.com>

On Mon, 2 Mar 2026 13:08:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a followup from https://github.com/openjdk/jdk/pull/29850, this time converting all (but one) TestNG tests under `test/jdk/java/net/httpclient/http3/` to use JUnit
>
> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/net/httpclient/http3/H3PushCancel.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by vyazici (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29893#pullrequestreview-3876728461

From daniel.fuchs at oracle.com  Mon Mar  2 15:32:31 2026
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 2 Mar 2026 15:32:31 +0000
Subject: HttpCookie: Unparseable Expires attribute causes immediate
 expiration
In-Reply-To: <8F8D7B02-513F-445E-8E40-FBC90F64CBE0@gmail.com>
References: <8F8D7B02-513F-445E-8E40-FBC90F64CBE0@gmail.com>
Message-ID: <e5d3c298-e9e7-4e6a-b350-1a6b1cb92729@oracle.com>

Hi,

On which version of the JDK did you observe this behavior?
The behaviour of HttpCookie.parse has been updated in JDK 26,
so I would expect this to be fixed in JDK 26.

See: https://bugs.openjdk.org/browse/JDK-8359343

Could you try to reproduce the issue on JDK 26?
https://jdk.java.net/26/

If the behavior still persists, then yes it's probably a bug
since the specification for getMaxAge() now says:

```
+     * The value of this attribute is determined by the following 
steps, in line
+     * with RFC 6265:
+     *
+     * <ol><li>If {@link #setMaxAge(long)} was called, return the value 
set.</li>
+     * <li>If previous step failed, and a {@code Max-Age} attribute was 
parsed
+     * then return that value.</li>
+     * <li>If previous step failed, and an {@code Expires} attribute 
was parsed
+     * then the maxAge calculated at parsing time from that date, is 
returned</li>
+     * <li>If previous step failed, then return {@code -1}.</li></ol>
```

best regards,

-- daniel

On 02/03/2026 13:35, Hyunsu Eun wrote:
> Hi,
> 
> It seems that java.net.HttpCookie treats cookies with an
> unparseable Expires attribute as immediately expired.
> 
> According to RFC 6265 (section 5.2.1), if the Expires value
> fails to parse as a cookie date, the attribute should be ignored.
> In that case, the cookie should remain a session cookie rather
> than being treated as expired.
> 
>  From reading the implementation, this appears to stem from
> HttpCookie.expiryDate2DeltaSeconds() returning 0 when parsing
> fails, after which maxAge is set to 0.
> 
> Would this be considered a bug?
> 
> I can provide a small reproducer if helpful, and would be
> happy to file a JBS issue and prepare a patch if appropriate.
> 
> Thanks,
> Hyunsu Eun


From dfuchs at openjdk.org  Mon Mar  2 15:40:55 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Mar 2026 15:40:55 GMT
Subject: Integrated: 8378565: Refactor
 test/jdk/java/net/httpclient/http3/*.java TestNG tests to JUnit
In-Reply-To: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
References: <ZqcCR0pAOsmx2yC7uoIMtRJni_ts8SbqhIdFG3_vULM=.5490d321-eb6f-4a34-9d71-f0584de0ebc9@github.com>
Message-ID: <-wbEpPBWKcDdJNPsiuAvXR7t-yc24wQbpD2LixODWhI=.642ea416-0124-4b24-858c-e54e3476c254@github.com>

On Tue, 24 Feb 2026 14:21:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a followup from https://github.com/openjdk/jdk/pull/29850, this time converting all (but one) TestNG tests under `test/jdk/java/net/httpclient/http3/` to use JUnit

This pull request has now been integrated.

Changeset: 7b5b70c9
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b5b70c9cb67b7e04d92fbf31dc1d1b97ee99613
Stats:     589 lines in 28 files changed: 99 ins; 84 del; 406 mod

8378565: Refactor test/jdk/java/net/httpclient/http3/*.java TestNG tests to JUnit

Reviewed-by: vyazici

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

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