From mdonovan at openjdk.org  Mon Jun  3 16:48:39 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Jun 2024 16:48:39 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
References: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
Message-ID: <HXX-m9uBa5xCxohuVss01cV4oWBMAQR9stLDwm-8drM=.a66da7f2-20db-4013-857f-e7f840b3dcd3@github.com>

> For this PR, I identified TLS tests that can fail due to hard-code certificates expiring. I updated those tests to use certificates that are generated programmatically. This includes adding some helper methods to the CertificateBuilder class to create builder objects with common default values. The builder can be further customized to meet the needs of the test. I also refactored some of the tests to put common functionality in base classes, further reducing duplicated code.
> 
> This PR does not include changes to SSLContextTemplate and the tests that use it. These tests require significant refactoring to incorporate programmatically generated certificates and should be a separate task.

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

 - made new methods for creating server and client certificates
 - Merge branch 'master' into certbuilding
 - renamed CertificateBuilder methods, updated tests, and removed duplication
 - Merge branch 'master' into certbuilding
 - 8325766: Review seclibs tests for cert expiry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18958/files
  - new: https://git.openjdk.org/jdk/pull/18958/files/d52e1265..b6ffb24b

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

  Stats: 102236 lines in 1995 files changed: 69895 ins; 20667 del; 11674 mod
  Patch: https://git.openjdk.org/jdk/pull/18958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18958/head:pull/18958

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

From mdonovan at openjdk.org  Mon Jun  3 16:53:03 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 3 Jun 2024 16:53:03 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <4H90D7UgJnkjpx1WLoSu3-r0d0KAGOtsr9F4O9Y4NQw=.bde1aa17-ace2-40d1-8639-5dd12d6d380a@github.com>
References: <DZNUaZvt51u1inYmCslRuMiIK0YLBo-OO64Tm-PiP6U=.d153eb33-f524-4aaf-927b-71ed496e39a3@github.com>
 <KYM2RmwTL7j-CjnPot_I8pgSC4RiDsG9sTAvoOqyTv4=.ab633852-0e1d-44ce-ae12-cad69afd2dd7@github.com>
 <GwlSbFIcMwTfPAxWfrCDD2KSLVWYeB58BYJgLSrXIKk=.7efacd66-6509-462d-afd1-2866bdcfbd33@github.com>
 <4H90D7UgJnkjpx1WLoSu3-r0d0KAGOtsr9F4O9Y4NQw=.bde1aa17-ace2-40d1-8639-5dd12d6d380a@github.com>
Message-ID: <kwlztnaoJMWmJbtmTy3GSBncCrY2ya7yiKhGlcu14Ds=.2416b0e8-48e8-4569-87c8-c31d1649afad@github.com>

On Thu, 23 May 2024 18:23:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I renamed the method. 
>> 
>> I don't want to over-generalize the code when I don't know what we'll need/want in the future. The tests in this PR just create CA and end-entity certs and with a couple exceptions, the tests in this PR are all of the tests that fail when the system clock is set to 2050. The exceptions are also client/server tests that don't need code signer and TSA certificates. 
>> 
>> When considering your comment, I went through the tests in this PR and found and removed some additional redundancy.
>
> The problem with generalizing an end-entity certificate is that there is not much you can generalize other than the cA field of the BasicConstraints extension being false (or not including the BC extension). Right now the newEndEntity() method looks like it is for TLS server certificates based on the KeyUsage extension (but it is also missing the KeyAgreement bit). But you could go further and add the EKU extension with the TLS server bit set. It shouldn't be used for TLS client certificates because they would have different KU extension values. Same for code signing end entity certificates. If you don't make it more specific, I feel that it is likely to be used to create certificates incorrectly.
> 
> So if you only need to create TLS server certs, I suggest renaming this method to newTLSServer() to make it clear it is for TLS server certs only. 
> 
> If a test needs to create certs which don't conform to a specific profile or have invalid fields, then it is probably better off calling CertificateBuilder methods itself rather than trying to create a helper method that satisfies all types of use cases.

The intent of these methods was not to create full certificates to satisfy lots of use cases but to create a CertificateBuilder object with the common fields (subject, serial number, validity, etc.) set. 

I see what you're saying about some of the extensions and created `newServerCertificateBuilder` and `newClientCertificateBuilder` methods that set key usage and the EKU extension for each.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18958#discussion_r1624772738

From michaelm at openjdk.org  Tue Jun  4 11:07:15 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 4 Jun 2024 11:07:15 GMT
Subject: RFR: 8332015: since-checker - Add @ since tags to jdk.httpserver
 [v2]
In-Reply-To: <mUrLGre5TAEVfIm7nma7Drip2I0H2_BZ41wXVhhe5ts=.e1abf58a-4934-4779-81cc-f047bd7b496b@github.com>
References: <APC0HtXoLuRj7qpFMH9fYUL4K-nzYZYsNNtiMMIpSyc=.e883276a-474e-4b84-a6aa-f70c5dea3c63@github.com>
 <mUrLGre5TAEVfIm7nma7Drip2I0H2_BZ41wXVhhe5ts=.e1abf58a-4934-4779-81cc-f047bd7b496b@github.com>
Message-ID: <N32NK3dRUnUHKBcSTdqbsVp4iqo1Nr_FypqLoaqQay0=.219ce3f2-5f0d-4fe6-8f50-7c8eb48602d3@github.com>

On Fri, 10 May 2024 03:53:12 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this simple change, aiming to fix current uses of `@since` in the source code
>> -The constructor BasicAuthenticator(java.lang.String,java.nio.charset.Charset) needs an `@since 14` instead of 9.
>> -com.sun.net.httpserver.spi: package-info.java does not contain an `@since`.
>> Thanks in advance.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright headers

Looks fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19168#pullrequestreview-2096062595

From nbenalla at openjdk.org  Tue Jun  4 11:41:08 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 11:41:08 GMT
Subject: Integrated: 8332015: since-checker - Add @ since tags to
 jdk.httpserver
In-Reply-To: <APC0HtXoLuRj7qpFMH9fYUL4K-nzYZYsNNtiMMIpSyc=.e883276a-474e-4b84-a6aa-f70c5dea3c63@github.com>
References: <APC0HtXoLuRj7qpFMH9fYUL4K-nzYZYsNNtiMMIpSyc=.e883276a-474e-4b84-a6aa-f70c5dea3c63@github.com>
Message-ID: <1V4opPPHy7MLcWvr4tc3SvGcLpBVzteXpduQ73m71As=.470d235f-2068-4317-87df-ca596f2b76ec@github.com>

On Fri, 10 May 2024 02:13:56 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this simple change, aiming to fix current uses of `@since` in the source code
> -The constructor BasicAuthenticator(java.lang.String,java.nio.charset.Charset) needs an `@since 14` instead of 9.
> -com.sun.net.httpserver.spi: package-info.java does not contain an `@since`.
> Thanks in advance.

This pull request has now been integrated.

Changeset: 9ee741d1
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ee741d1e55c2520b28a5e3ca0604073d81d0059
Stats:     4 lines in 2 files changed: 3 ins; 0 del; 1 mod

8332015: since-checker - Add @ since tags to jdk.httpserver

Reviewed-by: alanb, dfuchs, michaelm

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

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

From jpai at openjdk.org  Wed Jun  5 10:47:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 10:47:12 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers
Message-ID: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>

Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?

As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.

When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.

An existing jtreg test has been updated to reproduce this issue and verify the fix.

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

Commit messages:
 - 8333590: UnmodifiableHeaders shadows field declared in parent class

Changes: https://git.openjdk.org/jdk/pull/19555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333590
  Stats: 77 lines in 2 files changed: 64 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19555/head:pull/19555

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

From dfuchs at openjdk.org  Wed Jun  5 10:55:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Jun 2024 10:55:57 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers
In-Reply-To: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
Message-ID: <o8Ex7oa4Fn5h_nu6wZu2_bsHk9cEvI0B-fZDwMrOn2k=.654b795e-c78f-498e-b751-ba1feb18d4e2@github.com>

On Wed, 5 Jun 2024 10:42:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
> 
> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
> 
> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
> 
> An existing jtreg test has been updated to reproduce this issue and verify the fix.

src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java line 125:

> 123:     @Override
> 124:     public String toString() {
> 125:         return this.headers.toString();

Suggestion:

        return headers.toString();

to keep with the style of other methods in this class

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19555#discussion_r1627507259

From jpai at openjdk.org  Wed Jun  5 11:00:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 11:00:21 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers [v2]
In-Reply-To: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
Message-ID: <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
> 
> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
> 
> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
> 
> An existing jtreg test has been updated to reproduce this issue and verify the fix.

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

  Update src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19555/files
  - new: https://git.openjdk.org/jdk/pull/19555/files/c4713380..29a42d97

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

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

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

From dfuchs at openjdk.org  Wed Jun  5 11:28:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Jun 2024 11:28:57 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers [v2]
In-Reply-To: <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
 <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
Message-ID: <UOZwDyrZZAISx72PF1zTmq_kprXB-uj1yq5blPno2q8=.b221381d-7c6b-45a8-be0c-4eef1ff9c6a7@github.com>

On Wed, 5 Jun 2024 11:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
>> 
>> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
>> 
>> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
>> 
>> An existing jtreg test has been updated to reproduce this issue and verify the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19555#pullrequestreview-2098856889

From michaelm at openjdk.org  Wed Jun  5 13:06:00 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Jun 2024 13:06:00 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers [v2]
In-Reply-To: <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
 <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
Message-ID: <xd9ItstbgVVYMtBlKJZ_f9m_X8oblDLqFouogRWV1kM=.1969d3ed-4103-4180-b3a5-f4552a53f4e0@github.com>

On Wed, 5 Jun 2024 11:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
>> 
>> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
>> 
>> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
>> 
>> An existing jtreg test has been updated to reproduce this issue and verify the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Looks fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19555#pullrequestreview-2099077697

From jpai at openjdk.org  Wed Jun  5 13:44:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 13:44:00 GMT
Subject: RFR: 8333590: UnmodifiableHeaders.toString() returns a value that
 represents empty headers [v2]
In-Reply-To: <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
 <Iv3oKgiA3ukc9_RkAwL7NCWcCBkDka9JnCO8kmxRdOg=.3d5fcc7b-1114-42ee-90b4-cb082be7e33c@github.com>
Message-ID: <HaedXqHUwZ82snl4TKEyijj-W4LR0akElcA98XmvL0g=.f0132424-20ca-4661-bf3d-891bf23bb68e@github.com>

On Wed, 5 Jun 2024 11:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
>> 
>> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
>> 
>> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
>> 
>> An existing jtreg test has been updated to reproduce this issue and verify the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Thank you Daniel and Michael for the reviews. CI tier tests came back fine. I'll go ahead with the integration shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/19555#issuecomment-2149981092

From jpai at openjdk.org  Wed Jun  5 14:07:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 14:07:02 GMT
Subject: Integrated: 8333590: UnmodifiableHeaders.toString() returns a value
 that represents empty headers
In-Reply-To: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
References: <6Iuee5Pbs4Ed2NG2VZ9qVr4bGb3-43U7i2_UT_QrhTE=.223d4e26-a061-4ebb-aa33-c4881a789519@github.com>
Message-ID: <zTPK-pZsk9oIfoALjtHdKlzJiQRx-4UQ8Vrd3Qny8Zc=.8e942e02-2b12-4f9c-b134-c4c3710a6e27@github.com>

On Wed, 5 Jun 2024 10:42:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8333590?
> 
> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an internal class, within the `jdk.httpserver` module doesn't override the `toString()` method. `UnmodifiableHeaders` is of type `com.sun.net.httpserver.Headers` which is a public API in the `jdk.httpserver` module.
> 
> When applications call `Headers.toString()`, if the instance is of type `UnmodifiableHeaders`, then the returned `String` representation shows empty headers, even when it isn't empty. The commit in this PR fixes the issue by implementing `toString()` in the `UnmodifiableHeaders` to return the correct representation of the headers.
> 
> An existing jtreg test has been updated to reproduce this issue and verify the fix.

This pull request has now been integrated.

Changeset: 6882b381
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6882b381e8662b5c134d3a1868c357eeb3523ea8
Stats:     77 lines in 2 files changed: 64 ins; 1 del; 12 mod

8333590: UnmodifiableHeaders.toString() returns a value that represents empty headers

Reviewed-by: dfuchs, michaelm

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

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

From dfuchs at openjdk.org  Fri Jun  7 15:27:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Jun 2024 15:27:20 GMT
Subject: RFR: 8333804: java/net/httpclient/ForbiddenHeadTest.java threw an
 exception with 0 failures
Message-ID: <Di7V-0hD8E1uAkUf-ptvbiH-10NFqWq-RRKxWhnkiIk=.c6f52913-be25-4be0-9b39-28e9907e1b70@github.com>

The test failed because the shared HttpClients were not garbage collected in the imparted time.
The timeout of 500ms to wait for the clients to clean up is sufficient most of the time but rather small, I suspect a bit more time was needed in that instance.

The fix raises the timeout to 1500ms.

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

Commit messages:
 - 8333804

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

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

From jpai at openjdk.org  Fri Jun  7 15:46:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Jun 2024 15:46:12 GMT
Subject: RFR: 8333804: java/net/httpclient/ForbiddenHeadTest.java threw an
 exception with 0 failures
In-Reply-To: <Di7V-0hD8E1uAkUf-ptvbiH-10NFqWq-RRKxWhnkiIk=.c6f52913-be25-4be0-9b39-28e9907e1b70@github.com>
References: <Di7V-0hD8E1uAkUf-ptvbiH-10NFqWq-RRKxWhnkiIk=.c6f52913-be25-4be0-9b39-28e9907e1b70@github.com>
Message-ID: <b1tWrpzh4jJdm9ewhTMNOGacrWJ9HlRtZ6ZtFd4aGv4=.d2808d02-c9f0-4fae-b487-dcb94d7c6797@github.com>

On Fri, 7 Jun 2024 15:21:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test failed because the shared HttpClients were not garbage collected in the imparted time.
> The timeout of 500ms to wait for the clients to clean up is sufficient most of the time but rather small, I suspect a bit more time was needed in that instance.
> 
> The fix raises the timeout to 1500ms.

Marked as reviewed by jpai (Reviewer).

test/jdk/java/net/httpclient/ForbiddenHeadTest.java line 384:

> 382:         authClient = noAuthClient = null;
> 383:         Thread.sleep(100);
> 384:         AssertionError fail = TRACKER.check(1500);

We have other tests where we use a higher timeout like this. So I think it's OK to increase this value to try and prevent this failure.

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

PR Review: https://git.openjdk.org/jdk/pull/19600#pullrequestreview-2104889969
PR Review Comment: https://git.openjdk.org/jdk/pull/19600#discussion_r1631400098

From dholmes at openjdk.org  Mon Jun 10 02:38:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 02:38:25 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>

Sets the version to 24/24-ea and the copyright year to 2025.

Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.

This initial generation also picks up the unpublished changes from: 

- JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
- JDK-8284500: Typo in Supported Named Extensions - BasicContraints
- JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class

Thanks

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

Commit messages:
 - 8330205: Initial troff manpage generation for JDK 24

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330205
  Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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

From alanb at openjdk.org  Mon Jun 10 07:18:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:18:11 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

From dholmes at openjdk.org  Mon Jun 10 08:04:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:04:12 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
Message-ID: <G-MYWkkw506r9DLMCcme6orMWiD3hu1Wn6nRJuSIG_c=.94373b8a-b647-4e59-9a3e-053c012032aa@github.com>

On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sets the version to 24/24-ea and the copyright year to 2025.
>> 
>> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>> 
>> This initial generation also picks up the unpublished changes from: 
>> 
>> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
>> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
>> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>> 
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095

From dfuchs at openjdk.org  Mon Jun 10 12:47:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Jun 2024 12:47:16 GMT
Subject: Integrated: 8333804: java/net/httpclient/ForbiddenHeadTest.java threw
 an exception with 0 failures
In-Reply-To: <Di7V-0hD8E1uAkUf-ptvbiH-10NFqWq-RRKxWhnkiIk=.c6f52913-be25-4be0-9b39-28e9907e1b70@github.com>
References: <Di7V-0hD8E1uAkUf-ptvbiH-10NFqWq-RRKxWhnkiIk=.c6f52913-be25-4be0-9b39-28e9907e1b70@github.com>
Message-ID: <-ts_ZpDsmwnB74xIq7M6nuUgiI-pzlttds8JXTn8mds=.2d81b3ad-33e9-44a1-b167-dc20ea8ef33c@github.com>

On Fri, 7 Jun 2024 15:21:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test failed because the shared HttpClients were not garbage collected in the imparted time.
> The timeout of 500ms to wait for the clients to clean up is sufficient most of the time but rather small, I suspect a bit more time was needed in that instance.
> 
> The fix raises the timeout to 1500ms.

This pull request has now been integrated.

Changeset: ec1664e8
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec1664e8c9413890ce2dae5c2dbbce3449d67882
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333804: java/net/httpclient/ForbiddenHeadTest.java threw an exception with 0 failures

Reviewed-by: jpai

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

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

From iris at openjdk.org  Mon Jun 10 17:30:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Jun 2024 17:30:15 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696

From dholmes at openjdk.org  Tue Jun 11 00:50:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 00:50:28 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <aepA-ImIyckFwPaf4cS2pizlON3SYyrfc5BK9Y1SJwU=.50de780d-25c0-4da3-9066-52b1a472b8de@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8330205: Initial troff manpage generation for JDK 24

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

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01
  Stats: 53 lines in 28 files changed: 12 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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

From dholmes at openjdk.org  Tue Jun 11 01:02:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:02:39 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <fxPYBQ2lvXomy6ZaWwe2l7ucWeyV5Yd9dl7b7lZl5ho=.e8c4eae1-cf24-42e2-a86a-f5e3e0f6163c@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

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

  Regenerated after merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19617/files
  - new: https://git.openjdk.org/jdk/pull/19617/files/8472c47d..e7563087

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

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

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

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
Message-ID: <7aiYPjUq_qkJuy1jRAFfZTpNoCwaw9scrgKJkkbp6UA=.dcdfae3e-05c5-45af-81b4-8a434b2774ba@github.com>

On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark <iris at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).

Thanks for the review @irisclark .

I've merged in the latest updates that also brought in part of the missing changes. If anything goes wrong I have another PR in preparation that also updates java.1

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2159577044

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: Integrated: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <rZfMnH59MoMxA4EjbTMjwJ6Wv7_aU6tAALkPzROcOSM=.d0ee9e97-4348-4441-9c5c-5ab4d834e2bc@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - ~~JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC~~ (covered by merge)
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

This pull request has now been integrated.

Changeset: 3a01b47a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a01b47ac97714608356ce3faf797c37dc63e9af
Stats:     43 lines in 28 files changed: 2 ins; 3 del; 38 mod

8330205: Initial troff manpage generation for JDK 24

Reviewed-by: alanb, iris

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

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

From dfuchs at openjdk.org  Tue Jun 11 14:44:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Jun 2024 14:44:33 GMT
Subject: RFR: 8334028: HttpClient: NPE thrown from assert statement
Message-ID: <C31Qazyb5ELcCfnMQAbx4DJgoIO2o51D0X1yu3HAuzg=.150c4f52-823b-4a55-8751-8a9501f1ddd7@github.com>

The `jdk.internal.http.common.Utils` class exposes methods that work on lists or arrays of byte buffers, and tell whether or how much remaining data is present in the buffers in the list/array. These methods currently throw `NullPointerException` if the given list/buffer is null.

This is not in itself an issue, except that these methods are often called in debug statements, or in assert statements, where `null` could be passed and `NullPointerException` are not expected and should not be thrown.

One such assert statement in `ResponseSubscribers` hid a bug where a `NullPointerException` that  should have been unconditionally thrown was in fact only thrown if asserts were enabled. The test that was supposed to verify that NPEs are thrown was passing because assert are always enabled by default when running tests.

The proposed change modifies these Utils methods to allow null parameter, returning false or 0 when a null list or array is given. It also fixes the code in ResponseSunscribers that was throwing from the assert to unconditionally check for nulls before the assertion.

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

Commit messages:
 - 8334028

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

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

From dfuchs at openjdk.org  Tue Jun 11 17:12:34 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Jun 2024 17:12:34 GMT
Subject: RFR: 8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java
 timed out
Message-ID: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>

Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
The change makes sure the client connects using the loopback address instead of "localhost".

In case that does not fix the issue, some additional logging has been added to try to understand what's going on.

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

Commit messages:
 - 8299487
 - 8299487

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

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

From jpai at openjdk.org  Wed Jun 12 07:03:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 07:03:17 GMT
Subject: RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
In-Reply-To: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
Message-ID: <uxrXpedwYxrsUigez3sL3tiwZHmaUj9w8H-b72jkmfo=.640cbb5a-73d2-4866-afb4-123e51776e0e@github.com>

On Tue, 11 Jun 2024 17:07:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
> The change makes sure the client connects using the loopback address instead of "localhost".
> 
> In case that does not fix the issue, some additional logging has been added to try to understand what's going on.

The changes look OK to me. I have added a couple of trivial review comments inline.

test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java line 149:

> 147:                 }
> 148:             } catch (Throwable e) {
> 149:                 System.out.println("clientReader got exception: " + e);

Hello Daniel, I think since we are printing the stacktrace on the next line, it might be better to use `System.err.println` here so that this message to ends up in the `System.err` section like the stacktrace. Same suggestion for 2 more places in this PR where we are introducing such messages in the Throwable block.

test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java line 219:

> 217:                         os.close();
> 218:                         serverSock.close();
> 219:                         System.out.println("serverLooback exiting normally");

Typo in the message, should have been `serverLoopback ...`. Same in 1 other place.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19663#pullrequestreview-2112118704
PR Review Comment: https://git.openjdk.org/jdk/pull/19663#discussion_r1635916191
PR Review Comment: https://git.openjdk.org/jdk/pull/19663#discussion_r1635916940

From jpai at openjdk.org  Wed Jun 12 07:11:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 07:11:14 GMT
Subject: RFR: 8334028: HttpClient: NPE thrown from assert statement
In-Reply-To: <C31Qazyb5ELcCfnMQAbx4DJgoIO2o51D0X1yu3HAuzg=.150c4f52-823b-4a55-8751-8a9501f1ddd7@github.com>
References: <C31Qazyb5ELcCfnMQAbx4DJgoIO2o51D0X1yu3HAuzg=.150c4f52-823b-4a55-8751-8a9501f1ddd7@github.com>
Message-ID: <Os_G5AswQAShfFX0CYP22I56mUL5FBI4tRxi2aVe-vs=.ec874850-d881-4ecb-b86d-0b29d7a4b3f2@github.com>

On Tue, 11 Jun 2024 14:40:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `jdk.internal.http.common.Utils` class exposes methods that work on lists or arrays of byte buffers, and tell whether or how much remaining data is present in the buffers in the list/array. These methods currently throw `NullPointerException` if the given list/buffer is null.
> 
> This is not in itself an issue, except that these methods are often called in debug statements, or in assert statements, where `null` could be passed and `NullPointerException` are not expected and should not be thrown.
> 
> One such assert statement in `ResponseSubscribers` hid a bug where a `NullPointerException` that  should have been unconditionally thrown was in fact only thrown if asserts were enabled. The test that was supposed to verify that NPEs are thrown was passing because assert are always enabled by default when running tests.
> 
> The proposed change modifies these Utils methods to allow null parameter, returning false or 0 when a null list or array is given. It also fixes the code in ResponseSunscribers that was throwing from the assert to unconditionally check for nulls before the assertion.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19661#pullrequestreview-2112135753

From dfuchs at openjdk.org  Wed Jun 12 10:56:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 10:56:17 GMT
Subject: Integrated: 8334028: HttpClient: NPE thrown from assert statement
In-Reply-To: <C31Qazyb5ELcCfnMQAbx4DJgoIO2o51D0X1yu3HAuzg=.150c4f52-823b-4a55-8751-8a9501f1ddd7@github.com>
References: <C31Qazyb5ELcCfnMQAbx4DJgoIO2o51D0X1yu3HAuzg=.150c4f52-823b-4a55-8751-8a9501f1ddd7@github.com>
Message-ID: <zz204UQH9CsUlsGHwfT42GT7TT7FgXmSqPtEWgX-RZ8=.ede20436-225c-441d-bd2c-b74a1b40849e@github.com>

On Tue, 11 Jun 2024 14:40:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `jdk.internal.http.common.Utils` class exposes methods that work on lists or arrays of byte buffers, and tell whether or how much remaining data is present in the buffers in the list/array. These methods currently throw `NullPointerException` if the given list/buffer is null.
> 
> This is not in itself an issue, except that these methods are often called in debug statements, or in assert statements, where `null` could be passed and `NullPointerException` are not expected and should not be thrown.
> 
> One such assert statement in `ResponseSubscribers` hid a bug where a `NullPointerException` that  should have been unconditionally thrown was in fact only thrown if asserts were enabled. The test that was supposed to verify that NPEs are thrown was passing because assert are always enabled by default when running tests.
> 
> The proposed change modifies these Utils methods to allow null parameter, returning false or 0 when a null list or array is given. It also fixes the code in ResponseSunscribers that was throwing from the assert to unconditionally check for nulls before the assertion.

This pull request has now been integrated.

Changeset: 81ca0ece
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81ca0ece2e69477b3d22a40c51e044d56e13b6e4
Stats:     22 lines in 3 files changed: 18 ins; 0 del; 4 mod

8334028: HttpClient: NPE thrown from assert statement

Reviewed-by: jpai

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

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

From dfuchs at openjdk.org  Wed Jun 12 11:00:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 11:00:14 GMT
Subject: RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
In-Reply-To: <uxrXpedwYxrsUigez3sL3tiwZHmaUj9w8H-b72jkmfo=.640cbb5a-73d2-4866-afb4-123e51776e0e@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
 <uxrXpedwYxrsUigez3sL3tiwZHmaUj9w8H-b72jkmfo=.640cbb5a-73d2-4866-afb4-123e51776e0e@github.com>
Message-ID: <MPDzu8zFyzS50wawfsP5_YfvslCJKhVva5DN1lg6QjQ=.17d1bec2-2a98-4240-b79d-3245e341d31c@github.com>

On Wed, 12 Jun 2024 06:58:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
>> The change makes sure the client connects using the loopback address instead of "localhost".
>> 
>> In case that does not fix the issue, some additional logging has been added to try to understand what's going on.
>
> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java line 149:
> 
>> 147:                 }
>> 148:             } catch (Throwable e) {
>> 149:                 System.out.println("clientReader got exception: " + e);
> 
> Hello Daniel, I think since we are printing the stacktrace on the next line, it might be better to use `System.err.println` here so that this message to ends up in the `System.err` section like the stacktrace. Same suggestion for 2 more places in this PR where we are introducing such messages in the Throwable block.

I wanted to print this on System.out by design - to avoid the trace being lost among the many debug traces on System.err. What I'm interested mostly here is knowing whether the thread exited normally or with an error.
If you believe it's important enough I believe we could write both on System.out and System.err, but I specifically wanted it on System.out.

> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java line 219:
> 
>> 217:                         os.close();
>> 218:                         serverSock.close();
>> 219:                         System.out.println("serverLooback exiting normally");
> 
> Typo in the message, should have been `serverLoopback ...`. Same in 1 other place.

will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19663#discussion_r1636247003
PR Review Comment: https://git.openjdk.org/jdk/pull/19663#discussion_r1636247095

From dfuchs at openjdk.org  Wed Jun 12 11:33:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 11:33:43 GMT
Subject: RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out [v2]
In-Reply-To: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
Message-ID: <R8UIfWoduXJ8Z_XFZdP0ma5jp0gZ6UveaPmhW4to15M=.4d248704-3649-4b0e-a2ac-f624e0fd4467@github.com>

> Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
> The change makes sure the client connects using the loopback address instead of "localhost".
> 
> In case that does not fix the issue, some additional logging has been added to try to understand what's going on.

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

  Fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19663/files
  - new: https://git.openjdk.org/jdk/pull/19663/files/b1353b3b..30291a7d

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

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

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

From jpai at openjdk.org  Wed Jun 12 11:33:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 11:33:43 GMT
Subject: RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out [v2]
In-Reply-To: <R8UIfWoduXJ8Z_XFZdP0ma5jp0gZ6UveaPmhW4to15M=.4d248704-3649-4b0e-a2ac-f624e0fd4467@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
 <R8UIfWoduXJ8Z_XFZdP0ma5jp0gZ6UveaPmhW4to15M=.4d248704-3649-4b0e-a2ac-f624e0fd4467@github.com>
Message-ID: <8_2vumDKzKu8mSRn4B3lN-QM2YnhvSKrTBKAOMBFZdA=.a211b43c-2395-4d46-b12c-52caaf3dd0aa@github.com>

On Wed, 12 Jun 2024 11:30:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
>> The change makes sure the client connects using the loopback address instead of "localhost".
>> 
>> In case that does not fix the issue, some additional logging has been added to try to understand what's going on.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19663#pullrequestreview-2112747461

From jpai at openjdk.org  Wed Jun 12 11:33:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 11:33:44 GMT
Subject: RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out [v2]
In-Reply-To: <MPDzu8zFyzS50wawfsP5_YfvslCJKhVva5DN1lg6QjQ=.17d1bec2-2a98-4240-b79d-3245e341d31c@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
 <uxrXpedwYxrsUigez3sL3tiwZHmaUj9w8H-b72jkmfo=.640cbb5a-73d2-4866-afb4-123e51776e0e@github.com>
 <MPDzu8zFyzS50wawfsP5_YfvslCJKhVva5DN1lg6QjQ=.17d1bec2-2a98-4240-b79d-3245e341d31c@github.com>
Message-ID: <fbmLHGy0w2PnbsIDfTZIHOtoEJn4sovClEM4OISiY4w=.47fb0b0e-ca62-43d8-ada5-1ae952090cf8@github.com>

On Wed, 12 Jun 2024 10:56:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If you believe it's important enough I believe we could write both on System.out and System.err, but I specifically wanted it on System.out.

The current way you have it is fine. I didn't know the use of `System.out` was intentional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19663#discussion_r1636298645

From dfuchs at openjdk.org  Wed Jun 12 11:33:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 11:33:44 GMT
Subject: Integrated: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
In-Reply-To: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
References: <mkvDx1uP05tG10H1hNwVavGzfbeAfXVT2p864fFntxI=.d528cb30-bd81-4a5d-a07a-b0b354500b76@github.com>
Message-ID: <nWaG6GaPdVCv1oaMhS6NpScG1IvR8t6Uat7OH8vYKuk=.b83e348e-0469-46dd-abb4-20bc2b45722f@github.com>

On Tue, 11 Jun 2024 17:07:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Here is a trivial change that might fix intermittent failures in the test java/net/httpclient/whitebox/SSLTubeTestDriver.java.
> The change makes sure the client connects using the loopback address instead of "localhost".
> 
> In case that does not fix the issue, some additional logging has been added to try to understand what's going on.

This pull request has now been integrated.

Changeset: 81083a0e
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81083a0e10d9c92f5247ae256e170709014b596b
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out

Reviewed-by: jpai

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

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

From clanger at openjdk.org  Thu Jun 13 10:06:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 10:06:38 GMT
Subject: RFR: 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java
 fails: read times out
Message-ID: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>

The issue seems to be not reproducable. We've run the test now for a while in SAP's nightlies but it didn't reoccur. So let's remove the exclusion.

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

Commit messages:
 - JDK-8211854

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

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

From dfuchs at openjdk.org  Thu Jun 13 11:31:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Jun 2024 11:31:11 GMT
Subject: RFR: 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java
 fails: read times out
In-Reply-To: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
References: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
Message-ID: <EfZCTW8-v3lhPIKnmGEd84NBFLr58BgizhgzAV-Dfhg=.d4b40f07-08d1-41a7-8ae2-e56fad38d0e1@github.com>

On Thu, 13 Jun 2024 09:55:05 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The issue seems to be not reproducable. We've run the test now for a while in SAP's nightlies but it didn't reoccur. So let's remove the exclusion.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19692#pullrequestreview-2115520264

From jpai at openjdk.org  Thu Jun 13 12:03:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 12:03:11 GMT
Subject: RFR: 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java
 fails: read times out
In-Reply-To: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
References: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
Message-ID: <OzJB9HcDudK_UdAfBVTnOxtNGFprNhA6kTod3_UhaJc=.7b368640-6222-4c0c-8f59-5f2710217131@github.com>

On Thu, 13 Jun 2024 09:55:05 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The issue seems to be not reproducable. We've run the test now for a while in SAP's nightlies but it didn't reoccur. So let's remove the exclusion.

Removal from problem listing on AIX. Looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19692#pullrequestreview-2115584190

From clanger at openjdk.org  Thu Jun 13 13:19:18 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:19:18 GMT
Subject: RFR: 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java
 fails: read times out
In-Reply-To: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
References: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
Message-ID: <EUsS6uvUtcWWB2_c0VgYOftQ6E1OqvF8h0_K_c2OebQ=.bbeef8c8-6b0d-419b-a461-2286e099fd62@github.com>

On Thu, 13 Jun 2024 09:55:05 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The issue seems to be not reproducable. We've run the test now for a while in SAP's nightlies but it didn't reoccur. So let's remove the exclusion.

Thanks for the reviews. As it is a trivial fix of a test listing, I integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/19692#issuecomment-2165641963

From clanger at openjdk.org  Thu Jun 13 13:19:18 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:19:18 GMT
Subject: Integrated: 8211854: [aix]
 java/net/ServerSocket/AcceptInheritHandle.java fails: read times out
In-Reply-To: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
References: <o6iLSWAnVo2WMd1V5Hzo5nCcdLc_1MONi0Ne467_v-4=.9b890f85-3442-451d-949e-c13e325e4dfe@github.com>
Message-ID: <iKeF4vOpUnrGM8KiUb_f4ucPfhzCE8aCBdYtyKm3XJo=.b3448398-4d2c-4a0b-8d81-3acbbd12ef43@github.com>

On Thu, 13 Jun 2024 09:55:05 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The issue seems to be not reproducable. We've run the test now for a while in SAP's nightlies but it didn't reoccur. So let's remove the exclusion.

This pull request has now been integrated.

Changeset: 9d8439c1
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d8439c10780c3a0169c2675955a0506518f44fb
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fails: read times out

Reviewed-by: dfuchs, jpai

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

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

From duke at openjdk.org  Fri Jun 14 02:57:15 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 14 Jun 2024 02:57:15 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <LrfAgU6LO1TPTnym_Q31Ah713eUl2TBpLOPqLVcAW7A=.a3dd6f1d-0085-4701-b575-4b5f1d62f52b@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

Are we not going to do anything with this?

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2167118806

From dfuchs at openjdk.org  Fri Jun 14 09:37:31 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 09:37:31 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <LrfAgU6LO1TPTnym_Q31Ah713eUl2TBpLOPqLVcAW7A=.a3dd6f1d-0085-4701-b575-4b5f1d62f52b@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <LrfAgU6LO1TPTnym_Q31Ah713eUl2TBpLOPqLVcAW7A=.a3dd6f1d-0085-4701-b575-4b5f1d62f52b@github.com>
Message-ID: <mBK8pVCs7RJ7LH_kdX0XkCt_oJE-0aVkVlEfqMytn_g=.af166ab6-ac7e-4845-835c-9a24c95e9308@github.com>

On Fri, 14 Jun 2024 02:54:53 GMT, robert engels <duke at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>>    
>>    # Conflicts:
>>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>  - update api changes based on comments
>
> Are we not going to do anything with this?

@robaho Thanks for restarting the discussion. IMO the two constants are OK, but I don't think the new proposed methods have  gathered sufficient consensus to go in in this form yet.

Maybe we should brainstorm a bit more. For instance - we could rename the second parameter to sendResponseHeaders, and possibly rework the API documentation of that method.


public void sendResponseHeaders(int rCode, long lengthOrChunked);


then add 


public void sendHeadersForChunkedResponse(int rcode) {
    sendResponseHeaders(rCode, 0);
}

public void sendHeadersForFixedLengthResponse(int rcode, int responseLength) {
     if (responseLength < 0) throw new IllegalArgumentException("negative length: " + responseLength);
     sendResponseHeaders(rCode, responseLength == 0 ? -1 : responseLength);
}
 ``` 
 
 and:

-  add `@see` in `sendResponseHeaders` to link to the two new methods
- add an `@apiNote` to `sendResponseHeaders` to stress that using the other two methods is preferred.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2167640579

From dfuchs at openjdk.org  Fri Jun 14 09:42:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 09:42:24 GMT
Subject: [jdk23] RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
Message-ID: <_VsZ3UkwyvS3O3O72S9w1J0LoDlkzv98-xgga0rb6W8=.e11c8333-0243-4ea7-9712-d62e8c164106@github.com>

Clean backport of a small test fix that should avoid some intermittent failures in the CI.

The mainline fix PR can be seen here: PR: https://git.openjdk.org/jdk/pull/19663

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

Commit messages:
 - Backport 81083a0e10d9c92f5247ae256e170709014b596b

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

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

From michaelm at openjdk.org  Fri Jun 14 10:32:28 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 14 Jun 2024 10:32:28 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <82KcjG0hujbQYI7jFmJfdND3uc5Ny6mcgdtsIG1tPa4=.5d6f004f-1384-4121-90f2-958e2c0d770b@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

I think the more minimal the change, the better for this PR. The discussion generally has widened to something more suited to a small JEP on how to take the API forward at a higher level. I think I'd be happiest at this point with just the two constants defined and some adjustment to the apidoc for sendResponseHeaders() including this:


If {@literal == CHUNKED_CONTENT}, then chunked encoding is used,
and an arbitrary number of bytes may be written.
If {@literal == NO_CONTENT or < -1}, then no response body length is
specified and no response body may be written.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2167734290

From duke at openjdk.org  Sat Jun 15 03:25:19 2024
From: duke at openjdk.org (Ethan McCue)
Date: Sat, 15 Jun 2024 03:25:19 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

To reiterate, I'm still not the biggest fan of the constant names given

* The parameter name they are being used for is `responseLength`. "The responseLength is CHUNKED_CONTENT" feels jank and `lengthOrChunked` doesn't inspire joy.
* I'm not convinced the audience that we presumably care the most about for this API won't be helped too much by them

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2169078030

From duke at openjdk.org  Sat Jun 15 03:36:19 2024
From: duke at openjdk.org (robert engels)
Date: Sat, 15 Jun 2024 03:36:19 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <0rXb9OpJzp4KcOVkz3X0EucC45jQT8P2qTuHj8AWVFY=.e3307268-e61b-4480-b9ac-133e248f5348@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

Can we ask ?do these changes make things better?? I think they do. They?re not perfect - the additional methods would be much better.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2169080833

From clanger at openjdk.org  Mon Jun 17 08:34:39 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 08:34:39 GMT
Subject: [jdk23] RFR: 8211854: [aix]
 java/net/ServerSocket/AcceptInheritHandle.java fails: read times out
Message-ID: <Yl7sQWBMU2YkpO4_qlvSHNqtXqKh6RXJNx04E4igYv0=.2add3e8e-bb26-44fb-bb3a-3872222c82da@github.com>

Hi all,

This pull request contains a backport of [JDK-8211854](https://bugs.openjdk.org/browse/JDK-8211854), commit [9d8439c1](https://github.com/openjdk/jdk/commit/9d8439c10780c3a0169c2675955a0506518f44fb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Daniel Fuchs and Jaikiran Pai.

Thanks!

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

Commit messages:
 - Backport 9d8439c10780c3a0169c2675955a0506518f44fb

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

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

From mbaesken at openjdk.org  Mon Jun 17 10:25:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Jun 2024 10:25:22 GMT
Subject: [jdk23] RFR: 8211854: [aix]
 java/net/ServerSocket/AcceptInheritHandle.java fails: read times out
In-Reply-To: <Yl7sQWBMU2YkpO4_qlvSHNqtXqKh6RXJNx04E4igYv0=.2add3e8e-bb26-44fb-bb3a-3872222c82da@github.com>
References: <Yl7sQWBMU2YkpO4_qlvSHNqtXqKh6RXJNx04E4igYv0=.2add3e8e-bb26-44fb-bb3a-3872222c82da@github.com>
Message-ID: <NQyi9-KtKPWdSY00U-CsPvwWo3HxDMwsAjtaNA42eV4=.ef864072-0637-4b0d-9ec0-211a310b579b@github.com>

On Mon, 17 Jun 2024 08:28:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8211854](https://bugs.openjdk.org/browse/JDK-8211854), commit [9d8439c1](https://github.com/openjdk/jdk/commit/9d8439c10780c3a0169c2675955a0506518f44fb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Daniel Fuchs and Jaikiran Pai.
> 
> Thanks!

Looks okay, but please reconsider the description text of the bug, is it still what you do?

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19743#pullrequestreview-2122517123

From clanger at openjdk.org  Mon Jun 17 12:22:19 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 12:22:19 GMT
Subject: [jdk23] Integrated: 8211854: [aix]
 java/net/ServerSocket/AcceptInheritHandle.java fails: read times out
In-Reply-To: <Yl7sQWBMU2YkpO4_qlvSHNqtXqKh6RXJNx04E4igYv0=.2add3e8e-bb26-44fb-bb3a-3872222c82da@github.com>
References: <Yl7sQWBMU2YkpO4_qlvSHNqtXqKh6RXJNx04E4igYv0=.2add3e8e-bb26-44fb-bb3a-3872222c82da@github.com>
Message-ID: <MemCS_CDKP07ByvOjegE0KgQ5quPfA67FN5vXUX0s4M=.3ff6253c-7989-4ce2-9a00-fcbdd36759e9@github.com>

On Mon, 17 Jun 2024 08:28:23 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8211854](https://bugs.openjdk.org/browse/JDK-8211854), commit [9d8439c1](https://github.com/openjdk/jdk/commit/9d8439c10780c3a0169c2675955a0506518f44fb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Daniel Fuchs and Jaikiran Pai.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cb3c45a6
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb3c45a698ccd7f61f707fa3066b9155769f4f73
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fails: read times out

Reviewed-by: mbaesken
Backport-of: 9d8439c10780c3a0169c2675955a0506518f44fb

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

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

From dfuchs at openjdk.org  Mon Jun 17 14:55:34 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 14:55:34 GMT
Subject: [jdk23] RFR: 8333804: java/net/httpclient/ForbiddenHeadTest.java threw
 an exception with 0 failures
Message-ID: <HKRr9a1MA7n00XwHKzB_LDO3XcSytZzJGPW2-YnMrzE=.3a73cf78-73bf-4e83-9178-43f961a34a77@github.com>

This is a trivial one liner bug fix in a test class to improve test stability. The backport is a clean backport.

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

Commit messages:
 - Backport ec1664e8c9413890ce2dae5c2dbbce3449d67882

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

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

From jpai at openjdk.org  Mon Jun 17 15:35:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Jun 2024 15:35:11 GMT
Subject: [jdk23] RFR: 8333804: java/net/httpclient/ForbiddenHeadTest.java
 threw an exception with 0 failures
In-Reply-To: <HKRr9a1MA7n00XwHKzB_LDO3XcSytZzJGPW2-YnMrzE=.3a73cf78-73bf-4e83-9178-43f961a34a77@github.com>
References: <HKRr9a1MA7n00XwHKzB_LDO3XcSytZzJGPW2-YnMrzE=.3a73cf78-73bf-4e83-9178-43f961a34a77@github.com>
Message-ID: <Z_a7GOzwL_gVAIFTMBOllGNRwfpXLyP1GJmNUmWgfak=.e25d1ca9-483b-4d70-886c-c97b498f78c5@github.com>

On Mon, 17 Jun 2024 14:50:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a trivial one liner bug fix in a test class to improve test stability. The backport is a clean backport.

test-only change and a clean backport. Looks good to me for 23.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19751#pullrequestreview-2123232009

From jpai at openjdk.org  Mon Jun 17 16:02:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Jun 2024 16:02:12 GMT
Subject: [jdk23] RFR: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
In-Reply-To: <_VsZ3UkwyvS3O3O72S9w1J0LoDlkzv98-xgga0rb6W8=.e11c8333-0243-4ea7-9712-d62e8c164106@github.com>
References: <_VsZ3UkwyvS3O3O72S9w1J0LoDlkzv98-xgga0rb6W8=.e11c8333-0243-4ea7-9712-d62e8c164106@github.com>
Message-ID: <xsVPMvDyajtonx9RpFVbqLvOj0tn6BvOnNtPtm6DeDI=.85018474-7484-4c9c-818b-e704499d911d@github.com>

On Fri, 14 Jun 2024 09:37:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Clean backport of a small test fix that should avoid some intermittent failures in the CI.
> 
> The mainline fix PR can be seen here: PR: https://git.openjdk.org/jdk/pull/19663

test-only change and a clean backport. Looks good to me for 23.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19717#pullrequestreview-2123305168

From dfuchs at openjdk.org  Mon Jun 17 16:06:22 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 16:06:22 GMT
Subject: [jdk23] Integrated: 8299487: Test
 java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
In-Reply-To: <_VsZ3UkwyvS3O3O72S9w1J0LoDlkzv98-xgga0rb6W8=.e11c8333-0243-4ea7-9712-d62e8c164106@github.com>
References: <_VsZ3UkwyvS3O3O72S9w1J0LoDlkzv98-xgga0rb6W8=.e11c8333-0243-4ea7-9712-d62e8c164106@github.com>
Message-ID: <Oar-6plm97P4CYTIIO7xAUWOEswRVxLm6g9hYHFOSvg=.e3622724-1323-482b-af12-daa7a4e9ad1d@github.com>

On Fri, 14 Jun 2024 09:37:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Clean backport of a small test fix that should avoid some intermittent failures in the CI.
> 
> The mainline fix PR can be seen here: PR: https://git.openjdk.org/jdk/pull/19663

This pull request has now been integrated.

Changeset: 86fcbe09
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86fcbe09f87a9e255671e7b230598a3783becf29
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out

Reviewed-by: jpai
Backport-of: 81083a0e10d9c92f5247ae256e170709014b596b

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

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

From dfuchs at openjdk.org  Tue Jun 18 18:49:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 18:49:18 GMT
Subject: [jdk23] Integrated: 8333804:
 java/net/httpclient/ForbiddenHeadTest.java threw an exception with 0 failures
In-Reply-To: <HKRr9a1MA7n00XwHKzB_LDO3XcSytZzJGPW2-YnMrzE=.3a73cf78-73bf-4e83-9178-43f961a34a77@github.com>
References: <HKRr9a1MA7n00XwHKzB_LDO3XcSytZzJGPW2-YnMrzE=.3a73cf78-73bf-4e83-9178-43f961a34a77@github.com>
Message-ID: <0rLtl4av6nSBGPmSU_r39kDKISmW1BWehPX4SxL7kcQ=.bdea4cb6-52ad-4ea4-aa38-059b2ef938f6@github.com>

On Mon, 17 Jun 2024 14:50:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a trivial one liner bug fix in a test class to improve test stability. The backport is a clean backport.

This pull request has now been integrated.

Changeset: b21d7b23
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b21d7b23c1e01d034d109d2e8b61d11fab01cd14
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333804: java/net/httpclient/ForbiddenHeadTest.java threw an exception with 0 failures

Reviewed-by: jpai
Backport-of: ec1664e8c9413890ce2dae5c2dbbce3449d67882

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

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

From michaelm at openjdk.org  Thu Jun 20 09:18:16 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 20 Jun 2024 09:18:16 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>
Message-ID: <BDTv8Db8G0ZdtOyuH9p6g2Q59iIhNw1Cp6ukx3II5fQ=.4d1dab2f-dc64-4459-bd70-008ca1830b5d@github.com>

On Sat, 15 Jun 2024 03:22:47 GMT, Ethan McCue <duke at openjdk.org> wrote:

> To reiterate, I'm still not the biggest fan of the constant names given
> 
>     * The parameter name they are being used for is `responseLength`. "The responseLength is CHUNKED_CONTENT" feels jank and `lengthOrChunked` doesn't inspire joy.
> 
>     * I'm not convinced the audience that we presumably care the most about for this API won't be helped too much by them

There's nothing we can do about the fact that what is a 'length' parameter also conveys the usage of content encoding. I think the biggest win this change can achieve (for the least impact) is to reduce the easy to make error of using the value `0` to mean zero length. I agree it's not ideal that the constants have CONTENT in their name. But, the alternative of using something like LENGTH would see us define a constant like this `public static final int ZERO_LENGTH = -1;` which would provoke even more confusion (if not worse) imo.

I suggest we stick with the constant names but refer to them explicitly in the apidoc for sendResponseHeaders along the lines I suggested above.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180206341

From michaelm at openjdk.org  Thu Jun 20 09:30:16 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 20 Jun 2024 09:30:16 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>
Message-ID: <boTCFIY-qmHz9bUtrb8N3xXYvapQrsw6RPDcAjtiPlw=.48f204a6-aae8-48c3-9ef3-75df1450f75f@github.com>

On Sat, 15 Jun 2024 03:22:47 GMT, Ethan McCue <duke at openjdk.org> wrote:

> To reiterate, I'm still not the biggest fan of the constant names given
> 
>     * The parameter name they are being used for is `responseLength`. "The responseLength is CHUNKED_CONTENT" feels jank and `lengthOrChunked` doesn't inspire joy.
> 
>     * I'm not convinced the audience that we presumably care the most about for this API won't be helped too much by them

I posted a response to this and then deleted it because I hadn't considered your suggestion of changing the parameter name.

I think the biggest win this change can achieve (for the least impact) is to reduce the easy to make error of using the value 0 to mean zero length. I agree it's not ideal that the constants have CONTENT in their name. But, the alternative of using something like LENGTH would see us define a constant like this public static final int ZERO_LENGTH = -1; which would provoke even more confusion (if not worse) imo.

I suggest we stick with the constant names but refer to them explicitly in the apidoc for sendResponseHeaders along the lines I suggested above. But, also change the name of the parameter from `responseLength` to something more generic like `responseBody`. That would force the developer to read further to learn that values > 0 mean an explicit number of bytes but there are two additional symbolic values which denote no content, and chunked content.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180230303

From duke at openjdk.org  Thu Jun 20 14:39:16 2024
From: duke at openjdk.org (Ethan McCue)
Date: Thu, 20 Jun 2024 14:39:16 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <0rXb9OpJzp4KcOVkz3X0EucC45jQT8P2qTuHj8AWVFY=.e3307268-e61b-4480-b9ac-133e248f5348@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <0rXb9OpJzp4KcOVkz3X0EucC45jQT8P2qTuHj8AWVFY=.e3307268-e61b-4480-b9ac-133e248f5348@github.com>
Message-ID: <Y2WDpQlMQXhR2o_2c1x8zj7np-Fr9tgrM2uxSnrXBFs=.9566d5b5-079a-41f6-8d57-8fa92db9731f@github.com>

On Sat, 15 Jun 2024 03:33:23 GMT, robert engels <duke at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>>    
>>    # Conflicts:
>>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>  - update api changes based on comments
>
> Can we ask ?do these changes make things better?? I think they do. They?re not perfect - the additional methods would be much better.

@robaho  I think it makes the API very _slightly_ better, but in a way that would detract from future attempts to make the API holistically better to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180871759

From duke at openjdk.org  Thu Jun 20 15:08:12 2024
From: duke at openjdk.org (Ethan McCue)
Date: Thu, 20 Jun 2024 15:08:12 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <boTCFIY-qmHz9bUtrb8N3xXYvapQrsw6RPDcAjtiPlw=.48f204a6-aae8-48c3-9ef3-75df1450f75f@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <nmkjoWM9wabWylqlU0DyI2ib1s7JpnTIaDVyTkLCDLk=.ea4415b1-fae9-4f7d-adfc-3d3d99cb6b3f@github.com>
 <boTCFIY-qmHz9bUtrb8N3xXYvapQrsw6RPDcAjtiPlw=.48f204a6-aae8-48c3-9ef3-75df1450f75f@github.com>
Message-ID: <nIRGQSDn8uVotbwmnefzhB7W4TWbqA-f85sQKenuY1A=.f6d048ad-4ac7-41e8-8c29-d9fe02bfcab9@github.com>

On Thu, 20 Jun 2024 09:27:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> That would force the developer to read further

@Michael-Mc-Mahon I don't think any force in this life or the next will force a developer to read.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180930937

From duke at openjdk.org  Thu Jun 20 15:08:13 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 20 Jun 2024 15:08:13 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <0rXb9OpJzp4KcOVkz3X0EucC45jQT8P2qTuHj8AWVFY=.e3307268-e61b-4480-b9ac-133e248f5348@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
 <0rXb9OpJzp4KcOVkz3X0EucC45jQT8P2qTuHj8AWVFY=.e3307268-e61b-4480-b9ac-133e248f5348@github.com>
Message-ID: <R1ctrxqu17pVu9nflQ8wZ7tzGFFiUUDUea8pTAIAW1s=.7c595bbd-adbf-4be4-a21b-e018278c21d8@github.com>

On Sat, 15 Jun 2024 03:33:23 GMT, robert engels <duke at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>>    
>>    # Conflicts:
>>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>  - update api changes based on comments
>
> Can we ask ?do these changes make things better?? I think they do. They?re not perfect - the additional methods would be much better.

> @robaho I think it makes the API very _slightly_ better, but in a way that would detract from future attempts to make the API holistically better to use.

How does it detract from future attempts exactly? It is only adding some constants. If you remove the method, you can remove the constants. If you add additional methods as I proposed the constants can stay and be deprecated, just as we would deprecate the old method. I am not following your reasoning.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180934442

From duke at openjdk.org  Thu Jun 20 15:16:13 2024
From: duke at openjdk.org (Ethan McCue)
Date: Thu, 20 Jun 2024 15:16:13 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <-Tv4p1chl2kUGpWRiCG0h2GUf4lFK5bOiH3hnQmComc=.5e17ac9d-fcf2-43b2-890b-cad8bddb53f8@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

My reasoning is as follows

* Once we add something, we can't remove it. Even if we deprecate it, it will still be there
* The ideal API, in my head, is something like the following


exchange.sendResponseHeaders(200, ResponseLength.unknown());
exchange.sendResponseHeaders(200, ResponseLength.known(0));
exchange.sendResponseHeaders(200, ResponseLength.known(body.length));

exchange.sendResponse(200, Body.of("Hello, world"));


* That API, specifically `Body.of`, would be more naturally tempting to use.
* If we have `ResponseLength.unknown()` and `ResponseLength.known(0)` as options, the constants are redundant
* The constants do not address the case of "you get an arbitrarily sized bit of data, send it". People still need to do `thing.length == 0 ? -1 : thing.length` checks.
* Why would we add something that could be deprecated if we just found the time to reach consensus on the direction of the API?

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180951549

From duke at openjdk.org  Thu Jun 20 15:29:12 2024
From: duke at openjdk.org (Ethan McCue)
Date: Thu, 20 Jun 2024 15:29:12 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <1bgfp-kR8MuGKmxEhlkQbkniAyTnsZ92iOWQEMoFIZI=.ae92fcc4-7e89-43d9-b028-5194273b5b76@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

Maybe it will be a bit easier if we talk about some concrete use cases

## You want to send a response with zero body and you know it up front.

### Without constants


exchange.sendResponseHeaders(200, -1);


### With constants


exchange.sendResponseHeaders(200, HttpExchange.NO_CONTENT);


### With a class to hold the response length


exchange.sendResponseHeaders(200, ResponseLength.known(0));


### With a body abstraction


exchange.sendResponse(200, Body.empty());


## You want to send a response and you can compute the response length, but you don't know it up front and it could be zero

### Without constants


exchange.sendResponseHeaders(200, bytes.length == 0 ? -1 : bytes.length);
try (var body = exchange.getResponseBody) {
    body.write(bytes);
}


### With constants


exchange.sendResponseHeaders(200, bytes.length == 0 ? HttpExchange.NO_CONTENT : bytes.length);
try (var body = exchange.getResponseBody) {
    body.write(bytes);
}


### With a class to hold the response length


exchange.sendResponseHeaders(200, ResponseLength.known(bytes.length));
try (var body = exchange.getResponseBody) {
    body.write(bytes);
}


### With a body abstraction


exchange.sendResponse(200, Body.of(bytes));


## You want to send a response and you cannot compute the response length up front

### Without constants


exchange.sendResponseHeaders(200, 0);
try (var body = exchange.getResponseBody) {
    inputStream.transferTo(body);
}


### With constants


exchange.sendResponseHeaders(200, HttpExchange.CHUNKED_CONTENT);
try (var body = exchange.getResponseBody) {
    inputStream.transferTo(body);
}


### With a class to hold the response length


exchange.sendResponseHeaders(200, ResponseLength.unknown());
try (var body = exchange.getResponseBody) {
    inputStream.transferTo(body);
}


### With a body abstraction


exchange.sendResponse(200, Body.of(inputStream));

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2180978541

From duke at openjdk.org  Thu Jun 20 15:45:14 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 20 Jun 2024 15:45:14 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <vnvu88RmoXSXIuIVCVl5huXdyq466jMH7RzblSXrwD8=.289019cd-369d-4913-8c5b-1b168c2e9e29@github.com>
Message-ID: <hsFkPN9jsdncGNFLTcGY7wBdt9ywgEKXEdstvSC4s-Y=.0ca293e1-af01-43dc-a259-f49930ef6f87@github.com>

On Wed, 1 May 2024 21:12:05 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'robaho/HttpExchange-api-change' into HttpExchange-api-change
>    
>    # Conflicts:
>    #	src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>  - update api changes based on comments

> My reasoning is as follows
> 
> * Once we add something, we can't remove it. Even if we deprecate it, it will still be there
> * The ideal API, in my head, is something like the following
> 
> ```java
> exchange.sendResponseHeaders(200, ResponseLength.unknown());
> exchange.sendResponseHeaders(200, ResponseLength.known(0));
> exchange.sendResponseHeaders(200, ResponseLength.known(body.length));
> 
> exchange.sendResponse(200, Body.of("Hello, world"));
> ```
> 
>  * That API, specifically `Body.of`, would be more naturally tempting to use.
> * If we have `ResponseLength.unknown()` and `ResponseLength.known(0)` as options, the constants are redundant
> * The constants do not address the case of "you get an arbitrarily sized bit of data, send it". People still need to do `thing.length == 0 ? -1 : thing.length` checks.
> * Why would we add something that could be deprecated if we just found the time to reach consensus on the direction of the API?

My thoughts are those api methods are not as good as:


sendResponseUnknown(int code)
sendResponseFixed()
sendResponseNoContent()


To your point about getting developers to read, why make everyone go one level deeper?


You could also have,


sendResponse(int code,Body object)


that could delegate to the proper header methods, and send the Body. Technically, the additional response header methods are not needed only this one with a proper Body interface.

That would be ideal in my opinion.

I was trying to go down that route, but then some people complained that the changes were too involved, needed extended review, etc. so the CONSTANTS were chosen under the idea that it does make things more readable now, with little downside for later. Maybe the real issue, is that it takes too much effort to make fairly trivial (and analogous to existing ones) api changes?

Anyway, this seems to be right back where it started, so I will let the powers that be decide what to do, but I get the feeling it will be nothing. Not that that isn't often the best option - but I don't think that's the case here.

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

PR Comment: https://git.openjdk.org/jdk/pull/18955#issuecomment-2181012301

From dfuchs at openjdk.org  Tue Jun 25 13:27:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Jun 2024 13:27:23 GMT
Subject: RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java fails
 on linux-aarch64
Message-ID: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>

Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.

The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.

The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).

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

Commit messages:
 - 8334600

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

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

From alanb at openjdk.org  Wed Jun 26 08:28:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 08:28:11 GMT
Subject: RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
In-Reply-To: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
References: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
Message-ID: <Uq6IBMt0GCEAr0JuS5Mj1Gf2eeyVANg91VnjBdKJceI=.dc7b5fd9-6413-461b-bd09-765cd53de3be@github.com>

On Tue, 25 Jun 2024 13:22:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.
> 
> The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.
> 
> The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19881#pullrequestreview-2141093166

From dfuchs at openjdk.org  Wed Jun 26 10:12:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 10:12:13 GMT
Subject: Integrated: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
In-Reply-To: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
References: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
Message-ID: <-ULNZsJ766ho2szY6aMTiu4d0hTSDrV9mXVtKElN8uo=.ed4f1d7d-af33-4fa9-b1aa-41ccc3cc69bf@github.com>

On Tue, 25 Jun 2024 13:22:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.
> 
> The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.
> 
> The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).

This pull request has now been integrated.

Changeset: f23295ec
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625
Stats:     25 lines in 1 file changed: 16 ins; 0 del; 9 mod

8334600: TEST java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64

Reviewed-by: alanb

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

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

From djelinski at openjdk.org  Wed Jun 26 17:07:33 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 26 Jun 2024 17:07:33 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
Message-ID: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>

Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.

In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.

The included test fails without the change, passes with it.
The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
Unknown length responses that are terminated by EOF continue to work.

2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

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

Commit messages:
 - Fix KeepAliveStream test
 - Fix BasicTest4
 - Throw an exception on premature EOF

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

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

From jpai at openjdk.org  Thu Jun 27 05:09:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 05:09:09 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
Message-ID: <0SeG4zIVYO3GSM65IVhoSB26U7ox1mAtzM17a03FoKU=.825f7e85-3d21-418c-b383-ccc21e8cb94b@github.com>

On Wed, 26 Jun 2024 14:35:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
> 
> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
> 
> The included test fails without the change, passes with it.
> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
> Unknown length responses that are terminated by EOF continue to work.
> 
> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

src/java.base/share/classes/sun/net/www/MeteredStream.java line 58:

> 56:         if (n == -1) {
> 57:             if (expected > count) {
> 58:                 throw new IOException("Premature EOF");

Hello Daniel, should we instead throw `java.io.EOFException` which is much more precise than a generic `IOException`? `EOFException` states:


 * Signals that an end of file or end of stream has been reached
 * unexpectedly during input.

which I think accurately depicts what's happening here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19909#discussion_r1656418442

From djelinski at openjdk.org  Thu Jun 27 05:15:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Jun 2024 05:15:09 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <0SeG4zIVYO3GSM65IVhoSB26U7ox1mAtzM17a03FoKU=.825f7e85-3d21-418c-b383-ccc21e8cb94b@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
 <0SeG4zIVYO3GSM65IVhoSB26U7ox1mAtzM17a03FoKU=.825f7e85-3d21-418c-b383-ccc21e8cb94b@github.com>
Message-ID: <Fy9K1UKqUoxRi6B9bOUYb1voMqEofnuDAKUwKqcZJzg=.826b2d0a-5746-4de2-a1fd-94b9437f5886@github.com>

On Thu, 27 Jun 2024 05:06:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
>> 
>> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
>> 
>> The included test fails without the change, passes with it.
>> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
>> Unknown length responses that are terminated by EOF continue to work.
>> 
>> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.
>
> src/java.base/share/classes/sun/net/www/MeteredStream.java line 58:
> 
>> 56:         if (n == -1) {
>> 57:             if (expected > count) {
>> 58:                 throw new IOException("Premature EOF");
> 
> Hello Daniel, should we instead throw `java.io.EOFException` which is much more precise than a generic `IOException`? `EOFException` states:
> 
> 
>  * Signals that an end of file or end of stream has been reached
>  * unexpectedly during input.
> 
> which I think accurately depicts what's happening here.

Hi Jaikiran, I used IOException because that's already used by the ChunkedInputStream:

https://github.com/openjdk/jdk/blob/409a3fe601c61451e36554d57f29e661fe16058a/src/java.base/share/classes/sun/net/www/http/ChunkedInputStream.java#L257

No code in sun.net uses EOFException today. I suppose I could change that, but it might require changes in more places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19909#discussion_r1656424221

From jpai at openjdk.org  Thu Jun 27 05:32:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 05:32:09 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <Fy9K1UKqUoxRi6B9bOUYb1voMqEofnuDAKUwKqcZJzg=.826b2d0a-5746-4de2-a1fd-94b9437f5886@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
 <0SeG4zIVYO3GSM65IVhoSB26U7ox1mAtzM17a03FoKU=.825f7e85-3d21-418c-b383-ccc21e8cb94b@github.com>
 <Fy9K1UKqUoxRi6B9bOUYb1voMqEofnuDAKUwKqcZJzg=.826b2d0a-5746-4de2-a1fd-94b9437f5886@github.com>
Message-ID: <TSQUbZrtY8CIzKFncZEV7_cnIQ2o8c-D1-mYdGfwusU=.1c7051be-5ddb-448a-94d6-424087568675@github.com>

On Thu, 27 Jun 2024 05:12:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/MeteredStream.java line 58:
>> 
>>> 56:         if (n == -1) {
>>> 57:             if (expected > count) {
>>> 58:                 throw new IOException("Premature EOF");
>> 
>> Hello Daniel, should we instead throw `java.io.EOFException` which is much more precise than a generic `IOException`? `EOFException` states:
>> 
>> 
>>  * Signals that an end of file or end of stream has been reached
>>  * unexpectedly during input.
>> 
>> which I think accurately depicts what's happening here.
>
> Hi Jaikiran, I used IOException because that's already used by the ChunkedInputStream:
> 
> https://github.com/openjdk/jdk/blob/409a3fe601c61451e36554d57f29e661fe16058a/src/java.base/share/classes/sun/net/www/http/ChunkedInputStream.java#L257
> 
> No code in sun.net uses EOFException today. I suppose I could change that, but it might require changes in more places.

EOFException is an IOException too, so I think it would be OK to change them to throw this specific exception.

For this current PR, i think it's OK to use the IOException since like you note it maintains consistency with the other places. We can think of changing these relevant places to use EOFException as a separate task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19909#discussion_r1656452536

From dfuchs at openjdk.org  Thu Jun 27 06:59:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Jun 2024 06:59:15 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
Message-ID: <g5Y7t8Ha1j_GCWvbFvhPlTFuqq17KisiQeJyXjm51NY=.a46307e1-c667-453c-8b6c-ef1161731af2@github.com>

On Wed, 26 Jun 2024 14:35:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
> 
> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
> 
> The included test fails without the change, passes with it.
> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
> Unknown length responses that are terminated by EOF continue to work.
> 
> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

If the test is stable, this looks reasonable to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19909#pullrequestreview-2144415777

From duke at openjdk.org  Thu Jun 27 12:56:12 2024
From: duke at openjdk.org (Karan Kumar)
Date: Thu, 27 Jun 2024 12:56:12 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
Message-ID: <srA8IWcDk5XxFlgB7OOaAk5C3fGpPVMFmpEqwOVtxNo=.8d05cc23-4212-4553-b2e4-c40fb73940bf@github.com>

On Wed, 26 Jun 2024 14:35:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
> 
> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
> 
> The included test fails without the change, passes with it.
> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
> Unknown length responses that are terminated by EOF continue to work.
> 
> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

Verified the patch locally. Works for me.

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

PR Comment: https://git.openjdk.org/jdk/pull/19909#issuecomment-2194591817

From djelinski at openjdk.org  Thu Jun 27 15:17:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Jun 2024 15:17:15 GMT
Subject: RFR: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
Message-ID: <EkyqvRXvycZbJHS9gZzSXBuhqquvVgjc-B0YFLVgczE=.ac2bb6f1-4d01-4776-8d24-e4534fa66b6f@github.com>

On Wed, 26 Jun 2024 14:35:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
> 
> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
> 
> The included test fails without the change, passes with it.
> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
> Unknown length responses that are terminated by EOF continue to work.
> 
> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19909#issuecomment-2194989973

From djelinski at openjdk.org  Thu Jun 27 15:17:16 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Jun 2024 15:17:16 GMT
Subject: Integrated: 8335135: HttpURLConnection#HttpInputStream does not throw
 IOException when response is truncated
In-Reply-To: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
References: <YoPF6jCCC1SninB2nXnmstClXqwq5BUfh9OIns27C8A=.b5b5e61a-15a9-4aef-8a19-dad9625afd61@github.com>
Message-ID: <rInEWFNOrAatdphtZa6XN5Dr-IerT2w960U4Ne8BSwA=.587b4f29-8122-45f0-8e2a-c368059c43c0@github.com>

On Wed, 26 Jun 2024 14:35:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently HttpUrlConnection accepts truncated responses: if the server sends a `Content-Length` header, and then closes the connection before transferring all promised bytes, the input stream reports a clean EOF.
> 
> In this PR I modify the MeteredStream class to throw an IOException when it detects EOF before receiving all promised response bytes. MeteredStream (or its subclass KeepAliveStream) is used when the response contains a content-length header.
> 
> The included test fails without the change, passes with it.
> The same exception message and type is reported when a chunked response (`Transfer-Encoding: chunked`) is truncated.
> Unknown length responses that are terminated by EOF continue to work.
> 
> 2 tests depended on the old behavior and had to be adjusted. The remaining tier 1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: b6ffb442
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ffb442acb4a222f017868433eff213d9b84ed8
Stats:     120 lines in 4 files changed: 115 ins; 0 del; 5 mod

8335135: HttpURLConnection#HttpInputStream does not throw IOException when response is truncated

Reviewed-by: dfuchs

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

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

From syan at openjdk.org  Fri Jun 28 15:08:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 15:08:29 GMT
Subject: RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
In-Reply-To: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
References: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
Message-ID: <qjyfxr9h9Hm3LmHPGeDnFcpGqXaqUpUH1OYMluDpE3Y=.eb9c5985-1d33-40db-9d1f-c6137517f653@github.com>

On Tue, 25 Jun 2024 13:22:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.
> 
> The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.
> 
> The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).

@dfuch Do you mind I will try to backport this patch to jdk21 and jdk17.

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

PR Comment: https://git.openjdk.org/jdk/pull/19881#issuecomment-2197141185

From dfuchs at openjdk.org  Fri Jun 28 15:18:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 15:18:26 GMT
Subject: RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
In-Reply-To: <qjyfxr9h9Hm3LmHPGeDnFcpGqXaqUpUH1OYMluDpE3Y=.eb9c5985-1d33-40db-9d1f-c6137517f653@github.com>
References: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
 <qjyfxr9h9Hm3LmHPGeDnFcpGqXaqUpUH1OYMluDpE3Y=.eb9c5985-1d33-40db-9d1f-c6137517f653@github.com>
Message-ID: <acx-TH0zCcJW6BwM1gErtOt2BYyPg9Em-qECQmh2ZKo=.62c73292-09e1-4a93-be82-db1e1dffd8e7@github.com>

On Fri, 28 Jun 2024 15:05:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.
>> 
>> The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.
>> 
>> The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).
>
> @dfuch Do you mind I will try to backport this patch to jdk21 and jdk17.

@sendaoYan that would be a question for the maintainers of jdk21 and jdk17 to answer.
See https://openjdk.org/projects/jdk-updates/approval.html

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

PR Comment: https://git.openjdk.org/jdk/pull/19881#issuecomment-2197157733

From syan at openjdk.org  Fri Jun 28 15:36:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 15:36:22 GMT
Subject: RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
In-Reply-To: <qjyfxr9h9Hm3LmHPGeDnFcpGqXaqUpUH1OYMluDpE3Y=.eb9c5985-1d33-40db-9d1f-c6137517f653@github.com>
References: <0YDbguYu7bLMg2nvjeHPJJLOAN0q9a6QfDRjJY55jWk=.50810be5-f652-44e7-b913-7fbc2b620b0a@github.com>
 <qjyfxr9h9Hm3LmHPGeDnFcpGqXaqUpUH1OYMluDpE3Y=.eb9c5985-1d33-40db-9d1f-c6137517f653@github.com>
Message-ID: <DVwCKOO2vL18MwflQIheQ91CsA-mjyzulbw2eAwZdp0=.2f95abf3-d95f-49e5-8d1e-568b8f155b9b@github.com>

On Fri, 28 Jun 2024 15:05:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Please find here a change that makes the test IPMulticastIF.java more resilient to platform-dependent behavior.
>> 
>> The test assumed that you could set any outbound network interface on a bound datagram channel. This is in fact system dependent and could fail if the outbound interface and the local IP Address of the bound socket do not match.
>> 
>> The test is modified to only select the interfaces to which the local address is bound. It also verifies that any interface can be set if the socket is bound to the wildcard (any local address).
>
> @dfuch Do you mind I will try to backport this patch to jdk21 and jdk17.

> @sendaoYan that would be a question for the maintainers of jdk21 and jdk17 to answer. See https://openjdk.org/projects/jdk-updates/approval.html

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19881#issuecomment-2197188507

From syan at openjdk.org  Fri Jun 28 15:41:28 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 15:41:28 GMT
Subject: [jdk23] RFR: 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java
 fails on linux-aarch64
Message-ID: <9xg1HCYWWblPfyytBbDphIfzHoHPFRwM9bGVNiSUtxU=.9611122d-93e1-4aa0-97a7-836140e9a99d@github.com>

Hi all,

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

The commit being backported was authored by Daniel Fuchs on 26 Jun 2024 and was reviewed by Alan Bateman.

Thanks!

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

Commit messages:
 - Backport f23295ec1dde58d239a2625c9b1645534a2bb625

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

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

From alanb at openjdk.org  Sat Jun 29 06:26:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Jun 2024 06:26:19 GMT
Subject: [jdk23] RFR: 8334600: TEST
 java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64
In-Reply-To: <9xg1HCYWWblPfyytBbDphIfzHoHPFRwM9bGVNiSUtxU=.9611122d-93e1-4aa0-97a7-836140e9a99d@github.com>
References: <9xg1HCYWWblPfyytBbDphIfzHoHPFRwM9bGVNiSUtxU=.9611122d-93e1-4aa0-97a7-836140e9a99d@github.com>
Message-ID: <qv5fCrKPBE2m5AoceuDchkkJ54FbIRm91ILtFVAfyys=.7dfcc71b-5d2a-4d5e-a783-1e8058d959a5@github.com>

On Fri, 28 Jun 2024 15:36:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f23295ec](https://github.com/openjdk/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 26 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

@dfuch Has you planned to backport this to jdk23?

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

PR Comment: https://git.openjdk.org/jdk/pull/19945#issuecomment-2198002180

From syan at openjdk.org  Sat Jun 29 14:19:17 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 29 Jun 2024 14:19:17 GMT
Subject: [jdk23] RFR: 8334600: TEST
 java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64
In-Reply-To: <qv5fCrKPBE2m5AoceuDchkkJ54FbIRm91ILtFVAfyys=.7dfcc71b-5d2a-4d5e-a783-1e8058d959a5@github.com>
References: <9xg1HCYWWblPfyytBbDphIfzHoHPFRwM9bGVNiSUtxU=.9611122d-93e1-4aa0-97a7-836140e9a99d@github.com>
 <qv5fCrKPBE2m5AoceuDchkkJ54FbIRm91ILtFVAfyys=.7dfcc71b-5d2a-4d5e-a783-1e8058d959a5@github.com>
Message-ID: <ROhP6e0FPMLokh2a421tnHTsg6A7bImbota3wlRtXF4=.67ee9d6a-375b-4868-b624-5052fbf2eb8c@github.com>

On Sat, 29 Jun 2024 06:23:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @dfuch Has you planned to backport this to jdk23?

Before backport to jdk17u-dev and jdk21u-dev, should we backport to jdk23 first.

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

PR Comment: https://git.openjdk.org/jdk/pull/19945#issuecomment-2198209918