From djelinski at openjdk.org  Mon Oct  2 12:41:18 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 2 Oct 2023 12:41:18 GMT
Subject: RFR: 8317295: ResponseSubscribers.SubscriberAdapter should call
 the finisher function asynchronously [v3]
In-Reply-To: <_YioCiyxOfObMfR8ZiRyQpiNrBL8Fw7T-y0jrsjVS6o=.d9626b36-f8bd-415b-80f5-0019c6bce7be@github.com>
References: <NvrVDLtJuUA7k7Hl0KlfQbstI80g8IwZkOX_FPBL65g=.e0e139a0-fe64-4072-b7d2-c88be076f307@github.com>
 <_YioCiyxOfObMfR8ZiRyQpiNrBL8Fw7T-y0jrsjVS6o=.d9626b36-f8bd-415b-80f5-0019c6bce7be@github.com>
Message-ID: <PyNKpXVCC-g06v_Kfyp1gaIM66DZYwlWQ3qWCN7hv14=.fab94ed9-2df1-4a0c-94c9-502e7e50a042@github.com>

On Fri, 29 Sep 2023 11:07:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The finisher function supplied to `BodySubscribers.fromSubscriber` is specified to be called when `onComplete()` is called on the `BodySubscriber`. However, this function contains application code that may involve blocking operations. Though this is technically a user error to block in any function supplied to the HttpClient API, the `ResponseSubscribers.SubscriberAdapter` should protect itself against this by calling the finisher asynchronously, in the fork join pool.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @bug

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15981#pullrequestreview-1652656256

From dfuchs at openjdk.org  Mon Oct  2 13:09:30 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Oct 2023 13:09:30 GMT
Subject: Integrated: 8317295: ResponseSubscribers.SubscriberAdapter should call
 the finisher function asynchronously
In-Reply-To: <NvrVDLtJuUA7k7Hl0KlfQbstI80g8IwZkOX_FPBL65g=.e0e139a0-fe64-4072-b7d2-c88be076f307@github.com>
References: <NvrVDLtJuUA7k7Hl0KlfQbstI80g8IwZkOX_FPBL65g=.e0e139a0-fe64-4072-b7d2-c88be076f307@github.com>
Message-ID: <6pfN9abZbIzSuPwIBB3xAs7AnClIB3Xmk_Z1tUpzmWY=.f7112970-bd8c-47b6-934d-84e913f59063@github.com>

On Fri, 29 Sep 2023 09:47:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The finisher function supplied to `BodySubscribers.fromSubscriber` is specified to be called when `onComplete()` is called on the `BodySubscriber`. However, this function contains application code that may involve blocking operations. Though this is technically a user error to block in any function supplied to the HttpClient API, the `ResponseSubscribers.SubscriberAdapter` should protect itself against this by calling the finisher asynchronously, in the fork join pool.

This pull request has now been integrated.

Changeset: 8093563b
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8093563bce03b2a7dcea175f1e71cfd67de1c235
Stats:     73 lines in 2 files changed: 61 ins; 0 del; 12 mod

8317295: ResponseSubscribers.SubscriberAdapter should call the finisher function asynchronously

Reviewed-by: djelinski

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

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

From dfuchs at openjdk.org  Mon Oct  2 13:22:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Oct 2023 13:22:18 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream [v3]
In-Reply-To: <021eKsRhWPLE9W-Sz8LLraBhnXE0iZ_QVm5p53iIOtU=.d7553b04-3b35-43eb-a39d-5bc53ca6e41e@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
 <021eKsRhWPLE9W-Sz8LLraBhnXE0iZ_QVm5p53iIOtU=.d7553b04-3b35-43eb-a39d-5bc53ca6e41e@github.com>
Message-ID: <ikpHCsMeVeMgAJpZY6dnmcdT4QjpHhPOUi9kS3sWY8s=.bb381e5e-4ec9-4255-83e1-2532564f4f4d@github.com>

On Wed, 27 Sep 2023 10:55:46 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
>> 
>> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
>> 
>> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
>> 
>> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated the review comments

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpect100Test.java line 81:

> 79:         //send expect continue
> 80:         conn.setRequestProperty("Expect", "100-continue");
> 81:         sendRequest(conn);

Could you call `conn.getResponseCode()` after `sendRequest` here and assert that the returned code is the expected 417?

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpect100Test.java line 82:

> 80:         conn.setRequestProperty("Expect", "100-continue");
> 81:         sendRequest(conn);
> 82:         getHeaderField(conn);

Could you call conn.getInputStream().readAllBytes() here to verify that it doesn't throw? Also verify that you get the expected 0 length result.

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpect100Test.java line 97:

> 95:         conn.setRequestMethod("PUT");
> 96:         sendRequest(conn);
> 97:         getHeaderField(conn);

Same here - please add a line to verify that the response code is 200, and that the returned data is the expected RESPONSE.

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

PR Review: https://git.openjdk.org/jdk/pull/15483#pullrequestreview-1652728826
PR Review Comment: https://git.openjdk.org/jdk/pull/15483#discussion_r1342679549
PR Review Comment: https://git.openjdk.org/jdk/pull/15483#discussion_r1342682738
PR Review Comment: https://git.openjdk.org/jdk/pull/15483#discussion_r1342684206

From duke at openjdk.org  Tue Oct  3 10:02:36 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 3 Oct 2023 10:02:36 GMT
Subject: RFR: 8317246: Cleanup java.net.URLEncoder and URLDecoder use of
 file.encoding property
In-Reply-To: <jKbqfcp7-wdAUeKyxUhB5Jua-iMLekMBxSh9tUqg-Ko=.2306ba73-37a3-4736-9096-e9509b2cee9a@github.com>
References: <jKbqfcp7-wdAUeKyxUhB5Jua-iMLekMBxSh9tUqg-Ko=.2306ba73-37a3-4736-9096-e9509b2cee9a@github.com>
Message-ID: <L53strDY8VEBL602KesK1UT5xZSlic9bmgWGBbMB6D8=.5b951b6d-ea93-4a02-a34f-507269c54f96@github.com>

On Sat, 19 Aug 2023 09:05:47 GMT, Glavo <duke at openjdk.org> wrote:

> `DEFAULT_ENCODING_NAME ` in `URLEncoder` and `URLDecoder` can be replaced with `Charset.defaultCharset()`, which removes unnecessary static fields and avoid looking up charset when calling `URLDecoder.decode(String)` and `URLEncoder.encode(String)`.
> 
> This PR is trivial, since `Charset.defaultCharset()` is also initialized with `StaticProperty.fileEncoding()`, this causes no change in behavior. 
> 
> Moreover, the javadoc of `URLDecoder.decode(String)` and `URLEncoder.encode(String)` say that they use the default charset, so this change is semantically consistent with the documentation.

Can anyone sponsor this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15353#issuecomment-1744634351

From duke at openjdk.org  Tue Oct  3 10:37:45 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 3 Oct 2023 10:37:45 GMT
Subject: Integrated: 8317246: Cleanup java.net.URLEncoder and URLDecoder use of
 file.encoding property
In-Reply-To: <jKbqfcp7-wdAUeKyxUhB5Jua-iMLekMBxSh9tUqg-Ko=.2306ba73-37a3-4736-9096-e9509b2cee9a@github.com>
References: <jKbqfcp7-wdAUeKyxUhB5Jua-iMLekMBxSh9tUqg-Ko=.2306ba73-37a3-4736-9096-e9509b2cee9a@github.com>
Message-ID: <u-u6XqOm7S71z_CtkDe_QGpcFDKaQoaSg7lSMpSnlpw=.86c6ea52-b544-4a45-86fa-408b88aa4f2e@github.com>

On Sat, 19 Aug 2023 09:05:47 GMT, Glavo <duke at openjdk.org> wrote:

> `DEFAULT_ENCODING_NAME ` in `URLEncoder` and `URLDecoder` can be replaced with `Charset.defaultCharset()`, which removes unnecessary static fields and avoid looking up charset when calling `URLDecoder.decode(String)` and `URLEncoder.encode(String)`.
> 
> This PR is trivial, since `Charset.defaultCharset()` is also initialized with `StaticProperty.fileEncoding()`, this causes no change in behavior. 
> 
> Moreover, the javadoc of `URLDecoder.decode(String)` and `URLEncoder.encode(String)` say that they use the default charset, so this change is semantically consistent with the documentation.

This pull request has now been integrated.

Changeset: 3bcfac18
Author:    Glavo <zjx001202 at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bcfac18c39d83bf876787e7ce422831bab0db2f
Stats:     30 lines in 2 files changed: 0 ins; 27 del; 3 mod

8317246: Cleanup java.net.URLEncoder and URLDecoder use of file.encoding property

Reviewed-by: rriggs, naoto

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

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

From dfuchs at openjdk.org  Tue Oct  3 11:22:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Oct 2023 11:22:46 GMT
Subject: RFR: 8317246: Cleanup java.net.URLEncoder and URLDecoder use of
 file.encoding property
In-Reply-To: <eNR1FeMxRgmcPMS9TUylN00Cjq3M-P1HkqCJR7uP8wI=.b8e7c319-44cf-4446-9651-1772c5bdec54@github.com>
References: <jKbqfcp7-wdAUeKyxUhB5Jua-iMLekMBxSh9tUqg-Ko=.2306ba73-37a3-4736-9096-e9509b2cee9a@github.com>
 <eNR1FeMxRgmcPMS9TUylN00Cjq3M-P1HkqCJR7uP8wI=.b8e7c319-44cf-4446-9651-1772c5bdec54@github.com>
Message-ID: <NGocTfg8U5y_MNxf3DTERas_0oWfn1d2I5f6HVT4OdQ=.d156f975-dbd7-4af2-84cd-a2d6725ff2ca@github.com>

On Thu, 21 Sep 2023 10:09:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `DEFAULT_ENCODING_NAME ` in `URLEncoder` and `URLDecoder` can be replaced with `Charset.defaultCharset()`, which removes unnecessary static fields and avoid looking up charset when calling `URLDecoder.decode(String)` and `URLEncoder.encode(String)`.
>> 
>> This PR is trivial, since `Charset.defaultCharset()` is also initialized with `StaticProperty.fileEncoding()`, this causes no change in behavior. 
>> 
>> Moreover, the javadoc of `URLDecoder.decode(String)` and `URLEncoder.encode(String)` say that they use the default charset, so this change is semantically consistent with the documentation.
>
> Right, this only affects deprecated methods, so it's unclear who'd benefit. A little less code and a couple of constants less is nice, I guess.

I ran tests in our CI and observed no failures linked to this PR - I would have sponsored today but @cl4es beat me to it :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/15353#issuecomment-1744756279

From vtewari at openjdk.org  Wed Oct  4 10:38:18 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 4 Oct 2023 10:38:18 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream [v4]
In-Reply-To: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
Message-ID: <NjIXLIMm7qwZsjdYxJ1XoP_ssLi_iSfgUmp7qY8vDJ4=.1244b9d9-3f91-46d0-8dd2-1de36fb54c0b@github.com>

> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
> 
> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
> 
> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
> 
> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.

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

  addressed the review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15483/files
  - new: https://git.openjdk.org/jdk/pull/15483/files/5f6510aa..27280f61

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

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

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

From vtewari at openjdk.org  Wed Oct  4 10:45:43 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 4 Oct 2023 10:45:43 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream [v3]
In-Reply-To: <ikpHCsMeVeMgAJpZY6dnmcdT4QjpHhPOUi9kS3sWY8s=.bb381e5e-4ec9-4255-83e1-2532564f4f4d@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
 <021eKsRhWPLE9W-Sz8LLraBhnXE0iZ_QVm5p53iIOtU=.d7553b04-3b35-43eb-a39d-5bc53ca6e41e@github.com>
 <ikpHCsMeVeMgAJpZY6dnmcdT4QjpHhPOUi9kS3sWY8s=.bb381e5e-4ec9-4255-83e1-2532564f4f4d@github.com>
Message-ID: <eXiUqy5I9dbhjVjmB-_spHTz-ZCaJ8Kcv-5jkEiUmuI=.ed7b4eb8-8f09-45c8-a0a7-852d918a332f@github.com>

On Mon, 2 Oct 2023 13:17:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated the review comments
>
> test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpect100Test.java line 82:
> 
>> 80:         conn.setRequestProperty("Expect", "100-continue");
>> 81:         sendRequest(conn);
>> 82:         getHeaderField(conn);
> 
> Could you call conn.getInputStream().readAllBytes() here to verify that it doesn't throw? Also verify that you get the expected 0 length result.

As getInputStream calls > getInputStream0 > getOutputStream > getOutputStream0 >  So if server rejected the operation  then  getInputStream will also throw the same exception. This behavior is same even without the fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15483#discussion_r1345587258

From dfuchs at openjdk.org  Wed Oct  4 11:32:37 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Oct 2023 11:32:37 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream [v4]
In-Reply-To: <NjIXLIMm7qwZsjdYxJ1XoP_ssLi_iSfgUmp7qY8vDJ4=.1244b9d9-3f91-46d0-8dd2-1de36fb54c0b@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
 <NjIXLIMm7qwZsjdYxJ1XoP_ssLi_iSfgUmp7qY8vDJ4=.1244b9d9-3f91-46d0-8dd2-1de36fb54c0b@github.com>
Message-ID: <4BAcIEPLhAmO0DZnWHdU32qJmjpWBMG06Kgw0JVNYJc=.a2dbb6a4-ab9b-4ea0-8856-587d9e7293fc@github.com>

On Wed, 4 Oct 2023 10:38:18 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
>> 
>> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
>> 
>> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
>> 
>> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed the review comment

Thanks for the updates. Give me some time to test.

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

PR Review: https://git.openjdk.org/jdk/pull/15483#pullrequestreview-1657304883

From aefimov at openjdk.org  Wed Oct  4 16:56:43 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 4 Oct 2023 16:56:43 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <7QD5d3W6C1AowCi-cRVBuQnimo8nVf-atnudKTzPUK4=.9f67a3fc-629a-4085-8e98-fd556ddf226f@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

To restart the conversation around the method name, I've prepared the following table with a list of method names discussed during the previous review iteration:

| Name | Usage Example | Notes |
|-------|--------------|-------|
| `ofLiteral` | `InetAddress.ofLiteral` | Current version. Cleary conveys it takes only an IP literal. Matches its implementation. Good for IDE autocompletion. |
| `parse` | `InetAddress.parse` | The fact that only IP address literals are taken as a parameter is obscured a bit. But still suggests that the InetAddress instance is constructed by parsing some text. Good for IDE.|
| `parseLiteral` | `InetAddress.parseLiteral` | Method name changed to hint that an IP address literal is taken as a parameter. Good for IDE. Matches its implementation.|
| `getByAddress` | `InetAddress.getByAddress` | Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address. Introduces new meaning of `address` term - IP address literal string. In existing API the `address` means a raw byte array.|

My preference is to follow with one of the following two:
`ofLiteral` or `parseLiteral`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1747264766

From dfuchs at openjdk.org  Wed Oct  4 16:57:03 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Oct 2023 16:57:03 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream [v4]
In-Reply-To: <NjIXLIMm7qwZsjdYxJ1XoP_ssLi_iSfgUmp7qY8vDJ4=.1244b9d9-3f91-46d0-8dd2-1de36fb54c0b@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
 <NjIXLIMm7qwZsjdYxJ1XoP_ssLi_iSfgUmp7qY8vDJ4=.1244b9d9-3f91-46d0-8dd2-1de36fb54c0b@github.com>
Message-ID: <DxEZFBJ-yDSRk-weug7x99Zk18tm90pbA9eI0Cxf4RY=.e1baf6a4-ebb0-4ab3-a9c8-796c709cd0ef@github.com>

On Wed, 4 Oct 2023 10:38:18 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
>> 
>> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
>> 
>> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
>> 
>> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed the review comment

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15483#pullrequestreview-1658085707

From dfuchs at openjdk.org  Wed Oct  4 17:22:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Oct 2023 17:22:51 GMT
Subject: RFR: 8317522: Test logic for BODY_CF in
 AbstractThrowingSubscribers.java is wrong
Message-ID: <hNT4nXhmX5KXNVDQ-gBzLoUVIPoRniHbUlXw7Za1dac=.87c993aa-f472-4ba5-8890-346b83c2aad7@github.com>

The `AbstractThrowingSubscribers.java` test class makes the assumption that the HttpClient will cancel a request if the body `CompletableFuture` returned by a `BodySubscriber::getBody` is completed exceptionally. This assumption is wrong. Indeed, it should be the responsibility of the custom subscriber to cancel its subscription, or not, in such a case, as whether to cancel or not depends on the semantic the subscriber assigns to such a body.

The issue can be observed by modifying the test to send a longer response split in several chunks: with such a configuration, and using streaming body subscribers, such as `ofInputStream`, the test will fail waiting for the HttpClient to be garbaged collected, as the response data will not get pulled and the underlying exchange will never terminate. Though changing the HttpClient code to forcefully cancel the subscription (or the exchange) in such a case would "work", it does not seem desirable: it would introduce a change of behavior that might cause existing applications to fail, and there may be cases where a custom subscriber may legitimately want to complete its body CF exceptionally while still continuing to parse the body bytes. Whether to choose to cancel the subscription or not should solely depend on the logic of the custom subscriber.

The test logic is now modified to reflect this. Commenting the line that cancels the subscription in `ThrowingBodySubscriber::getBody` would now make the test fail. The test was previously passing "by chance" because the whole response was contained in a single `DataFrame` (or `ByteBuffer` for HTTP/1.1).

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

Commit messages:
 - 8317522

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

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

From duke at openjdk.org  Thu Oct  5 00:32:26 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 5 Oct 2023 00:32:26 GMT
Subject: RFR: 8316681: Rewrite URLEncoder.encode to use small reusable
 buffers [v6]
In-Reply-To: <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
References: <yqnNQpHX86NG7h7W9_yyTB4x6lHwn_yo6frGgatDTwo=.820bda8f-5c3c-40b5-bc5f-b5a5d90d5142@github.com>
 <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
Message-ID: <dWy6wcSaCrTmOU_nfzhmcdd-aSV80p8rZ56JXfHUd8A=.f8b72df6-95ae-48b9-b101-394f3067343a@github.com>

On Fri, 22 Sep 2023 08:53:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `URLEncoder` currently appends chars that needs encoding into a `java.io.CharArrayWriter`, converts that to a `String`, uses `String::getBytes` to get the encoded bytes and then appends these bytes in a escaped manner to the output stream. This is somewhat inefficient.
>> 
>> This PR replaces the `CharArrayWriter` with a reusable `CharBuffer` + `ByteBuffer` pair. This allows us to encode to the output `StringBuilder` in small chunks, with greatly reduced allocation as a result.
>> 
>> The exact size of the buffers is an open question, but generally it seems that a tiny buffer wins by virtue of allocating less, and that the per chunk overheads are relatively small.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/net/URLEncoder.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

URLEncoder#DONT_NEED_ENCODING based on BitSet is actually a lookup table. Should we consider improving it in this way?


public class URLEncoder {
	static final long DONT_NEED_ENCODING_FLAGS_0;
	static final long DONT_NEED_ENCODING_FLAGS_1;

	static {
		long flag0 = 0;
	    flag0 |= 1L << ' '; // ASCII 32
	    flag0 |= 1L << '*'; // ASCII 42
	    flag0 |= 1L << '-'; // ASCII 25
	    flag0 |= 1L << '.'; // ASCII 46

	    // ASCII 48 - 57
	    for (int i = '0'; i <= '9'; ++i) {
	        flag0 |= 1L << i;
	    }
	    DONT_NEED_ENCODING_FLAGS_0 = flag0;

	    long flags1 = 0;
	    // ASCII 65 - 90
	    for (int i = 'A'; i <= 'Z'; ++i) {
	        flags1 |= 1L << (i - 64);
	    }
	    flags1 |= 1L << ('_' - 64); // ASCII 95
	    // ASCII 97 - 122
	    for (int i = 'a'; i <= 'z'; ++i) {
	        flags1 |= 1L << (i - 64);
	    }
	    DONT_NEED_ENCODING_FLAGS_1 = flags1;
	}

	private static boolean dontNeedEncoding(char c) {
		int prefix = c >> 6;
		if (prefix > 1) {
			return false;
		}
	        long flags = prefix == 0 ? DONT_NEED_ENCODING_FLAGS_0 : DONT_NEED_ENCODING_FLAGS_1;
        	return (flags & (1L << c)) != 0;
	}
}

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

PR Comment: https://git.openjdk.org/jdk/pull/15865#issuecomment-1747842588

From djelinski at openjdk.org  Thu Oct  5 06:46:14 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 5 Oct 2023 06:46:14 GMT
Subject: RFR: 8317522: Test logic for BODY_CF in
 AbstractThrowingSubscribers.java is wrong
In-Reply-To: <hNT4nXhmX5KXNVDQ-gBzLoUVIPoRniHbUlXw7Za1dac=.87c993aa-f472-4ba5-8890-346b83c2aad7@github.com>
References: <hNT4nXhmX5KXNVDQ-gBzLoUVIPoRniHbUlXw7Za1dac=.87c993aa-f472-4ba5-8890-346b83c2aad7@github.com>
Message-ID: <5Y9dk89w-1cwKBvtBffzS9loqUR_gSHeKT4MCISz5zY=.61a2e128-ea79-45d4-8b69-8856873a46ef@github.com>

On Wed, 4 Oct 2023 17:14:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `AbstractThrowingSubscribers.java` test class makes the assumption that the HttpClient will cancel a request if the body `CompletableFuture` returned by a `BodySubscriber::getBody` is completed exceptionally. This assumption is wrong. Indeed, it should be the responsibility of the custom subscriber to cancel its subscription, or not, in such a case, as whether to cancel or not depends on the semantic the subscriber assigns to such a body.
> 
> The issue can be observed by modifying the test to send a longer response split in several chunks: with such a configuration, and using streaming body subscribers, such as `ofInputStream`, the test will fail waiting for the HttpClient to be garbaged collected, as the response data will not get pulled and the underlying exchange will never terminate. Though changing the HttpClient code to forcefully cancel the subscription (or the exchange) in such a case would "work", it does not seem desirable: it would introduce a change of behavior that might cause existing applications to fail, and there may be cases where a custom subscriber may legitimately want to complete its body CF exceptionally while still continuing to parse the body bytes. Whether to choose to cancel the subscription or not should solely depend on the logic of the custom subscriber.
> 
> The test logic is now modified to reflect this. Commenting the line that cancels the subscription in `ThrowingBodySubscriber::getBody` would now make the test fail. The test was previously passing "by chance" because the whole response was contained in a single `DataFrame` (or `ByteBuffer` for HTTP/1.1).

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16041#pullrequestreview-1658986061

From redestad at openjdk.org  Thu Oct  5 07:50:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Oct 2023 07:50:22 GMT
Subject: RFR: 8316681: Rewrite URLEncoder.encode to use small reusable
 buffers [v6]
In-Reply-To: <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
References: <yqnNQpHX86NG7h7W9_yyTB4x6lHwn_yo6frGgatDTwo=.820bda8f-5c3c-40b5-bc5f-b5a5d90d5142@github.com>
 <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
Message-ID: <ypVdcMFMLdVthAwRFkvWagSyuiaYS1Rx5SVZHcY47j4=.2d3ac1bd-a8fd-4982-b274-b347edf0e73d@github.com>

On Fri, 22 Sep 2023 08:53:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `URLEncoder` currently appends chars that needs encoding into a `java.io.CharArrayWriter`, converts that to a `String`, uses `String::getBytes` to get the encoded bytes and then appends these bytes in a escaped manner to the output stream. This is somewhat inefficient.
>> 
>> This PR replaces the `CharArrayWriter` with a reusable `CharBuffer` + `ByteBuffer` pair. This allows us to encode to the output `StringBuilder` in small chunks, with greatly reduced allocation as a result.
>> 
>> The exact size of the buffers is an open question, but generally it seems that a tiny buffer wins by virtue of allocating less, and that the per chunk overheads are relatively small.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/net/URLEncoder.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

How would this be an improvement?

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

PR Comment: https://git.openjdk.org/jdk/pull/15865#issuecomment-1748302930

From dfuchs at openjdk.org  Thu Oct  5 10:47:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 5 Oct 2023 10:47:20 GMT
Subject: Integrated: 8317522: Test logic for BODY_CF in
 AbstractThrowingSubscribers.java is wrong
In-Reply-To: <hNT4nXhmX5KXNVDQ-gBzLoUVIPoRniHbUlXw7Za1dac=.87c993aa-f472-4ba5-8890-346b83c2aad7@github.com>
References: <hNT4nXhmX5KXNVDQ-gBzLoUVIPoRniHbUlXw7Za1dac=.87c993aa-f472-4ba5-8890-346b83c2aad7@github.com>
Message-ID: <HA6gNUy-LZw4Kq7N60Yw5ibn4za0sAZsePmyAqlo-qM=.af778aed-ad2d-4040-a0ed-aae34372ac57@github.com>

On Wed, 4 Oct 2023 17:14:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `AbstractThrowingSubscribers.java` test class makes the assumption that the HttpClient will cancel a request if the body `CompletableFuture` returned by a `BodySubscriber::getBody` is completed exceptionally. This assumption is wrong. Indeed, it should be the responsibility of the custom subscriber to cancel its subscription, or not, in such a case, as whether to cancel or not depends on the semantic the subscriber assigns to such a body.
> 
> The issue can be observed by modifying the test to send a longer response split in several chunks: with such a configuration, and using streaming body subscribers, such as `ofInputStream`, the test will fail waiting for the HttpClient to be garbaged collected, as the response data will not get pulled and the underlying exchange will never terminate. Though changing the HttpClient code to forcefully cancel the subscription (or the exchange) in such a case would "work", it does not seem desirable: it would introduce a change of behavior that might cause existing applications to fail, and there may be cases where a custom subscriber may legitimately want to complete its body CF exceptionally while still continuing to parse the body bytes. Whether to choose to cancel the subscription or not should solely depend on the logic of the custom subscriber.
> 
> The test logic is now modified to reflect this. Commenting the line that cancels the subscription in `ThrowingBodySubscriber::getBody` would now make the test fail. The test was previously passing "by chance" because the whole response was contained in a single `DataFrame` (or `ByteBuffer` for HTTP/1.1).

This pull request has now been integrated.

Changeset: 4c5b66dc
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c5b66dceab15ce27f742c4173e14156249eb61a
Stats:     82 lines in 1 file changed: 55 ins; 11 del; 16 mod

8317522: Test logic for BODY_CF in AbstractThrowingSubscribers.java is wrong

Reviewed-by: djelinski

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

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

From msheppar at openjdk.org  Thu Oct  5 22:28:02 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 5 Oct 2023 22:28:02 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <6K47JoJa4WnRfSm_G8wg8tFhD8pELEn7YwflND7JdyM=.62e64e76-fb85-43f7-8e45-909b677df873@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

the most consistent (with the current API) and object oriented version is the getByAddress(String addr). It is consistent with the existing API. Logically getByAddress(byte[]) and getByAddress(String) are essentially the same. That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address, as a String is an encapsulation of an array of bytes. As such it logically natural to add an overloaded method.
Adding a new style of method affects the logical balance of the InetAddress class, giving a mongrel, or hybrid API appearance.

Ceist agam ort:
Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach? Or have I misconstrued your statement:  "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1749739710

From aefimov at openjdk.org  Fri Oct  6 11:17:48 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 6 Oct 2023 11:17:48 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <6K47JoJa4WnRfSm_G8wg8tFhD8pELEn7YwflND7JdyM=.62e64e76-fb85-43f7-8e45-909b677df873@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <6K47JoJa4WnRfSm_G8wg8tFhD8pELEn7YwflND7JdyM=.62e64e76-fb85-43f7-8e45-909b677df873@github.com>
Message-ID: <BV8zrVRMaMTL9yEEkMFM6c1eucneqdwryWRgxomIJVw=.c3f30b8b-e7cd-454d-bb10-343c04b61830@github.com>

On Thu, 5 Oct 2023 22:25:23 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address

 A literal IP address string can specify the same address in [multiple formats](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/InetAddress.html#textual-representation-of-ip-addresses-heading), a byte array supports only one - an array of bytes, with length equal to 4 for IPv4 addresses, and to 16 for IPv6 addresses.

> Ceist agam ort:
> Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach?

The idea of this change is to add three methods capable of parsing a string as an IPv4, IPv6 or any IP literal address. The explicit methods needs to be added to all three classes irrelevant to their naming.

> Or have I misconstrued your statement: "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
> But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.

You are right that the statement is a bit vague, yes. What was meant there that overloading `InetAddres` method, and adding new methods to `Inet4Address` and `Inet6Address` would introduce a bit confusing API structure. All three classes for both approaches would look like:

### ofLiteral approach

// New methods
InetAddress.ofLiteral(String)
Inet4Address.ofLiteral(String)
Inet6Address.ofLiteral(String)


### getByAddress approach

// Existing methods with `address` being a byte array
InetAddress.getByAddress(String, byte[])
InetAddress.getByAddress(byte[])

// New methods with `address` being a literal  
InetAddress.getByAddress(String) <-- overloaded method
Inet4Address.getByAddress(String) <-- new and not overloaded method
Inet6Address.getByAddress(String) <-- new and not overloaded method

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1750435491

From duke at openjdk.org  Fri Oct  6 18:45:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 6 Oct 2023 18:45:20 GMT
Subject: RFR: 8316681: Rewrite URLEncoder.encode to use small reusable
 buffers [v6]
In-Reply-To: <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
References: <yqnNQpHX86NG7h7W9_yyTB4x6lHwn_yo6frGgatDTwo=.820bda8f-5c3c-40b5-bc5f-b5a5d90d5142@github.com>
 <_s5aVyb4hZsEWAt9dhIuhPbjJHcJhq4yarhxYeiyWjY=.4ae72c48-4d1e-44f4-a30a-e6d1ba58a3cb@github.com>
Message-ID: <UWBd5-26NqBdLoYQ0LVgxxo1qNahi7-oyy9Q5Aqe_Nc=.022f49ca-7ed8-4244-afe8-b0574599ef53@github.com>

On Fri, 22 Sep 2023 08:53:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `URLEncoder` currently appends chars that needs encoding into a `java.io.CharArrayWriter`, converts that to a `String`, uses `String::getBytes` to get the encoded bytes and then appends these bytes in a escaped manner to the output stream. This is somewhat inefficient.
>> 
>> This PR replaces the `CharArrayWriter` with a reusable `CharBuffer` + `ByteBuffer` pair. This allows us to encode to the output `StringBuilder` in small chunks, with greatly reduced allocation as a result.
>> 
>> The exact size of the buffers is an open question, but generally it seems that a tiny buffer wins by virtue of allocating less, and that the per chunk overheads are relatively small.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/net/URLEncoder.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

The improvement is about 3% to 13% under microbench. The baseline is based on BitSet table lookup. In real scenarios, the performance of the new version that does not use BitSet should be better.

Performance numbers running on MacBook M1 Pro: 

-Benchmark                         (encodeChars)  (maxLength)  (unchanged)  Mode  Cnt  Score   Error  Units (baseline)
-URLEncodeDecode.testEncodeLatin1              6         1024            0  avgt   15  2.244 ? 0.290  ms/op
-URLEncodeDecode.testEncodeLatin1              6         1024           75  avgt   15  0.956 ? 0.074  ms/op
-URLEncodeDecode.testEncodeLatin1              6         1024          100  avgt   15  0.400 ? 0.006  ms/op

+Benchmark                         (encodeChars)  (maxLength)  (unchanged)  Mode  Cnt  Score    Error  Units (optimized)
+URLEncodeDecode.testEncodeLatin1              6         1024            0  avgt   15  2.057 ?  0.016  ms/op (+9.10)
+URLEncodeDecode.testEncodeLatin1              6         1024           75  avgt   15  0.842 ?  0.002  ms/op (+13.54)
+URLEncodeDecode.testEncodeLatin1              6         1024          100  avgt   15  0.385 ?  0.001  ms/op (+3.90)

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

PR Comment: https://git.openjdk.org/jdk/pull/15865#issuecomment-1751244288

From msheppar at openjdk.org  Sat Oct  7 11:35:16 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Sat, 7 Oct 2023 11:35:16 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <mOD7eYj6nDBrtQQ26M7dNkX0gYBk_6wX1KoBIBKQAcY=.7f387c98-01bf-4997-bab9-90331d9de9e7@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

thanks for the considered response

> > That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address
> 
> A literal IP address string can specify the same address in [multiple formats](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/InetAddress.html#textual-representation-of-ip-addresses-heading), a byte array supports only one - an array of bytes, with length equal to 4 for IPv4 addresses, and to 16 for IPv6 addresses.

I think you may have misinterpreted the point I was trying to make (or I didn't make it clearly enough), for example, a 4 byte array representing an IPv4 address is logically the same as a String representing an IPv4 address in dot notation. Thus, overloading getByAddress is a reasonable method to add and exhibits OO characteristics.

> 
> > Ceist agam ort:
> > Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach?
> 
> The idea of this change is to add three methods capable of parsing a string as an IPv4, IPv6 or any IP literal address. The explicit methods need to be added to all three classes irrelevant to their naming.
> 
> > Or have I misconstrued your statement: "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
> > But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.
> 
> You are right that the statement is a bit vague, yes. What was meant there was overloading the `InetAddress` method, and adding new methods to `Inet4Address` and `Inet6Address` would introduce a bit confusing API structure. All three classes for both approaches would look like:
> ### ofLiteral approach
> 
> ```
> // New methods
> InetAddress.ofLiteral(String)
> Inet4Address.ofLiteral(String)
> Inet6Address.ofLiteral(String)
> ```
> 
> ### getByAddress approach
> 
> ```
> // Existing methods with `address` being a byte array
> InetAddress.getByAddress(String, byte[])
> InetAddress.getByAddress(byte[])
> 
> // New methods with `address` being a literal  
> InetAddress.getByAddress(String) <-- overloaded method
> Inet4Address.getByAddress(String) <-- new and not overloaded method
> Inet6Address.getByAddress(String) <-- new and not overloaded method
> ```

There's no need to add these methods,
Inet4Address.getByAddress(String) <-- new and not overloaded method
Inet6Address.getByAddress(String) <-- new and not overloaded method

 to the derived classes. The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751688344

From alanb at openjdk.org  Sat Oct  7 12:04:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Oct 2023 12:04:09 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <mOD7eYj6nDBrtQQ26M7dNkX0gYBk_6wX1KoBIBKQAcY=.7f387c98-01bf-4997-bab9-90331d9de9e7@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <mOD7eYj6nDBrtQQ26M7dNkX0gYBk_6wX1KoBIBKQAcY=.7f387c98-01bf-4997-bab9-90331d9de9e7@github.com>
Message-ID: <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.cedf9716-9910-4fe7-890a-f65cbd192297@github.com>

On Sat, 7 Oct 2023 11:32:43 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class

I don't think I agree with this. The existing 2-arg getByAddress method takes a string that is a host name or string representation of an IP address. It can be argued that it was a mistake to allow it accept IP literal addresses but it can't be changed. Same thing with the UHE thrown by both getByAddress methods but that can't be changed either.

The new factory methods have a very clear purpose to create an InetAddress from the string representation of an IP literal address. The proposed name ofLiteral is readable/clear and consistent with the naming of other static factory methods added to the APIs in recent years.








The goal here is to add methods to parse IP address literals.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751693706

From msheppar at openjdk.org  Sat Oct  7 13:30:17 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Sat, 7 Oct 2023 13:30:17 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.cedf9716-9910-4fe7-890a-f65cbd192297@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <mOD7eYj6nDBrtQQ26M7dNkX0gYBk_6wX1KoBIBKQAcY=.7f387c98-01bf-4997-bab9-90331d9de9e7@github.com>
 <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.cedf9716-9910-4fe7-890a-f65cbd192297@github.com>
Message-ID: <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.4451974c-69f9-452b-93ef-d3a5463e9a1b@github.com>

On Sat, 7 Oct 2023 12:01:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class
> 
> I don't think I agree with this. The existing 2-arg getByAddress method takes a string that is a host name or string representation of an IP address. It can be argued that it was a mistake to allow it accept IP literal addresses but it can't be changed. Same thing with the UHE thrown by both getByAddress methods but that can't be changed either.
> 

The sentence should have read "The functionality can be fully provided by adding an overloaded (static) getByAddress in the base InetAddress class, only."

I wasn't suggesting that the current API was providing the requested functionality.
you may have misinterpreted what I'm saying. 
The requested functionality can be provided by an overloaded getByAddress method to the InetAddress , and that is sufficient. As such, there is no need for additional method in the Inet4Address or Inet6Address

> The new factory methods have a very clear purpose to create an InetAddress from the string representation of an IP literal address. The proposed name ofLiteral is readable/clear and consistent with the naming of other static factory methods added to the APIs in recent years.

For me, it is not consistent with the well esatblished InetAddress API (getByName, getByAddress), in which case the ofLiteral style looks like a bit of a wart.  Adding an overloaded getByAddress method is a logical OO design approach.  You seem to be intent on adding this "ofXXX" style methods. So we'll just have to agree to disagree on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751713257

From jkratochvil at openjdk.org  Sat Oct  7 16:33:38 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 7 Oct 2023 16:33:38 GMT
Subject: RFR: 8317696: Fix compilation with clang-16
Message-ID: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>

8317696: Fix compilation with clang-16

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

Commit messages:
 - 8317696: Fix compilation with clang-16

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

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

From jiefu at openjdk.org  Sun Oct  8 01:42:37 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 8 Oct 2023 01:42:37 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <Zkn7jVrn14qTjJDeCVtDPX4JjTcujBsHxa6GFfZb9ZE=.a19240c6-d508-461c-a428-6a50ddcc6d83@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

JBS: https://bugs.openjdk.org/browse/JDK-8317698

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1751882784

From vtewari at openjdk.org  Sun Oct  8 05:16:22 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sun, 8 Oct 2023 05:16:22 GMT
Subject: Integrated: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream
In-Reply-To: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
Message-ID: <wPBtBXTsNucP3V16kUudeNqEo_N1vP0S4Zr_QYJM5YA=.a5b0668f-8d2f-4b07-933b-9657bbabc9f2@github.com>

On Wed, 30 Aug 2023 09:23:34 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
> 
> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
> 
> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
> 
> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.

This pull request has now been integrated.

Changeset: 460ebcd9
Author:    Vyom Tewari <vtewari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/460ebcd9cb94867608e22e07092bd1cf33228700
Stats:     268 lines in 2 files changed: 268 ins; 0 del; 0 mod

8314978: Multiple server call from connection failing with expect100 in getOutputStream

Reviewed-by: dfuchs

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

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

From redestad at openjdk.org  Sun Oct  8 20:38:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Oct 2023 20:38:13 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <ew4u0LgtbZ9qo_PjBm5tYFfy10H8gyIp9CAioj4H_QQ=.84d644f8-d390-44e2-ad33-e61ad4cd8b66@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

I think this is a step in the wrong direction, duplicating code from a shared utility class in order to get a marginal improvement.

Could you instead analyze *why* this is a win and then see if we can improve the utility class (`ImmutableBitSetPredicate`) instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752155763

From redestad at openjdk.org  Sun Oct  8 21:17:03 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 8 Oct 2023 21:17:03 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <FMpZ8ub9RhuJTPrh_17RJAqeUsN0aG9DXRObDWZRbyE=.24a29e4c-8474-436b-ab46-16aa78420f4d@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

I drafted a PR that pulls off more or less the same optimization but does so by adding a variant to `ImmutableBitSetPredicate`. This ensures other `BitSet`-based predicates of 128 elements or less would get the similar benefit, and better contains the added complexity.

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752163233

From duke at openjdk.org  Mon Oct  9 03:00:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 03:00:24 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <V07Cuu8l-Sj9-hGQojxORJzq7ugk8JYemr1egnaKuuw=.f877c27f-c6bf-4c0b-b431-6a52ca179ec7@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

My problem is that ImmutableBitSetPredicate as a jdk.internal class is only used in URLEncoder

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752280940

From alanb at openjdk.org  Mon Oct  9 06:33:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Oct 2023 06:33:09 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.4451974c-69f9-452b-93ef-d3a5463e9a1b@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <mOD7eYj6nDBrtQQ26M7dNkX0gYBk_6wX1KoBIBKQAcY=.7f387c98-01bf-4997-bab9-90331d9de9e7@github.com>
 <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.cedf9716-9910-4fe7-890a-f65cbd192297@github.com>
 <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.4451974c-69f9-452b-93ef-d3a5463e9a1b@github.com>
Message-ID: <vZZRzBrVZvIQ-pSTcsO3ecEZ0J55Rijj95787xvKvzQ=.de665d9d-b6eb-475f-8ca1-9dcf0113cd74@github.com>

On Sat, 7 Oct 2023 13:27:45 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The sentence should have read "The functionality can be fully provided by adding an overloaded (static) getByAddress in the base InetAddress class, only."
> 
> I wasn't suggesting that the current API was providing the requested functionality. you may have misinterpreted what I'm saying. The requested functionality can be provided by an overloaded getByAddress method to the InetAddress , and that is sufficient. As such, there is no need for additional method in the Inet4Address or Inet6Address

The existing naming in InetAddress comes with baggage. The getByXXX method suggests lookup, they throw UHE. The getByAddress methods take a byte[], the input is bytes. The String parameter for the 2-arg getByAddress is intended to be a host name. I don't think the new static factory methods should be burdened with all this baggage so move to a methods that are clear/obvious/readable seems a much better route. We can bikeshed over specific name but the ofXXX convention is something that many areas of the platform has adopted in recent years.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752413273

From jpai at openjdk.org  Mon Oct  9 07:03:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Oct 2023 07:03:11 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.7acf31c6-1b7f-48fe-a7d5-bf45eb631884@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

Hello Aleksei, it's good to see the addition of these new APIs. On the naming front, I like the proposal of using either `ofLiteral` or `parseLiteral`.

The new APIs are proposing to throw an `IllegalArgumentException` if the passed literal is not an IP address literal. That seems logical. However, the existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw IP address, currently throws `UnknownHostException` in the case where the IP address isn't of a valid length. Should we consider throwing `UnknownHostException` from these new APIs too? I prefer `IllegalArgumentException` in these new APIs, but `UnknownHostException` might be something that would need to be considered?

The proposed changes also have text which talks about "ambiguous" address literals. The term ambiguous seems new in the InetAddress (and sub-classes). The package-info.java too doesn't have previous references to it. Should we add some details on what addresses are considered ambiguous (and how/if such addresses are treated by existing APIs)?

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752441558

From jpai at openjdk.org  Mon Oct  9 07:12:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Oct 2023 07:12:11 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <wN6HAbATLH-Wf7M-93ldDrR3CrA83w6Ze4k2imDJFCE=.08c85583-685d-4c6f-82ae-432e49494d2f@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 135:

> 133:      * to {@code false}, or is not set then validation of the address string is performed as follows:
> 134:      * If string can't be parsed by following IETF IPv4 address string literals
> 135:      * formatting style rules (default one), but can be parsed by following BSD formatting

I realize that this is an existing javadoc comment in an internal utility class (which is used by public InetAddress API implementation); do you think we should add a more formal reference to the BSD formatting of IP address, like we currently do for other RFCs and such in the class level javadoc of `InetAddress`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349926001

From alanb at openjdk.org  Mon Oct  9 07:15:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Oct 2023 07:15:09 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.7acf31c6-1b7f-48fe-a7d5-bf45eb631884@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.7acf31c6-1b7f-48fe-a7d5-bf45eb631884@github.com>
Message-ID: <3jfTVsFV-rv9zswqZJbE0FoPWo_W5LZ8PYv1aW7PGws=.0f52484b-060f-4a62-8b3f-c674b847a2f6@github.com>

On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The new APIs are proposing to throw an `IllegalArgumentException` if the passed literal is not an IP address literal. That seems logical. However, the existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw IP address, currently throws `UnknownHostException` in the case where the IP address isn't of a valid length. Should we consider throwing `UnknownHostException` from these new APIs too? I prefer `IllegalArgumentException` in these new APIs, but `UnknownHostException` might be something that would need to be considered?

UHE is an IOException so would be problematic for a number of reasons. IAE is the right exception for bad input here.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752455199

From jpai at openjdk.org  Mon Oct  9 07:15:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Oct 2023 07:15:12 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <sXD4KqQX8DZR5e03H1BopbP-BGBxUdbP9z6t6O7KJNM=.fdb5d9e6-b875-42e0-90ae-e39d1afacfb5@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

src/java.base/share/classes/java/net/Inet4Address.java line 181:

> 179:     /**
> 180:      * Parses string with an IPv4 address literal.
> 181:      * If string doesn't contain a valid literal - null is returned.

This sentence is a bit confusing, given the implementation details of this method. I think `null` is only returned if `throwIAE` is false?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349928593

From jpai at openjdk.org  Mon Oct  9 07:19:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Oct 2023 07:19:11 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <YI8jeX4KoUafEd5Jyh7RWgZ5h03uf2SA3TGOzkkV-Us=.2f6d3e5b-4c9f-43d6-96e4-c55473896347@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 141:

> 139:      * @param src input string
> 140:      * @param throwIAE {@code "true"} - throw {@code IllegalArgumentException} when cannot be parsed as IPv4 address string;
> 141:      *                 {@code "false"} - throw {@code "IllegalArgumentException"} only when IPv4 address string is ambiguous.

Are these double quotes around `true`, `false`, `null` and `IllegalArgumentException` intentional? It seems odd to have those double quotes when (rightly) using `{@code}`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349930995

From redestad at openjdk.org  Mon Oct  9 08:05:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Oct 2023 08:05:09 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <qIh8d5QP7F2ytBn2RTHsnrANv9OOY3jeLBWio_9s-oI=.1e630e09-8e73-4d27-9906-d4b1cb6d6bd0@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

It was recently conceived specifically to help `URLEncoder`, and it was implemented as an internal utility to give it time to mature/evolve and to make the decision to turn it into a public API independent from getting a quick win on JDK-internal code. It seems natural and logical that we keep improving this abstraction rather than manually inline the logic into `URLEncoder`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752517839

From duke at openjdk.org  Mon Oct  9 10:02:01 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 10:02:01 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <4r2InWqpRO344uCssw5sJzEJbkCBxVsEBAxai5iz1eo=.2981f83e-0b34-4096-9046-0b18c899a139@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

Can we find another use case of ImmutableBitSetPredicate in java.base?

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752622026

From ccleary at openjdk.org  Mon Oct  9 10:22:39 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 10:22:39 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

Conor Cleary 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 ten additional commits since the last revision:

 - 8309118: Fixed error in handleReset ReentrantLock
 - 8309118: Updates to Stream cancelImpl
 - 8309118: Refactored test, updated incoming_reset
 - Merge branch 'master' into JDK-8309118
 - 8309118: Cleanup identifiers and whitespace
 - 8309118: Removed unused try-with-resources
 - 8309118: Improve comments and annotations
 - 8309118: Remove local test timeout value
 - 8309118: Add more tests for 100 ExpectContinue with HTTP/2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/a2fec5f3..909783b2

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

  Stats: 134477 lines in 3723 files changed: 64529 ins; 26135 del; 43813 mod
  Patch: https://git.openjdk.org/jdk/pull/15664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15664/head:pull/15664

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

From ccleary at openjdk.org  Mon Oct  9 10:22:50 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 10:22:50 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v2]
In-Reply-To: <zbg-xusZbheKNtz4dVSPQ4oIKdMJVB01rehwNKlAgqw=.2cab77e3-bb2e-44f2-804c-59bbb99a6f59@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <zbg-xusZbheKNtz4dVSPQ4oIKdMJVB01rehwNKlAgqw=.2cab77e3-bb2e-44f2-804c-59bbb99a6f59@github.com>
Message-ID: <9DwHRpobaVOvQ72afzpTgR5mvlUFKTPIVYqoA2qTM0M=.a3d73247-ca5b-4071-b765-ce9aa13088e1@github.com>

On Wed, 20 Sep 2023 09:51:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: Cleanup identifiers and whitespace

This PR is now updated and ready for review again. A few fundamentals with regard to initial incorrect assumptions about the behaviour of HttpClient have been addressed. As a result the testing of these changes and the client in these RST_STREAM cases have changed quite a bit from the orignal posting. Fixes of various intermittent failures detected by running test cases included with this PR are also included. I will be updating the PR description to reflect this. 

Edit: PR description is updated

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1752579030

From redestad at openjdk.org  Mon Oct  9 10:26:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Oct 2023 10:26:54 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <IUbx0WCq3BLfQQ8C5ExcyGDE37Aw23V_sy1c0NMBZ2Q=.1cf6d6c9-9361-4a9d-bae3-fffdc3a548e7@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

I can't find any in the java.base module, but outside of java.base there are a few candidate such as `javax.management.remote.JMXServiceURL` and `com.sun.tools.javac.jvm.PoolReader`. Why?

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752713940

From duke at openjdk.org  Mon Oct  9 10:26:58 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 10:26:58 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <NwsoEHd4y4Uj-6gHyxL0kGdQHw_NC95GF3pbt_E9wMI=.347cd3ff-79eb-4ba4-9849-6e87827cef78@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

OK, I agree with you, this optimization should be handled in ImmutableBitSetPredicate, I will close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1752734662

From dfuchs at openjdk.org  Mon Oct  9 13:40:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Oct 2023 13:40:18 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
Message-ID: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>

On Mon, 9 Oct 2023 10:22:39 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary 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 ten additional commits since the last revision:
> 
>  - 8309118: Fixed error in handleReset ReentrantLock
>  - 8309118: Updates to Stream cancelImpl
>  - 8309118: Refactored test, updated incoming_reset
>  - Merge branch 'master' into JDK-8309118
>  - 8309118: Cleanup identifiers and whitespace
>  - 8309118: Removed unused try-with-resources
>  - 8309118: Improve comments and annotations
>  - 8309118: Remove local test timeout value
>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 234:

> 232:                 connections.values().forEach(this::close);
> 233:                 connections.remove(entry.getKey(), entry.getValue());
> 234:             }

I'd suggest to change `this::close(Http2Connection)` to return boolean (instead of void) and make it always return`true`, and then use `removeIf` instead of forEach:


connections.values().removeIf(this::close);

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 193:

> 191:                 if (frame instanceof ResetFrame rf) {
> 192:                     inputQ.remove();
> 193:                     if (endStreamReceived()) {

Suggestion:

                    if (endStreamReceived() && rf.getErrorCode() == ResetFrame.NO_ERROR) {

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 195:

> 193:                     if (endStreamReceived()) {
> 194:                         // If END_STREAM is already received, we should not receive any new RST_STREAM frames and
> 195:                         // close the connection gracefully by processing all remaining frames in the inputQ.

Suggestion:

                        // If END_STREAM is already received, we should we should simply
                        // complete the requestBodyCF successfuly and stop sending any
                        // request data.

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 484:

> 482:         if (debug.on()) debug.log("incoming: %s", frame);
> 483:         var cancelled = checkRequestCancelled() || closed;
> 484: //        endStreamSeen = endStreamSeen || frame.getFlag(HeaderFrame.END_STREAM);

leftover to be removed?

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 584:

> 582:     void incoming_reset(ResetFrame frame) {
> 583:         Log.logTrace("Received RST_STREAM on stream {0}", streamid);
> 584:         Flow.Subscriber<?> subscriber = responseSubscriber == null ? pendingResponseSubscriber : responseSubscriber;

Suggestion:

        Flow.Subscriber<?> subscriber = responseSubscriber;
        if (subscriber == null) subscriber = pendingResponseSubscriber;

(avoids reading volatile twice)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350308126
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350315812
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350312683
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350316732
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350319468

From dfuchs at openjdk.org  Mon Oct  9 13:49:19 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Oct 2023 13:49:19 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
Message-ID: <okCQowXBB1IEpadZ7ayaxRWxW5xXvYUfCm4Po1nE750=.f62213b1-23a8-438d-b577-51d7a556108e@github.com>

On Mon, 9 Oct 2023 10:22:39 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary 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 ten additional commits since the last revision:
> 
>  - 8309118: Fixed error in handleReset ReentrantLock
>  - 8309118: Updates to Stream cancelImpl
>  - 8309118: Refactored test, updated incoming_reset
>  - Merge branch 'master' into JDK-8309118
>  - 8309118: Cleanup identifiers and whitespace
>  - 8309118: Removed unused try-with-resources
>  - 8309118: Improve comments and annotations
>  - 8309118: Remove local test timeout value
>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 635:

> 633:                 closed = true;
> 634:             } finally {
> 635:                 stateLock.unlock();

Ouch! I am to blame for this one. It's a regression introduced by JDK-8308310. This one needs to be backported to JDK 21. Let me see if I should prepare a PR for that.

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 648:

> 646:                 completeResponseExceptionally(e);
> 647:                 if (!requestBodyCF.isDone()) {
> 648:                     if (debug.on()) debug.log("\nHERE");

remove this line?

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 652:

> 650:                 }
> 651:                 if (responseBodyCF != null) {
> 652:                     if (debug.on()) debug.log("\nALSO HERE");

... and this one?

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1090:

> 1088:                 } while (outgoing.peekFirst() != null);
> 1089: 
> 1090:                 // TODO: Maybe throw exception here to fix intermittent error?

Leftover?

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1112:

> 1110:         }
> 1111: 
> 1112:         // TODO: We could put the check for END_STREAM received here?

Leftover?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350329648
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350330046
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350330398
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350330745
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350331104

From dfuchs at openjdk.org  Mon Oct  9 13:56:05 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Oct 2023 13:56:05 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <okCQowXBB1IEpadZ7ayaxRWxW5xXvYUfCm4Po1nE750=.f62213b1-23a8-438d-b577-51d7a556108e@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <okCQowXBB1IEpadZ7ayaxRWxW5xXvYUfCm4Po1nE750=.f62213b1-23a8-438d-b577-51d7a556108e@github.com>
Message-ID: <-Z4KpAacLXG-eZ52pykjUc1HDl-hgoSOKRaiPdHcBkM=.1792f311-abe3-4397-850a-176d16944d57@github.com>

On Mon, 9 Oct 2023 13:43:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 635:
> 
>> 633:                 closed = true;
>> 634:             } finally {
>> 635:                 stateLock.unlock();
> 
> Ouch! I am to blame for this one. It's a regression introduced by JDK-8308310. This one needs to be backported to JDK 21. Let me see if I should prepare a PR for that.

https://github.com/openjdk/jdk/pull/16101

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350342203

From dfuchs at openjdk.org  Mon Oct  9 14:02:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Oct 2023 14:02:27 GMT
Subject: RFR: 8317736: Stream::handleReset locks twice
Message-ID: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>

Trivial one liner fix.

The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In Stream::handleReset the lock is locked twice.

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

Commit messages:
 - 8317736

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

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

From ccleary at openjdk.org  Mon Oct  9 14:07:17 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 14:07:17 GMT
Subject: RFR: 8317736: Stream::handleReset locks twice
In-Reply-To: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
References: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
Message-ID: <ueh4CvoCAEv5E_-9abjahqGsO-Luxp8St8TNJ-fsoNY=.d539aab5-700d-4668-9ed5-b1ffebddb6fd@github.com>

On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivial one liner fix.
> 
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In Stream::handleReset the lock is locked twice.

LGTM.

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

Marked as reviewed by ccleary (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16101#pullrequestreview-1664529328

From djelinski at openjdk.org  Mon Oct  9 14:14:58 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Oct 2023 14:14:58 GMT
Subject: RFR: 8317736: Stream::handleReset locks twice
In-Reply-To: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
References: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
Message-ID: <-z432ucLBECTvfDRRZ9K-XnyCisu86SYclKbOqL5nmc=.3aa7b9d1-a27b-4429-a297-22b683194243@github.com>

On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivial one liner fix.
> 
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In Stream::handleReset the lock is locked twice.

I suppose you could also mark it noreg-trivial...

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16101#pullrequestreview-1664545068

From jpai at openjdk.org  Mon Oct  9 14:33:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Oct 2023 14:33:00 GMT
Subject: RFR: 8317736: Stream::handleReset locks twice
In-Reply-To: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
References: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
Message-ID: <FFLL6qZY2lLyG64EYWouC1VcLerwVT--xcP1wLf6aV4=.2a267507-83c9-4317-8814-d5a9920a3488@github.com>

On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivial one liner fix.
> 
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In Stream::handleReset the lock is locked twice.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16101#pullrequestreview-1664591887

From redestad at openjdk.org  Mon Oct  9 14:38:00 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Oct 2023 14:38:00 GMT
Subject: RFR: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <EKEL2ZPxrR-5oncPxZq2IUr_ym3i8MDX3oNmDaoZp3s=.94c95235-38e7-4c92-91d8-ff8be473d0cd@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

Ok, I've cleaned up #16094 and added some sanity tests. Ok if I repurpose the JBS bug for #16094?

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

PR Comment: https://git.openjdk.org/jdk/pull/16082#issuecomment-1753132150

From djelinski at openjdk.org  Mon Oct  9 14:43:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Oct 2023 14:43:10 GMT
Subject: RFR: 8317696: Fix compilation with clang-16
In-Reply-To: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
Message-ID: <lIkW2cf_xYr0oLyPZmwRh-6KpXUHtGzibbja-ZTDidg=.d02f2f90-dc60-419e-9c40-bb76d053c4a5@github.com>

On Sat, 7 Oct 2023 16:24:29 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
> 
> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
> 
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>                                         ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>                                                               ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             phost = (*g_network_address_get_hostname)(conn);
>                                                                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             pport = (*g_network_address_get_port)(conn);
>                                                                  ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_strfreev)(proxies);
>                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_clear_error)(&error);
>                         ^
> Compiling X11Renderer.c (for libawt_headless.so)
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h:29:
> src/java.desktop/unix/native/common/aw...

Changes requested by djelinski (Reviewer).

src/java.base/unix/native/libnet/DefaultProxySelector.c line 96:

> 94: typedef GProxyResolver* g_proxy_resolver_get_default_func(void);
> 95: typedef char** g_proxy_resolver_lookup_func(GProxyResolver* resolver, char* uri, void *null, GError **error_p);
> 96: typedef GSocketConnectable* g_network_address_parse_uri_func(char* proxy, int zero, GError **error_p);

Suggestion:

typedef GSocketConnectable* g_network_address_parse_uri_func(char* proxy, unsigned short default_port, GError **error_p);

https://developer-old.gnome.org/gio/stable/GNetworkAddress.html#g-network-address-parse-uri

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 218:

> 216: static GtkWidget* (*fp_gtk_menu_bar_new)();
> 217: static GtkWidget* (*fp_gtk_menu_item_new)();
> 218: static GtkWidget* (*fp_gtk_notebook_new)(void);

This change is inconsistent with the surrounding style; I'd keep the original declaration, and only remove the NULL in function calls.

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

PR Review: https://git.openjdk.org/jdk/pull/16092#pullrequestreview-1664342423
PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1350242526
PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1350396505

From jkratochvil at openjdk.org  Mon Oct  9 14:54:14 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 9 Oct 2023 14:54:14 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v2]
In-Reply-To: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
Message-ID: <3qea9Ojjc6Q317U6dJHiY8_EwdMvnKweDTeSd_dqQzU=.9b5734d6-b122-4852-90a3-113df5defaaa@github.com>

> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
> 
> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
> 
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>                                         ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>                                                               ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             phost = (*g_network_address_get_hostname)(conn);
>                                                                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             pport = (*g_network_address_get_port)(conn);
>                                                                  ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_strfreev)(proxies);
>                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_clear_error)(&error);
>                         ^
> Compiling X11Renderer.c (for libawt_headless.so)
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h:29:
> src/java.desktop/unix/native/common/aw...

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/unix/native/libnet/DefaultProxySelector.c
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - Update also gtk3_interface.h prototypes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16092/files
  - new: https://git.openjdk.org/jdk/pull/16092/files/05c4054d..6c2c2f87

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

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

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

From jkratochvil at openjdk.org  Mon Oct  9 15:01:45 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 9 Oct 2023 15:01:45 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <lIkW2cf_xYr0oLyPZmwRh-6KpXUHtGzibbja-ZTDidg=.d02f2f90-dc60-419e-9c40-bb76d053c4a5@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <lIkW2cf_xYr0oLyPZmwRh-6KpXUHtGzibbja-ZTDidg=.d02f2f90-dc60-419e-9c40-bb76d053c4a5@github.com>
Message-ID: <2tYOw3UPK-A_WyEI7zHIazNX5-6Ad69bZbYd799AiwQ=.770053ff-b482-4c76-9afb-48d3a36111ae@github.com>

On Mon, 9 Oct 2023 14:38:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove declaration changes which are not required
>>    - suggested by djelinski
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 218:
> 
>> 216: static GtkWidget* (*fp_gtk_menu_bar_new)();
>> 217: static GtkWidget* (*fp_gtk_menu_item_new)();
>> 218: static GtkWidget* (*fp_gtk_notebook_new)(void);
> 
> This change is inconsistent with the surrounding style; I'd keep the original declaration, and only remove the NULL in function calls.

I did not notice it is not required to change the prototype. OK, it works without this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1350418413

From jkratochvil at openjdk.org  Mon Oct  9 15:01:41 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 9 Oct 2023 15:01:41 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
Message-ID: <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>

> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
> 
> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
> 
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>                                         ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>                                                               ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             phost = (*g_network_address_get_hostname)(conn);
>                                                                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             pport = (*g_network_address_get_port)(conn);
>                                                                  ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_strfreev)(proxies);
>                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_clear_error)(&error);
>                         ^
> Compiling X11Renderer.c (for libawt_headless.so)
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h:29:
> src/java.desktop/unix/native/common/aw...

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

  Remove declaration changes which are not required
   - suggested by djelinski

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16092/files
  - new: https://git.openjdk.org/jdk/pull/16092/files/6c2c2f87..fa2c32e4

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

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

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

From ccleary at openjdk.org  Mon Oct  9 15:44:07 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 15:44:07 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
Message-ID: <u1QntAmP-URLKiPHdRVbRmb01U06pdR7DEkiyIBkir8=.5e3b568c-371c-4d24-ba64-155be0ec2cd7@github.com>

On Mon, 9 Oct 2023 13:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 484:
> 
>> 482:         if (debug.on()) debug.log("incoming: %s", frame);
>> 483:         var cancelled = checkRequestCancelled() || closed;
>> 484: //        endStreamSeen = endStreamSeen || frame.getFlag(HeaderFrame.END_STREAM);
> 
> leftover to be removed?

Correct, from an older iteration. Will remove

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1350471672

From ccleary at openjdk.org  Mon Oct  9 15:54:07 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 15:54:07 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v4]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <_sGKprbaziML6UKpEzAF2YGHCQ8WcddHYC9zfKuDKtc=.f89420c5-9620-4678-8fdb-7b1c74f1889e@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

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

  8309118: Remove irrelevant comments and logs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/909783b2..94e2e1d2

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

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

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

From ccleary at openjdk.org  Mon Oct  9 15:54:14 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 9 Oct 2023 15:54:14 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
Message-ID: <wMv_YHKBuNmAcmr0xUyCo6BTT7qzDIyPAns8RupGHtE=.38f3d97c-076b-4d7b-be7e-09a562967a5e@github.com>

On Mon, 9 Oct 2023 10:22:39 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary 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 ten additional commits since the last revision:
> 
>  - 8309118: Fixed error in handleReset ReentrantLock
>  - 8309118: Updates to Stream cancelImpl
>  - 8309118: Refactored test, updated incoming_reset
>  - Merge branch 'master' into JDK-8309118
>  - 8309118: Cleanup identifiers and whitespace
>  - 8309118: Removed unused try-with-resources
>  - 8309118: Improve comments and annotations
>  - 8309118: Remove local test timeout value
>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2

Apologies for leaving those irrelevant comments and logs in, I tend to leave plenty of them around as I work to get a good idea of whats going on. I removed them all in the latest commit and will address the other comments you had @dfuch soon

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1753258843

From vtewari at openjdk.org  Mon Oct  9 16:07:55 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 9 Oct 2023 16:07:55 GMT
Subject: RFR: 8317736: Stream::handleReset locks twice
In-Reply-To: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
References: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
Message-ID: <S72jcloJ26Y9XCmAj2EVWvBFpr_YLIK8Hru_Wq8B8cg=.745dad9d-fd71-4cdf-88f1-140afb9ab89a@github.com>

On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivial one liner fix.
> 
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In Stream::handleReset the lock is locked twice.

Looks OK

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16101#pullrequestreview-1664874649

From dfuchs at openjdk.org  Mon Oct  9 16:35:09 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Oct 2023 16:35:09 GMT
Subject: Integrated: 8317736: Stream::handleReset locks twice
In-Reply-To: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
References: <njRmY1nnWfuFdDieIcx7eLzjUtHHhMAXzpmnuMPJOso=.de9999a5-6613-45c2-aeb1-1fb5cde4c749@github.com>
Message-ID: <yRklk2H59pmmpn7A6qMPXKeckrotL4NDvEk57Fln1FY=.59e3f256-a484-4b46-8762-bb3113fbc2a1@github.com>

On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Trivial one liner fix.
> 
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310) introduced a reentrant `stateLock` but also a regression. In `Stream::handleReset` the lock is locked twice.

This pull request has now been integrated.

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

8317736: Stream::handleReset locks twice

Reviewed-by: ccleary, djelinski, jpai, vtewari

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

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

From aivanov at openjdk.org  Mon Oct  9 18:37:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Oct 2023 18:37:00 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
Message-ID: <K6aKkaHZniUtziqIh1mlc86AGPjr1SR4cd2-MRPwlEg=.e3444e71-de64-4e37-b088-98abe5cd591e@github.com>

On Mon, 9 Oct 2023 15:01:41 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
>> 
>> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
>> 
>> 
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>>                                         ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>>                                                               ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             phost = (*g_network_address_get_hostname)(conn);
>>                                                                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             pport = (*g_network_address_get_port)(conn);
>>                                                                  ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_strfreev)(proxies);
>>                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_clear_error)(&error);
>>                         ^
>> Compiling X11Renderer.c (for libawt_headless.so)
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11Surf...
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove declaration changes which are not required
>    - suggested by djelinski

The changes for `java.desktop` look good to me.

src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h line 53:

> 51: #define MITSHM_PERM_OWNER  (0600)
> 52: 
> 53: extern int XShmQueryExtension(Display* dpy);

I wonder if it's even needed here: the declaration should come from `X11/extensions/XShm.h` which is included.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16092#pullrequestreview-1665070667
PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1350667139

From duke at openjdk.org  Mon Oct  9 18:38:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 18:38:10 GMT
Subject: Withdrawn: 8317698: Optimization for URLEncoder
In-Reply-To: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
References: <yd_bnK7dsq0kB90qTeqzAb6lBz70wfwWdg7Vd-k3X1E=.9930e700-a8b9-45ae-a566-1583e0d5bddf@github.com>
Message-ID: <8z6GTLgDcMCi5d6zDba8GQNta-kuKrmKK-9_wtk4m2Y=.35165c64-1eb1-41de-a38a-37a05316a40b@github.com>

On Fri, 6 Oct 2023 20:55:40 GMT, ??? <duke at openjdk.org> wrote:

> @cl4es and @Glavo have already made some very good optimizations to URLEncoder, but we can continue to improve.
> 
> The current URLEncoder's Predicate for DONT_NEED_ENCODING is based on BitSet, which is actually a table lookup. The actual performance may not be as good as microbench. 
> 
> The character value range of DONT_NEED_ENCODING is between [45-122]. We can construct two long type constants to do the work of BitSet. This can improve performance by about 7% to 30%.

This pull request has been closed without being integrated.

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

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

From djelinski at openjdk.org  Mon Oct  9 18:42:00 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Oct 2023 18:42:00 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
Message-ID: <X1r9HziKDsObpBVDSVuIigcOhVWypqUV1AG9a4vhsDE=.73e71adf-34f0-4254-b0be-dd9918641d11@github.com>

On Mon, 9 Oct 2023 15:01:41 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
>> 
>> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
>> 
>> 
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>>                                         ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>>                                                               ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             phost = (*g_network_address_get_hostname)(conn);
>>                                                                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             pport = (*g_network_address_get_port)(conn);
>>                                                                  ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_strfreev)(proxies);
>>                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_clear_error)(&error);
>>                         ^
>> Compiling X11Renderer.c (for libawt_headless.so)
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11Surf...
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove declaration changes which are not required
>    - suggested by djelinski

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16092#pullrequestreview-1665089916

From aefimov at openjdk.org  Tue Oct 10 15:08:24 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Oct 2023 15:08:24 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.7acf31c6-1b7f-48fe-a7d5-bf45eb631884@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.7acf31c6-1b7f-48fe-a7d5-bf45eb631884@github.com>
Message-ID: <jI1iULzKyB_z2w_J6BOrSCkroT9jVf1XHruwPpyF_YI=.26b0a153-c5e2-420b-a79a-289523f9975c@github.com>

On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Aleksei, it's good to see the addition of these new APIs. On the naming front, I like the 

Hello Jaikiran

> The proposed changes also have text which talks about "ambiguous" address literals. The term ambiguous seems new in the InetAddress (and sub-classes). The package-info.java too doesn't have previous references to it.

What ambiguous IPv4 address literals mean in the code and in [the release notes](https://www.oracle.com/java/technologies/javase/18all-relnotes.html#JDK-8277608): it is a set of addresses which can't be parsed in dotted-decimal forms listed in the Inet4Address#format class-level javadoc section, but can be parsed in BSD forms (decimal, octal, or hexadecimal) defined in [`inet_addr` of IEEE Std 1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html).

> Should we add some details on what addresses are considered ambiguous (and how/if such addresses are treated by existing APIs)?

The release note states that the `InetAddress` accepts IPv4 address literals in decimal quad notation. The new `ofLiteral` API also states that only dotted-decimal forms are supported, `ambigous` term is not mentioned in any public javadoc, and given that the related system property is a jdk-specific system property I would like to avoid introducing this term as part of this PR. 

> do you think we should add a more formal reference to the BSD formatting of IP address

I think a more formal reference to BSD forms might be needed if they are recognizable by InetAddress APIs. As of today, this is not the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1755647174

From aefimov at openjdk.org  Tue Oct 10 15:13:20 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Oct 2023 15:13:20 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <sXD4KqQX8DZR5e03H1BopbP-BGBxUdbP9z6t6O7KJNM=.fdb5d9e6-b875-42e0-90ae-e39d1afacfb5@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <sXD4KqQX8DZR5e03H1BopbP-BGBxUdbP9z6t6O7KJNM=.fdb5d9e6-b875-42e0-90ae-e39d1afacfb5@github.com>
Message-ID: <DI6wEDZMr3C8d-vqEwsGFsxWbEAODyBvqT6i4bwC1m0=.cfa4a599-629e-424c-89dc-abea1948b92b@github.com>

On Mon, 9 Oct 2023 07:12:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>>  - add null checks and NPE to methods javadoc
>
> src/java.base/share/classes/java/net/Inet4Address.java line 181:
> 
>> 179:     /**
>> 180:      * Parses string with an IPv4 address literal.
>> 181:      * If string doesn't contain a valid literal - null is returned.
> 
> This sentence is a bit confusing, given the implementation details of this method. I think `null` is only returned if `throwIAE` is false?

Thank you for spotting it. I have updated the javadoc of the `parseAddressString` method to contain all three possible scenarios:

     * If string contains a non-parsable literal and {@code throwIAE} is set to {@code false}
     * - {@code null} is returned.
     * If string contains a non-parsable literal and {@code throwIAE} is set to {@code true}
     * - {@code IllegalArgumentException} is thrown.
     * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
     * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
     * {@code throwIAE} value.

> src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 141:
> 
>> 139:      * @param src input string
>> 140:      * @param throwIAE {@code "true"} - throw {@code IllegalArgumentException} when cannot be parsed as IPv4 address string;
>> 141:      *                 {@code "false"} - throw {@code "IllegalArgumentException"} only when IPv4 address string is ambiguous.
> 
> Are these double quotes around `true`, `false`, `null` and `IllegalArgumentException` intentional? It seems odd to have those double quotes when (rightly) using `{@code}`.

Nope, there are not intentional - a leftover from the fix prototyping stage. Will remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352771068
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352772971

From michaelm at openjdk.org  Tue Oct 10 15:44:13 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 10 Oct 2023 15:44:13 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
Message-ID: <xDiXVNDqoRpVg7LGJZ5rxnfYm8TJ2xdfase6i_z1rPU=.d5ada882-8530-4004-b883-9a6a4e104d3d@github.com>

On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc

src/java.base/share/classes/java/net/Inet4Address.java line 163:

> 161:      *  Inet4Address.ofLiteral("02130706689") ==> /127.0.1.1
> 162:      * }
> 163:      * <p>If the provided address literal cannot represent a valid IPv4 address an

I think this behavior is the same as existing methods, except that only the decimal format is supported? I wonder is it really necessary to describe it here, as it it would be quite an arcane usage, and the section in the class doc "Textual representation if IP addresses" already partially covers it. The snippet example with the leading zero seems to be implying that octal format is not supported, but without really saying it out loud. 

Maybe the apidoc for the method could just say that the decimal formats are the only ones supported, but otherwise refer to the class docs for how the different variants work ? And maybe move the snippet there as well?

src/java.base/share/classes/java/net/Inet6Address.java line 525:

> 523:      *         parsed as an IPv6 address literal.
> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
> 525:      */

Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352797174
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352812605

From michaelm at openjdk.org  Tue Oct 10 16:20:14 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 10 Oct 2023 16:20:14 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <xDiXVNDqoRpVg7LGJZ5rxnfYm8TJ2xdfase6i_z1rPU=.d5ada882-8530-4004-b883-9a6a4e104d3d@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <xDiXVNDqoRpVg7LGJZ5rxnfYm8TJ2xdfase6i_z1rPU=.d5ada882-8530-4004-b883-9a6a4e104d3d@github.com>
Message-ID: <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.7f528cdb-0811-4f70-b7b4-5a96a68f6acb@github.com>

On Tue, 10 Oct 2023 15:40:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>>  - add null checks and NPE to methods javadoc
>
> src/java.base/share/classes/java/net/Inet6Address.java line 525:
> 
>> 523:      *         parsed as an IPv6 address literal.
>> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
>> 525:      */
> 
> Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.

My mistake, it looks like we don't support the octal or hexadecimal formats in the existing `getByName` method, which is good news!

But, I think the comments above still apply in terms of moving the snippets to the class level docs, and maybe specifying there also that we only support the decimal literals

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352862018

From aefimov at openjdk.org  Tue Oct 10 16:42:14 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Oct 2023 16:42:14 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v3]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
Message-ID: <24cauXWCzLb4UoF8E9PmS8_KI_rFiX-LY0qPNEuvbQM=.9beef864-6af8-408d-a52f-8e472c8a64cf@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

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

 - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
 - update javadoc of internal utility methods.
 - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
 - add null checks and NPE to methods javadoc
 - 8272215: Add InetAddress methods for parsing IP address literals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/e72c2c96..6b7ff713

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

  Stats: 50909 lines in 1164 files changed: 28769 ins; 14746 del; 7394 mod
  Patch: https://git.openjdk.org/jdk/pull/15775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15775/head:pull/15775

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

From dfuchs at openjdk.org  Tue Oct 10 17:23:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Oct 2023 17:23:18 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v3]
In-Reply-To: <24cauXWCzLb4UoF8E9PmS8_KI_rFiX-LY0qPNEuvbQM=.9beef864-6af8-408d-a52f-8e472c8a64cf@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <24cauXWCzLb4UoF8E9PmS8_KI_rFiX-LY0qPNEuvbQM=.9beef864-6af8-408d-a52f-8e472c8a64cf@github.com>
Message-ID: <SzPaN3rHZd_5Gsd-elKu6yHl7xfg9CHI56E7n4B3SLM=.a71164c3-52d4-4eff-a166-0f2d44184914@github.com>

On Tue, 10 Oct 2023 16:42:14 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
>  - update javadoc of internal utility methods.
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - add null checks and NPE to methods javadoc
>  - 8272215: Add InetAddress methods for parsing IP address literals

src/java.base/share/classes/java/net/Inet4Address.java line 180:

> 178: 
> 179:     /**
> 180:      * Parses string as an IPv4 address literal.

Suggestion:

     * Parses the given string as an IPv4 address literal.

src/java.base/share/classes/java/net/Inet4Address.java line 182:

> 180:      * Parses string as an IPv4 address literal.
> 181:      * If string contains a non-parsable literal and {@code throwIAE} is set to {@code false}
> 182:      * - {@code null} is returned.

Suggestion:

     * If the given {@code addressLiteral} string cannot be parsed as an IPv4 address literal 
     * and {@code throwIAE} is {@code false}, {@code null} is returned.

src/java.base/share/classes/java/net/Inet4Address.java line 184:

> 182:      * - {@code null} is returned.
> 183:      * If string contains a non-parsable literal and {@code throwIAE} is set to {@code true}
> 184:      * - {@code IllegalArgumentException} is thrown.

Suggestion:

     * If the given {@code addressLiteral} string cannot be parsed as an IPv4 address literal
     * and {@code throwIAE} is {@code true}, an {@code IllegalArgumentException} is thrown.

src/java.base/share/classes/java/net/Inet4Address.java line 190:

> 188:      * @param addressLiteral IPv4 address literal to parse
> 189:      * @param throwIAE throw {@code IllegalArgumentException} if the
> 190:      *                 literal cannot be parsed as an IPv4 address literal.

Suggestion:

     * @param throwIAE whether to throw {@code IllegalArgumentException} if the
     *                 given {@code addressLiteral} string cannot be parsed as
     *                 an IPv4 address literal.

src/java.base/share/classes/java/net/Inet4Address.java line 195:

> 193:      * @throws IllegalArgumentException if ambiguous IPv4 literal is specified,
> 194:      * or non-parsable IPv4 literal is specified with {@code throwIAE} set to
> 195:      * {@code true}.

* @throws IllegalArgumentException if the given {@code addressLiteral} string
     *    cannot be parsed as an IPv4 address literal and {@code throwIAE} is {@code true}.
     *    An {@code IllegalArgumentException} is also thrown regardless of the value of 
     *    {@code throwIAE} if the given {@code addressLiteral} string is ambiguous, that is,
     *    it cannot be parsed as a valid IPv4 address literal using decimal notation but could be
     *    interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352956961
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352979935
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352986216
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1353001177
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1353026855

From prr at openjdk.org  Tue Oct 10 20:39:47 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Oct 2023 20:39:47 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <K6aKkaHZniUtziqIh1mlc86AGPjr1SR4cd2-MRPwlEg=.e3444e71-de64-4e37-b088-98abe5cd591e@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
 <K6aKkaHZniUtziqIh1mlc86AGPjr1SR4cd2-MRPwlEg=.e3444e71-de64-4e37-b088-98abe5cd591e@github.com>
Message-ID: <eSbki14oaBmOOswZkIR3FPbexH4TzKlR_7Ba1t65Igg=.0b77e76f-1739-45b5-b2d7-5f973f337a95@github.com>

On Mon, 9 Oct 2023 18:29:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove declaration changes which are not required
>>    - suggested by djelinski
>
> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h line 53:
> 
>> 51: #define MITSHM_PERM_OWNER  (0600)
>> 52: 
>> 53: extern int XShmQueryExtension(Display* dpy);
> 
> I wonder if it's even needed here: the declaration should come from `X11/extensions/XShm.h` which is included.

I agree, but I wonder why it was ever added ? Near as I can tell its been there since the SHM code was added in 1.4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1353307160

From mbaesken at openjdk.org  Wed Oct 11 08:08:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 08:08:05 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
Message-ID: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>

When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

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

Commit messages:
 - JDK-8317866

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

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

From jkratochvil at openjdk.org  Wed Oct 11 09:27:30 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 11 Oct 2023 09:27:30 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v4]
In-Reply-To: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
Message-ID: <YRtrQNFsaYl3Xn6aKqpD8jLk24Pt0mSYTOeEatffycU=.38e7b7f9-bbec-4f89-aecc-16c064dac6ba@github.com>

> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
> 
> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
> 
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>                                         ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>                                                               ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             phost = (*g_network_address_get_hostname)(conn);
>                                                                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             pport = (*g_network_address_get_port)(conn);
>                                                                  ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_strfreev)(proxies);
>                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_clear_error)(&error);
>                         ^
> Compiling X11Renderer.c (for libawt_headless.so)
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h:29:
> src/java.desktop/unix/native/common/aw...

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

  Remove the XShmQueryExtension declaration completely.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16092/files
  - new: https://git.openjdk.org/jdk/pull/16092/files/fa2c32e4..8e0d079c

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

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

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

From jkratochvil at openjdk.org  Wed Oct 11 09:27:33 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 11 Oct 2023 09:27:33 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v3]
In-Reply-To: <eSbki14oaBmOOswZkIR3FPbexH4TzKlR_7Ba1t65Igg=.0b77e76f-1739-45b5-b2d7-5f973f337a95@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <Ikv7MGPEC-ASJ5BpAdIEBNqLLgRV38wbMx3ygTLGaP8=.72917dcb-286a-4580-8fe7-f950976ce1cb@github.com>
 <K6aKkaHZniUtziqIh1mlc86AGPjr1SR4cd2-MRPwlEg=.e3444e71-de64-4e37-b088-98abe5cd591e@github.com>
 <eSbki14oaBmOOswZkIR3FPbexH4TzKlR_7Ba1t65Igg=.0b77e76f-1739-45b5-b2d7-5f973f337a95@github.com>
Message-ID: <p9ieH7W0hWfye-JJh77mGEvLhBqhCfYS0mhf2uX-VQU=.416cbc6c-562c-49b4-9ec7-88057cf7b532@github.com>

On Tue, 10 Oct 2023 20:37:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h line 53:
>> 
>>> 51: #define MITSHM_PERM_OWNER  (0600)
>>> 52: 
>>> 53: extern int XShmQueryExtension(Display* dpy);
>> 
>> I wonder if it's even needed here: the declaration should come from `X11/extensions/XShm.h` which is included.
>
> I agree, but I wonder why it was ever added ? Near as I can tell its been there since the SHM code was added in 1.4

So I have removed the declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16092#discussion_r1354546381

From dfuchs at openjdk.org  Wed Oct 11 10:33:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Oct 2023 10:33:50 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber registered
Message-ID: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>

Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.

The issue appears to be a race condition between cancelImpl and schedule where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.

A simple fix is to ensure that cancelImpl will complete the subscriber, if needed.

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

Commit messages:
 - 8317808

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

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

From dfuchs at openjdk.org  Wed Oct 11 10:45:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Oct 2023 10:45:10 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <lFGgC6Mt7IyABYSGSn1u2C3QJRVqCgXb-gs5pW6Wo8Y=.e274ae84-7a14-46d2-a5d8-e888d0eab894@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

This looks reasonable. Thanks for the cleanup! 
Let me run some test before approving.

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670752677

From alanb at openjdk.org  Wed Oct 11 11:11:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Oct 2023 11:11:15 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <GFNSW49zXHZWQrB7g56yH5ug0JftvKALSRSi_mdLuZQ=.d7cf22b6-c39b-4a4b-b287-ef77d6f424f9@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670860910

From dfuchs at openjdk.org  Wed Oct 11 16:40:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Oct 2023 16:40:23 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <OijHB1TVVmIeCUpk7wxH3pUjWN9MhLPkaK4LID4CAk0=.b4a4136c-1ef9-4636-b597-04dfd899183c@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1671817764

From mbaesken at openjdk.org  Thu Oct 12 07:25:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:25:23 GMT
Subject: RFR: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <2LvAHcncM4Kz_4yLH4KfixikvW2sV087KwHsJnsSKCc=.cf19c19b-ffa0-4806-9d84-cb6f373edca5@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

Hi Daniel and Alan, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16139#issuecomment-1759071633

From mbaesken at openjdk.org  Thu Oct 12 07:25:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 07:25:25 GMT
Subject: Integrated: JDK-8317866: replace NET_SocketAvailable
In-Reply-To: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
References: <Azhdmv542wy1ShKjmPOEXS8By5T1mJ0G0_0Dy-G1Bao=.d4cac16c-52e2-4bc3-b59b-1ad047064284@github.com>
Message-ID: <fMY7ZqSD1-jPkWvncEhQRaQbV1nad6q1qlKMZtuel4o=.9a3062ce-bb95-4668-a532-c22c4efdb77d@github.com>

On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced.

This pull request has now been integrated.

Changeset: 424de295
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/424de295a6ca19e9aacb7e1e1c9b5f955064cb65
Stats:     34 lines in 4 files changed: 4 ins; 27 del; 3 mod

8317866: replace NET_SocketAvailable

Reviewed-by: dfuchs, alanb

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

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

From alanb at openjdk.org  Thu Oct 12 13:07:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 13:07:48 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <mZJG405OGCCOoErDvTWUzvuGHCh1RANxV6ihIf3qfeM=.bec16d07-b069-43ee-bddf-305430e460f4@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Changes in this area only require one reviewer so it's okay to integrate if you want.

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759495468

From dfuchs at openjdk.org  Thu Oct 12 14:02:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Oct 2023 14:02:04 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <Z95zxmawwZ75gFm0AYzrOs8sss07-NBokjjNxUPScJw=.5dd45b54-794e-44a3-8e24-2af5d6908ddb@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

LGTM - I was expecting @tprinzing to review too, but yes you can integrate if you want.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1674252334

From mbaesken at openjdk.org  Thu Oct 12 14:10:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 14:10:25 GMT
Subject: RFR: JDK-8318006: remove unused net related coding
Message-ID: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>

[JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old socket implementation code but it did leave some unused code behind, it would be good to remove these unused functions.

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

Commit messages:
 - JDK-8318006

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

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

From alanb at openjdk.org  Thu Oct 12 14:26:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 14:26:41 GMT
Subject: RFR: JDK-8318006: remove unused net related coding
In-Reply-To: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
References: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
Message-ID: <KPmraz7QY2PtpNYg3UrIZbdqhZhhPK8Z2os7nwI2tAQ=.107e4e0d-ebe0-41cc-86c4-559be0795f46@github.com>

On Thu, 12 Oct 2023 13:14:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old socket implementation code but it did leave some unused code behind, it would be good to remove these unused functions.

Looks okay, I wonder if the list of include files can be pruned as part of this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16164#pullrequestreview-1674300699

From tprinzing at openjdk.org  Thu Oct 12 14:47:38 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 12 Oct 2023 14:47:38 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <UT31A_j03xq6DCG7IBBxfPEZ18I13iGCkHvzuJx5o9U=.2660ea5c-916b-4a46-90d2-dc6ca164d067@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

I was planning to change the convenience function to take functions as arguments.  With this change there is a bunch of duplicated code.

I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759755174

From egahlin at openjdk.org  Thu Oct 12 15:51:28 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Oct 2023 15:51:28 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <5CpsTt095Fp76yWPbqfYuiWBqB5HoJPyTIhkNifUBP8=.73812635-fefd-4fd3-8366-484bb9e0c0c6@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

> I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code.
> 
> I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.



> I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code.
> 
> I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this.

If it's a lambda, it could be problematic. I have another change coming up, which also motivated this PR. It's still in draft, need to decide on the syntax, but it adds an annotation that can filter out stack frames, for example the emit() method. A lambda wouldn't get a proper method name.

https://github.com/openjdk/jdk/pull/15867

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

PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759888327

From dfuchs at openjdk.org  Thu Oct 12 16:47:28 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Oct 2023 16:47:28 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered [v2]
In-Reply-To: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
Message-ID: <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>

> Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.
> 
> The issue appears to be a race condition between `cancelImpl` and `schedule` where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.
> 
> A simple fix is to ensure that `cancelImpl` will complete the subscriber, if needed.

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

  Simplify the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16144/files
  - new: https://git.openjdk.org/jdk/pull/16144/files/4cc23df3..a97ebe20

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

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

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

From aefimov at openjdk.org  Fri Oct 13 01:26:26 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Oct 2023 01:26:26 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v4]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
Message-ID: <Wc3S2AUMcrKlXvIt4QotwtOqPJBYmagbm83SRLOwDJ8=.30c06bc5-375a-4284-a9c2-a136d8bafc7e@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Aleksei Efimov has updated the pull request incrementally with three additional commits since the last revision:

 - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
 - Moving snippets to class-level docs per Michael suggestion, associated doc changes
 - Daniel suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/6b7ff713..d65e9d20

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

  Stats: 115 lines in 4 files changed: 44 ins; 38 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/15775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15775/head:pull/15775

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

From lucy at openjdk.org  Fri Oct 13 07:22:16 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 13 Oct 2023 07:22:16 GMT
Subject: RFR: JDK-8318006: remove unused net related coding
In-Reply-To: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
References: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
Message-ID: <JalwUIslRBdttyxaDX0AIKRlFAPTFuYcO0hKgGZWFNU=.bc3d2bfe-d974-4fc7-a667-90701efcd4ca@github.com>

On Thu, 12 Oct 2023 13:14:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old socket implementation code but it did leave some unused code behind, it would be good to remove these unused functions.

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16164#pullrequestreview-1675865732

From mbaesken at openjdk.org  Fri Oct 13 08:56:24 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 08:56:24 GMT
Subject: RFR: JDK-8318006: remove unused net related coding
In-Reply-To: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
References: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
Message-ID: <6V0VKYOfrBos-3_T1ar9jnwIbU6zsmXa0nq-5ailgkE=.0e302f22-0b39-48e9-b4f2-bc43ca750a6d@github.com>

On Thu, 12 Oct 2023 13:14:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old socket implementation code but it did leave some unused code behind, it would be good to remove these unused functions.

Hi Alan and Lutz , thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16164#issuecomment-1761155546

From mbaesken at openjdk.org  Fri Oct 13 08:56:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 08:56:25 GMT
Subject: Integrated: JDK-8318006: remove unused net related coding
In-Reply-To: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
References: <U4LOH_2i8YbpI9IBKd87vuabdqs-445GycWkoh_AasY=.48777775-34d8-4440-8ccf-cb971f178eb2@github.com>
Message-ID: <dzQMjEnyV7zaQ_-7S1arYN5EXZwI4ceROk48Ms3Yd8E=.04f2fa65-4e53-4de2-be1d-aa63f47e61d6@github.com>

On Thu, 12 Oct 2023 13:14:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old socket implementation code but it did leave some unused code behind, it would be good to remove these unused functions.

This pull request has now been integrated.

Changeset: 126f2ace
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/126f2ace5d36c72a8fced27218a66e0b6f920f85
Stats:     141 lines in 3 files changed: 0 ins; 141 del; 0 mod

8318006: remove unused net related coding

Reviewed-by: alanb, lucy

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

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

From dfuchs at openjdk.org  Fri Oct 13 09:19:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Oct 2023 09:19:20 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v4]
In-Reply-To: <Wc3S2AUMcrKlXvIt4QotwtOqPJBYmagbm83SRLOwDJ8=.30c06bc5-375a-4284-a9c2-a136d8bafc7e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <Wc3S2AUMcrKlXvIt4QotwtOqPJBYmagbm83SRLOwDJ8=.30c06bc5-375a-4284-a9c2-a136d8bafc7e@github.com>
Message-ID: <ovwS2PGYR1Bru3J0zHvNvy6kQOG4lx2_36h0VcaIfgw=.f3a1f2b6-3fcf-4d97-accb-d595cb5f279f@github.com>

On Fri, 13 Oct 2023 01:26:26 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
>  - Moving snippets to class-level docs per Michael suggestion, associated doc changes
>  - Daniel suggestions

Sorry for the back and forth suggestions - I hadn't noticed that "ambiguous" was already introduced earlier in the method description. I'd suggest the following refactoring to make it easier to read.

src/java.base/share/classes/java/net/Inet4Address.java line 189:

> 187:      * and {@code throwIAE} is {@code true}, an {@code IllegalArgumentException} is thrown.
> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to

Suggestion:

     * Otherwise, if it can be considered as {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
     * an ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to

src/java.base/share/classes/java/net/Inet4Address.java line 190:

> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
> 190:      * {@code throwIAE} value.

Suggestion:

     * {@code throwIAE} value.
     *
     * @apiNote
     * The given {@code addressLiteral} string is considered ambiguous if it cannot be parsed as
     *  a valid IPv4 address literal using decimal notation, but could be
     * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

src/java.base/share/classes/java/net/Inet4Address.java line 202:

> 200:      * {@code throwIAE} if the given {@code addressLiteral} string is ambiguous, that is,
> 201:      * it cannot be parsed as a valid IPv4 address literal using decimal notation but could be
> 202:      * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

Suggestion:

     * @throws IllegalArgumentException if the given {@code addressLiteral} string
     * cannot be parsed as an IPv4 address literal and {@code throwIAE} is {@code true},
     * or if it is considered ambiguous, regardless of the value of the value of
     * {@code throwIAE}.

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

PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1676057283
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358006767
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1357992180
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1357995298

From aefimov at openjdk.org  Fri Oct 13 12:19:11 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Oct 2023 12:19:11 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v5]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
Message-ID: <sA4q9MsE587e71bJaTPwT0ig_HDtamhaGxXH1FNMOhY=.b026be97-59aa-4b09-95ad-43038b40ae6f@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

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

  improve the ambiguous term readability according to Daniel comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/d65e9d20..4bd63f29

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

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

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

From aefimov at openjdk.org  Fri Oct 13 12:19:24 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Oct 2023 12:19:24 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v4]
In-Reply-To: <ovwS2PGYR1Bru3J0zHvNvy6kQOG4lx2_36h0VcaIfgw=.f3a1f2b6-3fcf-4d97-accb-d595cb5f279f@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <Wc3S2AUMcrKlXvIt4QotwtOqPJBYmagbm83SRLOwDJ8=.30c06bc5-375a-4284-a9c2-a136d8bafc7e@github.com>
 <ovwS2PGYR1Bru3J0zHvNvy6kQOG4lx2_36h0VcaIfgw=.f3a1f2b6-3fcf-4d97-accb-d595cb5f279f@github.com>
Message-ID: <Zeud45dYMb85xwuOJKXZBwVjF7vUa90y_uKwI1mkZvE=.8e86921d-d28f-4ccd-ba5b-d44058da3fb6@github.com>

On Fri, 13 Oct 2023 09:08:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
>>  - Moving snippets to class-level docs per Michael suggestion, associated doc changes
>>  - Daniel suggestions
>
> src/java.base/share/classes/java/net/Inet4Address.java line 190:
> 
>> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
>> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
>> 190:      * {@code throwIAE} value.
> 
> Suggestion:
> 
>      * {@code throwIAE} value.
>      *
>      * @apiNote
>      * The given {@code addressLiteral} string is considered ambiguous if it cannot be parsed as
>      *  a valid IPv4 address literal using decimal notation, but could be
>      * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

Thanks for the suggestions Daniel. They look reasonable to me, and improve the readability. Taken them aboard in 4bd63f29386a515d63879412f80d958046e6c8c2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358126045

From aefimov at openjdk.org  Fri Oct 13 12:19:41 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Oct 2023 12:19:41 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.7f528cdb-0811-4f70-b7b4-5a96a68f6acb@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.e3b03591-2bca-44a1-805d-2cb1e4af30a1@github.com>
 <cc3MYiTvaQcpgStuX9FRQrZF7QMlubtOyeCsK44hz-o=.ca4d1b4f-b582-4f51-8798-f496b2bfd591@github.com>
 <xDiXVNDqoRpVg7LGJZ5rxnfYm8TJ2xdfase6i_z1rPU=.d5ada882-8530-4004-b883-9a6a4e104d3d@github.com>
 <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.7f528cdb-0811-4f70-b7b4-5a96a68f6acb@github.com>
Message-ID: <d4gl7MHhuWBAtD0oZSshGKS_QdEMT9WRBRlRcpyoDOw=.eea7a4b0-6d28-490d-aa41-a18c9c18f9a7@github.com>

On Tue, 10 Oct 2023 16:17:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet6Address.java line 525:
>> 
>>> 523:      *         parsed as an IPv6 address literal.
>>> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
>>> 525:      */
>> 
>> Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.
>
> My mistake, it looks like we don't support the octal or hexadecimal formats in the existing `getByName` method, which is good news!
> 
> But, I think the comments above still apply in terms of moving the snippets to the class level docs, and maybe specifying there also that we only support the decimal literals

That is a good point Michael. The snippets were moved to class-level javadocs, and were modified a bit to limit the number of examples, and other small changes. Pushed as [e95858e](https://github.com/openjdk/jdk/pull/15775/commits/e95858ebb6039e9b5bbbca2a4730fcbed78747ca).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358130204

From michaelm at openjdk.org  Fri Oct 13 13:44:43 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 13 Oct 2023 13:44:43 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered [v2]
In-Reply-To: <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
 <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
Message-ID: <l5H91UZ6U88EMeHA2CrjmWyo4raWGC4l_h3HSB_f5Yo=.fdceb947-e200-4e14-bea2-c7e7ab4b5f1a@github.com>

On Thu, 12 Oct 2023 16:47:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.
>> 
>> The issue appears to be a race condition between `cancelImpl` and `schedule` where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.
>> 
>> A simple fix is to ensure that `cancelImpl` will complete the subscriber, if needed.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the fix

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 584:

> 582:                     }
> 583:                     return false;
> 584:                 }

Is this change here actually part of the fix, or something else that needed to be fixed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16144#discussion_r1358283715

From dfuchs at openjdk.org  Fri Oct 13 14:03:16 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Oct 2023 14:03:16 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered [v2]
In-Reply-To: <l5H91UZ6U88EMeHA2CrjmWyo4raWGC4l_h3HSB_f5Yo=.fdceb947-e200-4e14-bea2-c7e7ab4b5f1a@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
 <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
 <l5H91UZ6U88EMeHA2CrjmWyo4raWGC4l_h3HSB_f5Yo=.fdceb947-e200-4e14-bea2-c7e7ab4b5f1a@github.com>
Message-ID: <-BvfsgVp9qfa5QRZqR-pOxxB9Io07i9IULdIgLA1ccA=.7fb4545f-d423-4099-b8c1-8f6c0e617a10@github.com>

On Fri, 13 Oct 2023 13:41:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify the fix
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 584:
> 
>> 582:                     }
>> 583:                     return false;
>> 584:                 }
> 
> Is this change here actually part of the fix, or something else that needed to be fixed?

A bit of both. I was looking at why the subscriber didn't get properly unregistered and stumbled on this small issue. Tests showed that it wasn't sufficient to fix the issue so I continued debugging.
The semantics of the method is that it should return `true` only if the subscriber was added to the list, so it really should have returned `false` here, and `true` only if `subscribers.add` was called and returned `true`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16144#discussion_r1358300558

From michaelm at openjdk.org  Fri Oct 13 14:29:20 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 13 Oct 2023 14:29:20 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered [v2]
In-Reply-To: <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
 <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
Message-ID: <yeEI5i38Gv-Rlqit0rA5R_WXCFNXCsTufiSsCKT8AjI=.c7180d3d-f5f6-428b-bf5c-8eab7de8df5a@github.com>

On Thu, 12 Oct 2023 16:47:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.
>> 
>> The issue appears to be a race condition between `cancelImpl` and `schedule` where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.
>> 
>> A simple fix is to ensure that `cancelImpl` will complete the subscriber, if needed.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the fix

Seems straight forward. LGTM

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16144#pullrequestreview-1676597872

From djelinski at openjdk.org  Fri Oct 13 14:29:23 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 13 Oct 2023 14:29:23 GMT
Subject: RFR: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered [v2]
In-Reply-To: <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
 <g8yzVub_cFbz05FaBE0biiZwFme0Au6LivWrzZmUH0o=.57eace2e-0af2-4ed8-a80e-8d9f88b3baa0@github.com>
Message-ID: <nw2hVo0Rg9AMD9ZioQS8VglCd94omXDCpMmir9DYQq4=.0d317534-ee85-407f-9924-2ca217fe555f@github.com>

On Thu, 12 Oct 2023 16:47:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.
>> 
>> The issue appears to be a race condition between `cancelImpl` and `schedule` where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.
>> 
>> A simple fix is to ensure that `cancelImpl` will complete the subscriber, if needed.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the fix

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16144#pullrequestreview-1676617747

From dfuchs at openjdk.org  Fri Oct 13 14:39:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Oct 2023 14:39:18 GMT
Subject: Integrated: 8317808: HTTP/2 stream cancelImpl may leave subscriber
 registered
In-Reply-To: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
References: <EnrLEx63kJ6cFQlI52DwbSAoEaPl6lnVPCd0iVbEvDs=.3d60d2c1-f308-4cbb-984b-198cec8d5738@github.com>
Message-ID: <grxzArB1DGwU3EYIHAI3qJ5Ixi03OxdVf6p1PL0CpBA=.ce643c36-bfc3-46c3-a44f-cab706de9cf0@github.com>

On Wed, 11 Oct 2023 10:25:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Some of the ThrowingSubscriberXxx tests (typically those that use a streaming body) have been observed failing intermittently (though rarely) in timeout. The error message printed at the end showed that some HTTP/2 stream subscribers had not been properly deregistered when an exception was thrown in GET_BODY.
> 
> The issue appears to be a race condition between `cancelImpl` and `schedule` where the scheduler `sched` may get stopped before the subscriber is exceptionally completed.
> 
> A simple fix is to ensure that `cancelImpl` will complete the subscriber, if needed.

This pull request has now been integrated.

Changeset: 6273ab97
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6273ab97dc1a0d3c1f51ba94694d9594dd7593d4
Stats:     29 lines in 4 files changed: 22 ins; 4 del; 3 mod

8317808: HTTP/2 stream cancelImpl may leave subscriber registered

Reviewed-by: michaelm, djelinski

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

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

From duke at openjdk.org  Fri Oct 13 16:59:27 2023
From: duke at openjdk.org (Terry Chow)
Date: Fri, 13 Oct 2023 16:59:27 GMT
Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for
 Windows [v4]
In-Reply-To: <DR4ciLM0OW0ZOOBD207jGRSUpa0oignNT2ZmlBeON7o=.13afabdc-b834-424a-85de-36ea3b4fce75@github.com>
References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>
 <DR4ciLM0OW0ZOOBD207jGRSUpa0oignNT2ZmlBeON7o=.13afabdc-b834-424a-85de-36ea3b4fce75@github.com>
Message-ID: <1TjXly8LhR5oJUVfw3UnawdvuOLyvBnsIvqeaBZXOtQ=.13bf9012-28c9-42f7-9744-bf663e2993f6@github.com>

On Thu, 20 Jul 2023 18:52:53 GMT, Terry Chow <duke at openjdk.org> wrote:

>> The PR adds support for the keepalive extended socket options on Windows. For TCP_KEEPIDLE and TCP_KEEPINTVL, these options are supported starting from Windows 10 version 1709. TCP_KEEPCNT is supported starting from Windows 10 version 1703. Information on these socket options can be found [here](https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-tcp-socket-options).
>> 
>> I've also corrected the `handleError()` function. On Windows, the error needs to be retrieved using `WSAGetLastError()` and error codes are prefixed with "WSA". Information on this can be found [here](https://learn.microsoft.com/en-us/windows/win32/winsock/error-codes-errno-h-errno-and-wsagetlasterror-2).
>> 
>>>The error codes returned by Windows Sockets are similar to UNIX socket error code constants, but the constants are all prefixed with WSA.
>> 
>>>Error codes set by Windows Sockets are not made available through the errno variable.
>> 
>> No new tests were added as the existing tests should cover this.
>
> Terry Chow has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed inconsistent 'keep' vs. 'Keep' in method names

Hello, a release note was added to the ticket awhile ago. Let me know if there's anything else I need to do or correct. Thanks again.

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

PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1761822453

From dfuchs at openjdk.org  Fri Oct 13 17:23:31 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Oct 2023 17:23:31 GMT
Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for
 Windows [v4]
In-Reply-To: <1TjXly8LhR5oJUVfw3UnawdvuOLyvBnsIvqeaBZXOtQ=.13bf9012-28c9-42f7-9744-bf663e2993f6@github.com>
References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>
 <DR4ciLM0OW0ZOOBD207jGRSUpa0oignNT2ZmlBeON7o=.13afabdc-b834-424a-85de-36ea3b4fce75@github.com>
 <1TjXly8LhR5oJUVfw3UnawdvuOLyvBnsIvqeaBZXOtQ=.13bf9012-28c9-42f7-9744-bf663e2993f6@github.com>
Message-ID: <8Non0u57uw1TU1NqlwpBtpulNN7OVRhWKGFTIOH9KIo=.489cc32e-308b-4283-9860-4485bbfafa32@github.com>

On Fri, 13 Oct 2023 16:56:23 GMT, Terry Chow <duke at openjdk.org> wrote:

>> Terry Chow has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed inconsistent 'keep' vs. 'Keep' in method names
>
> Hello, a release note was added to the ticket awhile ago. Let me know if there's anything else I need to do or correct. Thanks again.

Thanks Terry @tkyc. I have made some updates and marked it DELIVERED. Can you double check that everything still looks good?

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

PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1761877877

From duke at openjdk.org  Fri Oct 13 17:58:25 2023
From: duke at openjdk.org (Terry Chow)
Date: Fri, 13 Oct 2023 17:58:25 GMT
Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for
 Windows [v4]
In-Reply-To: <8Non0u57uw1TU1NqlwpBtpulNN7OVRhWKGFTIOH9KIo=.489cc32e-308b-4283-9860-4485bbfafa32@github.com>
References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>
 <DR4ciLM0OW0ZOOBD207jGRSUpa0oignNT2ZmlBeON7o=.13afabdc-b834-424a-85de-36ea3b4fce75@github.com>
 <1TjXly8LhR5oJUVfw3UnawdvuOLyvBnsIvqeaBZXOtQ=.13bf9012-28c9-42f7-9744-bf663e2993f6@github.com>
 <8Non0u57uw1TU1NqlwpBtpulNN7OVRhWKGFTIOH9KIo=.489cc32e-308b-4283-9860-4485bbfafa32@github.com>
Message-ID: <cmrWanW3y8OzBYhE8BhpBZXGqrB3GTU_jqhRXAu0-7s=.82fa1eb9-469b-4062-bbd8-4ff3d525bfce@github.com>

On Fri, 13 Oct 2023 17:19:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello, a release note was added to the ticket awhile ago. Let me know if there's anything else I need to do or correct. Thanks again.
>
> Thanks Terry @tkyc. I have made some updates and marked it DELIVERED. Can you double check that everything still looks good?

@dfuch LGTM. Thanks for the quick update Daniel.

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

PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1761948896

From djelinski at openjdk.org  Mon Oct 16 10:32:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 16 Oct 2023 10:32:17 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
Message-ID: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>

`ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.

Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.

Tier2 green.

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

Commit messages:
 - Fix connectFailed, add test
 - Improve null handling

Changes: https://git.openjdk.org/jdk/pull/16199/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318150
  Stats: 74 lines in 2 files changed: 19 ins; 24 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/16199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16199/head:pull/16199

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

From jpai at openjdk.org  Mon Oct 16 10:52:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Oct 2023 10:52:46 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <yuBpDhC9pXtXjZ39YoiFK1z9DCmlKHW6PsgowtG_1VM=.e73e4916-3cd7-41aa-aa5f-7391f96e471d@github.com>

On Mon, 16 Oct 2023 09:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

The change to the source and the migration of the test to junit looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16199#pullrequestreview-1679678256

From dfuchs at openjdk.org  Mon Oct 16 11:52:48 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Oct 2023 11:52:48 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <nJF_15xMnvBp5Bop5zqt4UEHEVob0tu-a6kbmaFqWdc=.148cf7b3-2581-4119-8552-280d27ec426d@github.com>

On Mon, 16 Oct 2023 09:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

Looks reasonable to me. I believe CSR and release notes would be warranted. Also it would be good to double check whether other implementations of ProxySelector - e.g. when using -Djava.net.useSystemProxies=true also respect the contract of throwing IAE in those cases. We can't check that with a non-regression test unfortunately (unless it's a manual test) - but some code inspection might reveal whether the contract is respected or not.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16199#pullrequestreview-1679777786

From aivanov at openjdk.org  Mon Oct 16 12:09:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 16 Oct 2023 12:09:50 GMT
Subject: RFR: 8317696: Fix compilation with clang-16 [v4]
In-Reply-To: <YRtrQNFsaYl3Xn6aKqpD8jLk24Pt0mSYTOeEatffycU=.38e7b7f9-bbec-4f89-aecc-16c064dac6ba@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
 <YRtrQNFsaYl3Xn6aKqpD8jLk24Pt0mSYTOeEatffycU=.38e7b7f9-bbec-4f89-aecc-16c064dac6ba@github.com>
Message-ID: <Tl5FOg7dlHbK6auvrnEDjl65fXZ6x1Cpaplqw1uNhVY=.47be5334-6481-4695-98b9-636f98854ef0@github.com>

On Wed, 11 Oct 2023 09:27:30 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
>> 
>> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
>> 
>> 
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>>                                         ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>>                                                               ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             phost = (*g_network_address_get_hostname)(conn);
>>                                                                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>                             pport = (*g_network_address_get_port)(conn);
>>                                                                  ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_strfreev)(proxies);
>>                      ^
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>>         (*g_clear_error)(&error);
>>                         ^
>> Compiling X11Renderer.c (for libawt_headless.so)
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
>> In file included from src/java.desktop/unix/native/common/java2d/x11/X11Surf...
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the XShmQueryExtension declaration completely.

Client tests are green.

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16092#pullrequestreview-1679806119

From djelinski at openjdk.org  Mon Oct 16 13:18:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 16 Oct 2023 13:18:42 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <lDY-jSHaaVPIP23Fy5wCAN_LZ-sqJ8wAUiw7V7cl8kI=.4eeadc6e-904c-42fb-8a3c-f22ab405ddc6@github.com>

On Mon, 16 Oct 2023 09:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

There are only 2 implementations of ProxySelector in the JDK, and they are both covered by this test. `-Djava.net.useSystemProxies=true` changes the behavior of DefaultProxySelector, but parameter validation code path is the same in both cases. I could add a separate `@run` line with `-Djava.net.useSystemProxies=true`, but in the current state it would just run the same code again.

Will post a CSR and a release note soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/16199#issuecomment-1764463803

From dfuchs at openjdk.org  Mon Oct 16 13:25:35 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Oct 2023 13:25:35 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <lDY-jSHaaVPIP23Fy5wCAN_LZ-sqJ8wAUiw7V7cl8kI=.4eeadc6e-904c-42fb-8a3c-f22ab405ddc6@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
 <lDY-jSHaaVPIP23Fy5wCAN_LZ-sqJ8wAUiw7V7cl8kI=.4eeadc6e-904c-42fb-8a3c-f22ab405ddc6@github.com>
Message-ID: <u33A7NNPolhGx5uAVLO6QyGPsfcN2MwFL7pjsyAr25k=.979afe2f-1692-4fcf-970c-4d1124767fdd@github.com>

On Mon, 16 Oct 2023 13:15:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>  I could add a separate @run line with -Djava.net.useSystemProxies=true, but in the current state it would just run the same code again.

No need for that - and thanks for confirming that we have only two concrete implementations in the JDK and they now both behave in the same way.

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

PR Comment: https://git.openjdk.org/jdk/pull/16199#issuecomment-1764475904

From mbaesken at openjdk.org  Mon Oct 16 15:52:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Oct 2023 15:52:47 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1764687056

From aefimov at openjdk.org  Mon Oct 16 16:18:10 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:10 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address literals
Message-ID: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>

### Summary 

The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
 `java.net.Inet6Address` classes to parse IP address literals:
 ```
method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
``` 

### How new methods differ from existing ones

These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 

### The list of noteworthy changes
- `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
- All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
- The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.

### Testing 

`jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.

`java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):

Added Methods
-------------

java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

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

Commit messages:
 - improve the ambiguous term readability according to Daniel comments
 - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
 - Moving snippets to class-level docs per Michael suggestion, associated doc changes
 - Daniel suggestions
 - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
 - update javadoc of internal utility methods.
 - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
 - add null checks and NPE to methods javadoc
 - 8272215: Add InetAddress methods for parsing IP address literals

Changes: https://git.openjdk.org/jdk/pull/15775/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272215
  Stats: 658 lines in 6 files changed: 579 ins; 57 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/15775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15775/head:pull/15775

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

From dfuchs at openjdk.org  Mon Oct 16 16:18:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Oct 2023 16:18:15 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Good work Aleksei, certainly enough to get the discussion going :-) 
I'm not entirely sure of some aspects of this proposal though. See my other comments inline.

Sorry for the back and forth suggestions - I hadn't noticed that "ambiguous" was already introduced earlier in the method description. I'd suggest the following refactoring to make it easier to read.

The main motivation here is to have a method that will create an InetAddress from an IP literal, and throw if the string given as parameters doesn't correspond to an IP literal. By comparison, `getByName` will try to parse the given name as an IP literal, and if it can't parse it as an IP literal, pass it to the resolver. The new method will never invoke the resolver and throw in that case.  I find the name `ofLiteral` to be closer to what the method does than it would be if we provided it as an override to e.g. `getByAddress`, but naming can be discussed.

Well the name `ofLiteral` clearly conveys that it only accepts a string that represents an IP literal: I'm not sure what's cryptic about it?

src/java.base/share/classes/java/net/Inet4Address.java line 148:

> 146:      *   <blockquote><ul style="list-style-type:none">
> 147:      *   <li>{@code 1.2.3.4}</li>
> 148:      *   <li>{@code 06.07.08.09}</li>

It might be clearer to transform this in a kind of JShell like snippet, showing the Inet4Adress call and what is returned? I would also expect to see an example of IPv4-compatible IPv6 address literal here.

Something like:

     * {@snippet:
     *     Inet4Address.ofLiteral("1.2.3.4")            ==>    /1.2.3.4
     *     Inet4Address.ofLiteral("06.07.08.09")        ==>    /6.7.8.9
     *     Inet4Address.ofLiteral(""::ffff:1020:3040")  ==>    /16.32.48.64
     * }


As a side note, I suspect that Inet4Adress.ofLiteral() accepting IPv4-compatible IPv6 addresses will be surprising for most users. I wonder if we should change that, and have Inet6Address.ofLiteral() return InetAddress instead of Inet6Address, and take care of that edge case.

As a user of the API I could very well see myself trying to do something like:

if (addr.startsWith("[") && addr.endsWith("]")) {
    var ipv6 = addr.substring(1, addr.length() - 1);
    try {
         Inet6Address.ofLiteral(ipv6);
    }  catch (...) {
         throw new IllegalArgumentException("Invalid IPv6 literal between "[ ]"");
    }
}

I'm not saying we shouldn't do what you're suggesting here, but I believe we should get more feedback.

src/java.base/share/classes/java/net/Inet4Address.java line 180:

> 178: 
> 179:     /**
> 180:      * Parses string as an IPv4 address literal.

Suggestion:

     * Parses the given string as an IPv4 address literal.

src/java.base/share/classes/java/net/Inet4Address.java line 182:

> 180:      * Parses string as an IPv4 address literal.
> 181:      * If string contains a non-parsable literal and {@code throwIAE} is set to {@code false}
> 182:      * - {@code null} is returned.

Suggestion:

     * If the given {@code addressLiteral} string cannot be parsed as an IPv4 address literal 
     * and {@code throwIAE} is {@code false}, {@code null} is returned.

src/java.base/share/classes/java/net/Inet4Address.java line 184:

> 182:      * - {@code null} is returned.
> 183:      * If string contains a non-parsable literal and {@code throwIAE} is set to {@code true}
> 184:      * - {@code IllegalArgumentException} is thrown.

Suggestion:

     * If the given {@code addressLiteral} string cannot be parsed as an IPv4 address literal
     * and {@code throwIAE} is {@code true}, an {@code IllegalArgumentException} is thrown.

src/java.base/share/classes/java/net/Inet4Address.java line 189:

> 187:      * and {@code throwIAE} is {@code true}, an {@code IllegalArgumentException} is thrown.
> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to

Suggestion:

     * Otherwise, if it can be considered as {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
     * an ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to

src/java.base/share/classes/java/net/Inet4Address.java line 190:

> 188:      * @param addressLiteral IPv4 address literal to parse
> 189:      * @param throwIAE throw {@code IllegalArgumentException} if the
> 190:      *                 literal cannot be parsed as an IPv4 address literal.

Suggestion:

     * @param throwIAE whether to throw {@code IllegalArgumentException} if the
     *                 given {@code addressLiteral} string cannot be parsed as
     *                 an IPv4 address literal.

src/java.base/share/classes/java/net/Inet4Address.java line 190:

> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
> 190:      * {@code throwIAE} value.

Suggestion:

     * {@code throwIAE} value.
     *
     * @apiNote
     * The given {@code addressLiteral} string is considered ambiguous if it cannot be parsed as
     *  a valid IPv4 address literal using decimal notation, but could be
     * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

src/java.base/share/classes/java/net/Inet4Address.java line 195:

> 193:      * @throws IllegalArgumentException if ambiguous IPv4 literal is specified,
> 194:      * or non-parsable IPv4 literal is specified with {@code throwIAE} set to
> 195:      * {@code true}.

* @throws IllegalArgumentException if the given {@code addressLiteral} string
     *    cannot be parsed as an IPv4 address literal and {@code throwIAE} is {@code true}.
     *    An {@code IllegalArgumentException} is also thrown regardless of the value of 
     *    {@code throwIAE} if the given {@code addressLiteral} string is ambiguous, that is,
     *    it cannot be parsed as a valid IPv4 address literal using decimal notation but could be
     *    interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed)

src/java.base/share/classes/java/net/Inet4Address.java line 202:

> 200:      * {@code throwIAE} if the given {@code addressLiteral} string is ambiguous, that is,
> 201:      * it cannot be parsed as a valid IPv4 address literal using decimal notation but could be
> 202:      * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

Suggestion:

     * @throws IllegalArgumentException if the given {@code addressLiteral} string
     * cannot be parsed as an IPv4 address literal and {@code throwIAE} is {@code true},
     * or if it is considered ambiguous, regardless of the value of the value of
     * {@code throwIAE}.

src/java.base/share/classes/java/net/Inet6Address.java line 490:

> 488:      * java.net.spi.InetAddressResolver resolver} is not queried to resolve
> 489:      * the provided literal, and no reverse lookup is performed.
> 490:      * @implNote <a href="Inet6Address.html#special-ipv6-address-heading">

`@implNote` is not appropriate here. This should be part of the spec (if we keep it). See my other comment above in `Inet4Address`.

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

PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1631177877
PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1676057283
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1723443367
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1724040184
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1328799014
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352956961
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352979935
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352986216
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358006767
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1353001177
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1357992180
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1353026855
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1357995298
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1328804396

From alanb at openjdk.org  Mon Oct 16 16:18:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 16:18:16 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <PwJjKM3aL6FcnuuV5sduMmRlcikHvVoSq398lPvbzqM=.49c182d1-a67a-4f01-94d8-28110caf5d1f@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

At a high-level, introducing static methods named "ofLiteral" or "parse" to parse a string as an IPv4 or IPv6 literal address is good. I think the methods will require work on the class descriptions, speak about parsing the input string, and only mention "blocking" in the context of specifying that they don't attempt reverse name resolution. I suspect that the API additions will require a bit of re-work of the class descriptions, esp. as they are specified in terms of "textual representation".

On Inet4Address.ofLiteral, I can't tell from the method description if it supports all 4 forms that are listed in the class description. It may be a surprise that this method parses IPv4-mapped IPv6 addresses. So I think my main comment here is that the method description will need to more completely specify the forms that the input string may take.

Similar comment on Inet6Address.ofLiteral. I can't tell from the API docs if the input needs enclosing square brackets, I can't tell if it supports shortened forms, I can't tell if it's legal or not to include a scope ID. So I think my comment is just that you'll probably go through a few iterations to fully specify the forms that the input string can take.

InetAddress.ofLiteral doesn't need "throws IAE" in the method signature as it's an unchecked exception. I think this method will end up linking to the other two, and specifying that it first attempts to parse the input as an IPv4 address.

My comments here are just about the API for now, I didn't look at the implementation or tests at the time.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1722501929

From msheppar at openjdk.org  Mon Oct 16 16:18:17 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 16:18:17 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Looking at the motivation for this addition in the budgd description
The requirement is that of providing a methof to parse of an  string literal address returns and return an InetAddress without necessitating a reverse address lookup, which is what getByName does at the minute.
The additional motivation, appears to be to avoid the  misinterpretation scenario where an invalid address
String literal is considered as a hostname or fqdn resulting in a look by name.

Adding explicit factory methods is one approach, as proposed here. 
An alternative is to provide a string literal validator
which returns true if the string literal address is either an IPv4 or IPv6 address.
The validator can be used by an application in conjunction with the existing API getByName method.
For example, boolean isValidLiteralAddress(String literalAddress)
 InetAddress serverAddress;
 if (InetAddress.isValidLiteralAddress(someLiteralAddress) {
     serverAddress = InetAddress.getByName(someAddress);
 ?
 }

This will provide applications with a convenience method to validate inputs and use existing API without side effects.
Also, this approach will reduce the amount of internal restructuring required, should guarantee current behaviour, and provide a convenience application validation method.

But, for some might consider making two method calls  be too much of a burden!

If this is not considered an appropriate option, then a renaming of the proposed methods would be beneficial so as to exhibit the semantics of the operations.
For example, in keeping with the current nomenclature of getByName, getByAddress then getFromLiteral or getByLiteral would be in keeping with current naming scheme.

Alternatively, a straight forward ?it does what it says on the tin? name  such as parseLiteral would seem appropriate. I'm not a big fan of these "of" factory methods.

on further reflection, wrt method name, an overloaded getByAddress(String literalAddress) method is most appropriate rather then the of methods

the most consistent (with the current API) and object oriented version is the getByAddress(String addr). It is consistent with the existing API. Logically getByAddress(byte[]) and getByAddress(String) are essentially the same. That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address, as a String is an encapsulation of an array of bytes. As such it logically natural to add an overloaded method.
Adding a new style of method affects the logical balance of the InetAddress class, giving a mongrel, or hybrid API appearance.

Ceist agam ort:
Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach? Or have I misconstrued your statement:  "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.

thanks for the considered response

> > That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address
> 
> A literal IP address string can specify the same address in [multiple formats](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/InetAddress.html#textual-representation-of-ip-addresses-heading), a byte array supports only one - an array of bytes, with length equal to 4 for IPv4 addresses, and to 16 for IPv6 addresses.

I think you may have misinterpreted the point I was trying to make (or I didn't make it clearly enough), for example, a 4 byte array representing an IPv4 address is logically the same as a String representing an IPv4 address in dot notation. Thus, overloading getByAddress is a reasonable method to add and exhibits OO characteristics.

> 
> > Ceist agam ort:
> > Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach?
> 
> The idea of this change is to add three methods capable of parsing a string as an IPv4, IPv6 or any IP literal address. The explicit methods need to be added to all three classes irrelevant to their naming.
> 
> > Or have I misconstrued your statement: "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
> > But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.
> 
> You are right that the statement is a bit vague, yes. What was meant there was overloading the `InetAddress` method, and adding new methods to `Inet4Address` and `Inet6Address` would introduce a bit confusing API structure. All three classes for both approaches would look like:
> ### ofLiteral approach
> 
> ```
> // New methods
> InetAddress.ofLiteral(String)
> Inet4Address.ofLiteral(String)
> Inet6Address.ofLiteral(String)
> ```
> 
> ### getByAddress approach
> 
> ```
> // Existing methods with `address` being a byte array
> InetAddress.getByAddress(String, byte[])
> InetAddress.getByAddress(byte[])
> 
> // New methods with `address` being a literal  
> InetAddress.getByAddress(String) <-- overloaded method
> Inet4Address.getByAddress(String) <-- new and not overloaded method
> Inet6Address.getByAddress(String) <-- new and not overloaded method
> ```

There's no need to add these methods,
Inet4Address.getByAddress(String) <-- new and not overloaded method
Inet6Address.getByAddress(String) <-- new and not overloaded method

 to the derived classes. The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1722571081
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1722595450
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1749739710
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751688344

From duke at openjdk.org  Mon Oct 16 16:18:18 2023
From: duke at openjdk.org (Bernd)
Date: Mon, 16 Oct 2023 16:18:18 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
Message-ID: <nAWSxs5LViSGxtj0FACQfk35OBZrse34D-TiPMG-A7E=.45b687c1-8474-4f70-bac6-ce1e0938fbbd@github.com>

On Sun, 17 Sep 2023 23:21:23 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> on further reflection, wrt method name, an overloaded getByAddress(String literalAddress) method is most appropriate

I agree, and it should have both variants, 

getByAddtess(String literalAddress) throws UHE

getByAdress(String hostname, String  literalAddress) throws UHE


In order to produce resolved addresses as well. 

(The UHE is a bit strange but the preexisting method used it for a reason for invalid address arrays, I guess)

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1722599828

From msheppar at openjdk.org  Mon Oct 16 16:18:19 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
Message-ID: <ucvE_Bx3DZ4Zl2-FrnzP4gP7W0u1i-oqG9eZQsnpQQI=.3cc92736-a405-42e7-a930-ec63b158f197@github.com>

On Mon, 18 Sep 2023 13:43:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The main motivation here is to have a method that will create an InetAddress from an IP literal, and throw if the string given as parameters doesn't correspond to an IP literal. By comparison, `getByName` will try to parse the given name as an IP literal, and if it can't parse it as an IP literal, pass it to the resolver. The new method will never invoke the resolver and throw in that case. I find the name `ofLiteral` to be closer to what the method does than it would be if we provided it as an override to e.g. `getByAddress`, but naming can be discussed.

Well, the getByAddress methods are already providing a variation on the proposed functionality, and as such it makes sense from an OO perspective (polymorphism) to provide an overloaded method to perform the proposed functionality.  getByAddress is doing "what is says on the tin" ... ofLiteral conveys no semantics  and is more cryptic or nuanced

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1723598856

From michaelm at openjdk.org  Mon Oct 16 16:18:19 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <laszUpFTGqGzuGI0kabN_V4_M4uJAsVXnkkZ__KsA0o=.87fd192c-5b30-4c85-9201-7fba440f01ac@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

I'd have a mild preference for the new name rather than overloading the existing `getByAddress`. With IDE auto completion, I think a distinct name is a bit clearer for the developer as to what exactly the method will do. 

I think if it can be specified and implemented that `InetAddress.ofLiteral` calls the sub-type variants (based on string length maybe) then I think it makes sense to specify the parsing details in the sub-classes. If not, then I'm not sure we need the new methods in the sub-classes.

src/java.base/share/classes/java/net/Inet4Address.java line 163:

> 161:      *  Inet4Address.ofLiteral("02130706689") ==> /127.0.1.1
> 162:      * }
> 163:      * <p>If the provided address literal cannot represent a valid IPv4 address an

I think this behavior is the same as existing methods, except that only the decimal format is supported? I wonder is it really necessary to describe it here, as it it would be quite an arcane usage, and the section in the class doc "Textual representation if IP addresses" already partially covers it. The snippet example with the leading zero seems to be implying that octal format is not supported, but without really saying it out loud. 

Maybe the apidoc for the method could just say that the decimal formats are the only ones supported, but otherwise refer to the class docs for how the different variants work ? And maybe move the snippet there as well?

src/java.base/share/classes/java/net/Inet6Address.java line 525:

> 523:      *         parsed as an IPv6 address literal.
> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
> 525:      */

Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1725280222
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352797174
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352812605

From aefimov at openjdk.org  Mon Oct 16 16:18:20 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <PwJjKM3aL6FcnuuV5sduMmRlcikHvVoSq398lPvbzqM=.49c182d1-a67a-4f01-94d8-28110caf5d1f@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <PwJjKM3aL6FcnuuV5sduMmRlcikHvVoSq398lPvbzqM=.49c182d1-a67a-4f01-94d8-28110caf5d1f@github.com>
Message-ID: <2STaEer-1W3aUDerOp6KwI3EYAGZKoqBpv5zfQ6WRcM=.7f447707-d86b-4d33-a824-db9a0ef53752@github.com>

On Sun, 17 Sep 2023 15:30:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> At a high-level, introducing static methods named "ofLiteral" or "parse" to parse a string as an IPv4 or IPv6 literal address is good. I think the methods will require work on the class descriptions, speak about parsing the input string, and only mention "blocking" in the context of specifying that they don't attempt reverse name resolution.

Thanks Alan. Based on the intial feedback it is clear that these new methods require more work on documentation. 

> On Inet4Address.ofLiteral, I can't tell from the method description if it supports all 4 forms that are listed in the class description. It may be a surprise that this method parses IPv4-mapped IPv6 addresses. So I think my main comment here is that the method description will need to more completely specify the forms that the input string may take.

I agree that seeing `Inet4Address.ofLiteral` capable of parsing IPv4-mapped IPv6 addresses can look strange here. On contrary, there should be no surprise for `Inet6Address.ofLiteral` to parse such addresses. I will pursue updating its signature to return `InetAddress` and document it as one of the supported forms.

> Similar comment on Inet6Address.ofLiteral. I can't tell from the API docs if the input needs enclosing square brackets, I can't tell if it supports shortened forms, I can't tell if it's legal or not to include a scope ID. 

`Inet6Address.ofLiteral` supports literal enclosed with/without square brackets, supports scope ID, shorten-format. But it is not mentioned in Javadoc. I will work on updating Javadoc to list all these aspects.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1725373552

From aefimov at openjdk.org  Mon Oct 16 16:18:20 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <xJKsrtq_ecuY0zA_DyLbz_683U-sMS7aFp-sHNQRxEQ=.ad0e8a70-4597-4582-9bdb-4d869db9736d@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Thanks for all the comments/feedback/suggestions provided. They highlight the fact that this change requires additional work in the following areas:
- Improving new methods Javadoc to mention all supported IP address literal forms.
- Having Inet4Addres.ofLiteral responsible for parsing IPv4-mapped IPv6 addresses looks strange. That will require method signature changes, but will keep javadoc and API less confusing.

In comming days I will work on fixing the above issues first. The methods name can be discussed after that.

The next iteration contains the following changes:

- Improvements to Javadoc of the new methods. That includes the addition of all supported IP address literal forms.
- `Inet4Addres.ofLiteral` is no longer capable of parsing IPv4-mapped IPv6 address literals - it can be done with `Inet6Address.ofLiteral` instead.
- Added missing `null` checks for literal parameters.
- Added new test scenarios.

To restart the conversation around the method name, I've prepared the following table with a list of method names discussed during the previous review iteration:

| Name | Usage Example | Notes |
|-------|--------------|-------|
| `ofLiteral` | `InetAddress.ofLiteral` | Current version. Cleary conveys it takes only an IP literal. Matches its implementation. Good for IDE autocompletion. |
| `parse` | `InetAddress.parse` | The fact that only IP address literals are taken as a parameter is obscured a bit. But still suggests that the InetAddress instance is constructed by parsing some text. Good for IDE.|
| `parseLiteral` | `InetAddress.parseLiteral` | Method name changed to hint that an IP address literal is taken as a parameter. Good for IDE. Matches its implementation.|
| `getByAddress` | `InetAddress.getByAddress` | Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address. Introduces new meaning of `address` term - IP address literal string. In existing API the `address` means a raw byte array.|

My preference is to proceed with one of the following two:
`ofLiteral` or `parseLiteral`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1725438962
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1732371463
PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1747264766

From aefimov at openjdk.org  Mon Oct 16 16:18:20 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
Message-ID: <BV8zrVRMaMTL9yEEkMFM6c1eucneqdwryWRgxomIJVw=.7f79c3ea-4897-4587-8af5-8568f53b5e0b@github.com>

On Thu, 5 Oct 2023 22:25:23 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address

 A literal IP address string can specify the same address in [multiple formats](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/InetAddress.html#textual-representation-of-ip-addresses-heading), a byte array supports only one - an array of bytes, with length equal to 4 for IPv4 addresses, and to 16 for IPv6 addresses.

> Ceist agam ort:
> Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach?

The idea of this change is to add three methods capable of parsing a string as an IPv4, IPv6 or any IP literal address. The explicit methods need to be added to all three classes irrelevant to their naming.

> Or have I misconstrued your statement: "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ?
> But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods.

You are right that the statement is a bit vague, yes. What was meant there was overloading the `InetAddress` method, and adding new methods to `Inet4Address` and `Inet6Address` would introduce a bit confusing API structure. All three classes for both approaches would look like:

### ofLiteral approach

// New methods
InetAddress.ofLiteral(String)
Inet4Address.ofLiteral(String)
Inet6Address.ofLiteral(String)


### getByAddress approach

// Existing methods with `address` being a byte array
InetAddress.getByAddress(String, byte[])
InetAddress.getByAddress(byte[])

// New methods with `address` being a literal  
InetAddress.getByAddress(String) <-- overloaded method
Inet4Address.getByAddress(String) <-- new and not overloaded method
Inet6Address.getByAddress(String) <-- new and not overloaded method

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1750435491

From alanb at openjdk.org  Mon Oct 16 16:18:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
Message-ID: <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.6f580d96-cfe2-4aa3-b89e-8ee1d6da49f7@github.com>

On Sat, 7 Oct 2023 11:32:43 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class

I don't think I agree with this. The existing 2-arg getByAddress method takes a string that is a host name or string representation of an IP address. It can be argued that it was a mistake to allow it accept IP literal addresses but it can't be changed. Same thing with the UHE thrown by both getByAddress methods but that can't be changed either.

The new factory methods have a very clear purpose to create an InetAddress from the string representation of an IP literal address. The proposed name ofLiteral is readable/clear and consistent with the naming of other static factory methods added to the APIs in recent years.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751693706

From msheppar at openjdk.org  Mon Oct 16 16:18:21 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.6f580d96-cfe2-4aa3-b89e-8ee1d6da49f7@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
 <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.6f580d96-cfe2-4aa3-b89e-8ee1d6da49f7@github.com>
Message-ID: <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.8d518d16-6661-4213-b382-b47f89f4736d@github.com>

On Sat, 7 Oct 2023 12:01:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class
> 
> I don't think I agree with this. The existing 2-arg getByAddress method takes a string that is a host name or string representation of an IP address. It can be argued that it was a mistake to allow it accept IP literal addresses but it can't be changed. Same thing with the UHE thrown by both getByAddress methods but that can't be changed either.
> 

The sentence should have read "The functionality can be fully provided by adding an overloaded (static) getByAddress in the base InetAddress class, only."

I wasn't suggesting that the current API was providing the requested functionality.
you may have misinterpreted what I'm saying. 
The requested functionality can be provided by an overloaded getByAddress method to the InetAddress , and that is sufficient. As such, there is no need for additional method in the Inet4Address or Inet6Address

> The new factory methods have a very clear purpose to create an InetAddress from the string representation of an IP literal address. The proposed name ofLiteral is readable/clear and consistent with the naming of other static factory methods added to the APIs in recent years.

For me, it is not consistent with the well esatblished InetAddress API (getByName, getByAddress), in which case the ofLiteral style looks like a bit of a wart.  Adding an overloaded getByAddress method is a logical OO design approach.  You seem to be intent on adding this "ofXXX" style methods. So we'll just have to agree to disagree on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751713257

From alanb at openjdk.org  Mon Oct 16 16:18:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.8d518d16-6661-4213-b382-b47f89f4736d@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <4NCOtVWLF5K-PSw7_3LFdBT19UyapNxAUtSj4XEu0gA=.696f2b10-e739-466d-a8ba-8384d18b75d7@github.com>
 <GuII7IWzeKYdZD9UW8STppZs7pePAd65GqTt6zN77AY=.6f580d96-cfe2-4aa3-b89e-8ee1d6da49f7@github.com>
 <mLLWjuWnfcKMK0PBDQSGhLOvmJNMJq9gMBQdb7m65g8=.8d518d16-6661-4213-b382-b47f89f4736d@github.com>
Message-ID: <vZZRzBrVZvIQ-pSTcsO3ecEZ0J55Rijj95787xvKvzQ=.e1ff66f1-61e1-4be9-bacf-41b008e33b00@github.com>

On Sat, 7 Oct 2023 13:27:45 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The sentence should have read "The functionality can be fully provided by adding an overloaded (static) getByAddress in the base InetAddress class, only."
> 
> I wasn't suggesting that the current API was providing the requested functionality. you may have misinterpreted what I'm saying. The requested functionality can be provided by an overloaded getByAddress method to the InetAddress , and that is sufficient. As such, there is no need for additional method in the Inet4Address or Inet6Address

The existing naming in InetAddress comes with baggage. The getByXXX method suggests lookup, they throw UHE. The getByAddress methods take a byte[], the input is bytes. The String parameter for the 2-arg getByAddress is intended to be a host name. I don't think the new static factory methods should be burdened with all this baggage so move to a methods that are clear/obvious/readable seems a much better route. We can bikeshed over specific name but the ofXXX convention is something that many areas of the platform has adopted in recent years.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752413273

From jpai at openjdk.org  Mon Oct 16 16:18:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.4280c4c9-ec86-4bb7-8ca7-bcfdcd89787c@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Hello Aleksei, it's good to see the addition of these new APIs. On the naming front, I like the proposal of using either `ofLiteral` or `parseLiteral`.

The new APIs are proposing to throw an `IllegalArgumentException` if the passed literal is not an IP address literal. That seems logical. However, the existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw IP address, currently throws `UnknownHostException` in the case where the IP address isn't of a valid length. Should we consider throwing `UnknownHostException` from these new APIs too? I prefer `IllegalArgumentException` in these new APIs, but `UnknownHostException` might be something that would need to be considered?

The proposed changes also have text which talks about "ambiguous" address literals. The term ambiguous seems new in the InetAddress (and sub-classes). The package-info.java too doesn't have previous references to it. Should we add some details on what addresses are considered ambiguous (and how/if such addresses are treated by existing APIs)?

src/java.base/share/classes/java/net/Inet4Address.java line 181:

> 179:     /**
> 180:      * Parses string with an IPv4 address literal.
> 181:      * If string doesn't contain a valid literal - null is returned.

This sentence is a bit confusing, given the implementation details of this method. I think `null` is only returned if `throwIAE` is false?

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 135:

> 133:      * to {@code false}, or is not set then validation of the address string is performed as follows:
> 134:      * If string can't be parsed by following IETF IPv4 address string literals
> 135:      * formatting style rules (default one), but can be parsed by following BSD formatting

I realize that this is an existing javadoc comment in an internal utility class (which is used by public InetAddress API implementation); do you think we should add a more formal reference to the BSD formatting of IP address, like we currently do for other RFCs and such in the class level javadoc of `InetAddress`?

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 141:

> 139:      * @param src input string
> 140:      * @param throwIAE {@code "true"} - throw {@code IllegalArgumentException} when cannot be parsed as IPv4 address string;
> 141:      *                 {@code "false"} - throw {@code "IllegalArgumentException"} only when IPv4 address string is ambiguous.

Are these double quotes around `true`, `false`, `null` and `IllegalArgumentException` intentional? It seems odd to have those double quotes when (rightly) using `{@code}`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752441558
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349928593
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349926001
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1349930995

From alanb at openjdk.org  Mon Oct 16 16:18:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.4280c4c9-ec86-4bb7-8ca7-bcfdcd89787c@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.4280c4c9-ec86-4bb7-8ca7-bcfdcd89787c@github.com>
Message-ID: <3jfTVsFV-rv9zswqZJbE0FoPWo_W5LZ8PYv1aW7PGws=.4707edfe-b05a-4a5a-8c1b-8c23fbc43d67@github.com>

On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The new APIs are proposing to throw an `IllegalArgumentException` if the passed literal is not an IP address literal. That seems logical. However, the existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw IP address, currently throws `UnknownHostException` in the case where the IP address isn't of a valid length. Should we consider throwing `UnknownHostException` from these new APIs too? I prefer `IllegalArgumentException` in these new APIs, but `UnknownHostException` might be something that would need to be considered?

UHE is an IOException so would be problematic for a number of reasons. IAE is the right exception for bad input here.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1752455199

From aefimov at openjdk.org  Mon Oct 16 16:18:22 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.4280c4c9-ec86-4bb7-8ca7-bcfdcd89787c@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <HUAHG5YHtuZH9lm2NlsmJjS2eNwHpHVACGl_-yva1Ac=.4280c4c9-ec86-4bb7-8ca7-bcfdcd89787c@github.com>
Message-ID: <jI1iULzKyB_z2w_J6BOrSCkroT9jVf1XHruwPpyF_YI=.9758817d-9afd-4897-b3a8-7c9fbb328801@github.com>

On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Aleksei, it's good to see the addition of these new APIs. On the naming front, I like the 

Hello Jaikiran

> The proposed changes also have text which talks about "ambiguous" address literals. The term ambiguous seems new in the InetAddress (and sub-classes). The package-info.java too doesn't have previous references to it.

What ambiguous IPv4 address literals mean in the code and in [the release notes](https://www.oracle.com/java/technologies/javase/18all-relnotes.html#JDK-8277608): it is a set of addresses which can't be parsed in dotted-decimal forms listed in the Inet4Address#format class-level javadoc section, but can be parsed in BSD forms (decimal, octal, or hexadecimal) defined in [`inet_addr` of IEEE Std 1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html).

> Should we add some details on what addresses are considered ambiguous (and how/if such addresses are treated by existing APIs)?

The release note states that the `InetAddress` accepts IPv4 address literals in decimal quad notation. The new `ofLiteral` API also states that only dotted-decimal forms are supported, `ambigous` term is not mentioned in any public javadoc, and given that the related system property is a jdk-specific system property I would like to avoid introducing this term as part of this PR. 

> do you think we should add a more formal reference to the BSD formatting of IP address

I think a more formal reference to BSD forms might be needed if they are recognizable by InetAddress APIs. As of today, this is not the case.

> src/java.base/share/classes/java/net/Inet4Address.java line 181:
> 
>> 179:     /**
>> 180:      * Parses string with an IPv4 address literal.
>> 181:      * If string doesn't contain a valid literal - null is returned.
> 
> This sentence is a bit confusing, given the implementation details of this method. I think `null` is only returned if `throwIAE` is false?

Thank you for spotting it. I have updated the javadoc of the `parseAddressString` method to contain all three possible scenarios:

     * If string contains a non-parsable literal and {@code throwIAE} is set to {@code false}
     * - {@code null} is returned.
     * If string contains a non-parsable literal and {@code throwIAE} is set to {@code true}
     * - {@code IllegalArgumentException} is thrown.
     * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
     * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
     * {@code throwIAE} value.

> src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 141:
> 
>> 139:      * @param src input string
>> 140:      * @param throwIAE {@code "true"} - throw {@code IllegalArgumentException} when cannot be parsed as IPv4 address string;
>> 141:      *                 {@code "false"} - throw {@code "IllegalArgumentException"} only when IPv4 address string is ambiguous.
> 
> Are these double quotes around `true`, `false`, `null` and `IllegalArgumentException` intentional? It seems odd to have those double quotes when (rightly) using `{@code}`.

Nope, there are not intentional - a leftover from the fix prototyping stage. Will remove them.

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

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1755647174
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352771068
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352772971

From duke at openjdk.org  Mon Oct 16 16:18:22 2023
From: duke at openjdk.org (Bernd)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
Message-ID: <B1ihNAXvzrGITISR-EoVpyefdA7WxJd7IWcDF4YXeIM=.3e1105d2-7f55-425e-9b3d-7bcd7f15dc73@github.com>

On Mon, 18 Sep 2023 14:14:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>      *     Inet4Address.ofLiteral("06.07.08.09")        ==>    /6.7.8.9

if we ignore octal encoding, we should document it explicitely.

Maybe 

> The loose IPv4 syntax of partial numbers or hex encoding ("10.0.258", "0xA000102") is not supported and causes a parsing error. Octal (zero) prefixes are ignored, i.e. interpreted decimal.

(However I would prefer to reject octal in this case)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1329036189

From dfuchs at openjdk.org  Mon Oct 16 16:18:22 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <B1ihNAXvzrGITISR-EoVpyefdA7WxJd7IWcDF4YXeIM=.3e1105d2-7f55-425e-9b3d-7bcd7f15dc73@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
 <B1ihNAXvzrGITISR-EoVpyefdA7WxJd7IWcDF4YXeIM=.3e1105d2-7f55-425e-9b3d-7bcd7f15dc73@github.com>
Message-ID: <Zg8RI-TEhs_sFQNQWIKcSJAwUddEo-APh4pGS7ssLhA=.ea37bb83-e83f-4e8b-a8ba-d9708513f9df@github.com>

On Mon, 18 Sep 2023 16:58:15 GMT, Bernd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet4Address.java line 148:
>> 
>>> 146:      *   <blockquote><ul style="list-style-type:none">
>>> 147:      *   <li>{@code 1.2.3.4}</li>
>>> 148:      *   <li>{@code 06.07.08.09}</li>
>> 
>> It might be clearer to transform this in a kind of JShell like snippet, showing the Inet4Adress call and what is returned? I would also expect to see an example of IPv4-compatible IPv6 address literal here.
>> 
>> Something like:
>> 
>>      * {@snippet:
>>      *     Inet4Address.ofLiteral("1.2.3.4")            ==>    /1.2.3.4
>>      *     Inet4Address.ofLiteral("06.07.08.09")        ==>    /6.7.8.9
>>      *     Inet4Address.ofLiteral(""::ffff:1020:3040")  ==>    /16.32.48.64
>>      * }
>> 
>> 
>> As a side note, I suspect that Inet4Adress.ofLiteral() accepting IPv4-compatible IPv6 addresses will be surprising for most users. I wonder if we should change that, and have Inet6Address.ofLiteral() return InetAddress instead of Inet6Address, and take care of that edge case.
>> 
>> As a user of the API I could very well see myself trying to do something like:
>> 
>> if (addr.startsWith("[") && addr.endsWith("]")) {
>>     var ipv6 = addr.substring(1, addr.length() - 1);
>>     try {
>>          Inet6Address.ofLiteral(ipv6);
>>     }  catch (...) {
>>          throw new IllegalArgumentException("Invalid IPv6 literal between "[ ]"");
>>     }
>> }
>> 
>> I'm not saying we shouldn't do what you're suggesting here, but I believe we should get more feedback.
>
>>      *     Inet4Address.ofLiteral("06.07.08.09")        ==>    /6.7.8.9
> 
> if we ignore octal encoding, we should document it explicitely.
> 
> Maybe 
> 
>> The loose IPv4 syntax of partial numbers or hex encoding ("10.0.258", "0xA000102") is not supported and causes a parsing error. Octal (zero) prefixes are ignored, i.e. interpreted decimal.
> 
> (However I would prefer to reject octal in this case)

This method behaves like `InetAddress.getByName` in that regards.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1329046350

From aefimov at openjdk.org  Mon Oct 16 16:18:23 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:23 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <rLcQLL22csIPJKdrGO2aX0A2SoPr3qxKIZ0TGCu8DpQ=.f120f2cb-f5d5-4033-bb81-fbe9dac66630@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
 <B1ihNAXvzrGITISR-EoVpyefdA7WxJd7IWcDF4YXeIM=.3e1105d2-7f55-425e-9b3d-7bcd7f15dc73@github.com>
 <Zg8RI-TEhs_sFQNQWIKcSJAwUddEo-APh4pGS7ssLhA=.ea37bb83-e83f-4e8b-a8ba-d9708513f9df@github.com>
 <rLcQLL22csIPJKdrGO2aX0A2SoPr3qxKIZ0TGCu8DpQ=.f120f2cb-f5d5-4033-bb81-fbe9dac66630@github.com>
Message-ID: <fv52APxJ2uFC7w7_iRK4bsbZQj9M9UVgnL5VeXEFVgA=.ce2ceb12-8062-46f1-8603-b89a163b1edb@github.com>

On Mon, 18 Sep 2023 17:16:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This method behaves like `InetAddress.getByName` in that regards.
>
> I believe accepting leading 0 as an octal indicator would require a new API, yet to be defined. What we're proposing here is a method that behaves like `InetAddress.getByName` would except that it rejects what `InetAddress.getByName` would have identified as a hostname needing resolution. In other words it only accepts IP literals that `InetAddress.getByName` would accept as IP literals, and parses them as `InetAddress.getByName` would parse them, and rejects anything that would cause `InetAddress.getByName` to invoke the resolver.

> if we ignore octal encoding, we should document it explicitely.

Agree - Javadoc for `Inet4Address.ofLiteral` needs to be updated to cleary mention that only IPv4 literals in decimal encoding are supported, and to state that no other encodings (octal, hexadecimal) are supported.  That will also need to mention that one, two, three and four-part IPv4 address literals are supported to match [Inet4Address format section](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/Inet4Address.html#format)

> Maybe
>
> > The loose IPv4 syntax of partial numbers or hex encoding ("10.0.258", "0xA000102") is > > not supported and causes a parsing error. Octal (zero) prefixes are ignored, i.e. interpreted decimal.

Thanks for the suggestion. `10.0.258` is supported and [documented](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/Inet4Address.html#format) 'd.d.d' format. It is not planned to change support for such address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1330043596

From michaelm at openjdk.org  Mon Oct 16 16:18:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Oct 2023 16:18:23 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <laszUpFTGqGzuGI0kabN_V4_M4uJAsVXnkkZ__KsA0o=.87fd192c-5b30-4c85-9201-7fba440f01ac@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <laszUpFTGqGzuGI0kabN_V4_M4uJAsVXnkkZ__KsA0o=.87fd192c-5b30-4c85-9201-7fba440f01ac@github.com>
Message-ID: <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.c2e47cc5-de04-44db-b4da-397c12550a7c@github.com>

On Tue, 10 Oct 2023 15:40:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> src/java.base/share/classes/java/net/Inet6Address.java line 525:
> 
>> 523:      *         parsed as an IPv6 address literal.
>> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
>> 525:      */
> 
> Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.

My mistake, it looks like we don't support the octal or hexadecimal formats in the existing `getByName` method, which is good news!

But, I think the comments above still apply in terms of moving the snippets to the class level docs, and maybe specifying there also that we only support the decimal literals

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1352862018

From aefimov at openjdk.org  Mon Oct 16 16:18:23 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:23 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.c2e47cc5-de04-44db-b4da-397c12550a7c@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <laszUpFTGqGzuGI0kabN_V4_M4uJAsVXnkkZ__KsA0o=.87fd192c-5b30-4c85-9201-7fba440f01ac@github.com>
 <meA3zRahpnOaB2nLbMRIZ9KyUMQF-ETfu381DwPxFis=.c2e47cc5-de04-44db-b4da-397c12550a7c@github.com>
Message-ID: <d4gl7MHhuWBAtD0oZSshGKS_QdEMT9WRBRlRcpyoDOw=.f58066ef-e44e-4726-ae0a-45a07cecef24@github.com>

On Tue, 10 Oct 2023 16:17:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet6Address.java line 525:
>> 
>>> 523:      *         parsed as an IPv6 address literal.
>>> 524:      * @throws NullPointerException if the {@code ipv6AddressLiteral} is {@code null}.
>>> 525:      */
>> 
>> Similar comment to Inet4Address. The snippet should be incorporated into the general class docs section "Textual representation of IP addresses" and the apidoc here should limit itself to any limitations that only apply to this method imo.
>
> My mistake, it looks like we don't support the octal or hexadecimal formats in the existing `getByName` method, which is good news!
> 
> But, I think the comments above still apply in terms of moving the snippets to the class level docs, and maybe specifying there also that we only support the decimal literals

That is a good point Michael. The snippets were moved to class-level javadocs, and were modified a bit to limit the number of examples, and other small changes. Pushed as [e95858e](https://github.com/openjdk/jdk/pull/15775/commits/e95858ebb6039e9b5bbbca2a4730fcbed78747ca).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358130204

From dfuchs at openjdk.org  Mon Oct 16 16:18:22 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <Zg8RI-TEhs_sFQNQWIKcSJAwUddEo-APh4pGS7ssLhA=.ea37bb83-e83f-4e8b-a8ba-d9708513f9df@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
 <B1ihNAXvzrGITISR-EoVpyefdA7WxJd7IWcDF4YXeIM=.3e1105d2-7f55-425e-9b3d-7bcd7f15dc73@github.com>
 <Zg8RI-TEhs_sFQNQWIKcSJAwUddEo-APh4pGS7ssLhA=.ea37bb83-e83f-4e8b-a8ba-d9708513f9df@github.com>
Message-ID: <rLcQLL22csIPJKdrGO2aX0A2SoPr3qxKIZ0TGCu8DpQ=.f120f2cb-f5d5-4033-bb81-fbe9dac66630@github.com>

On Mon, 18 Sep 2023 17:07:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>>      *     Inet4Address.ofLiteral("06.07.08.09")        ==>    /6.7.8.9
>> 
>> if we ignore octal encoding, we should document it explicitely.
>> 
>> Maybe 
>> 
>>> The loose IPv4 syntax of partial numbers or hex encoding ("10.0.258", "0xA000102") is not supported and causes a parsing error. Octal (zero) prefixes are ignored, i.e. interpreted decimal.
>> 
>> (However I would prefer to reject octal in this case)
>
> This method behaves like `InetAddress.getByName` in that regards.

I believe accepting leading 0 as an octal indicator would require a new API, yet to be defined. What we're proposing here is a method that behaves like `InetAddress.getByName` would except that it rejects what `InetAddress.getByName` would have identified as a hostname needing resolution. In other words it only accepts IP literals that `InetAddress.getByName` would accept as IP literals, and parses them as `InetAddress.getByName` would parse them, and rejects anything that would cause `InetAddress.getByName` to invoke the resolver.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1329055548

From aefimov at openjdk.org  Mon Oct 16 16:18:23 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 16:18:23 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <D0eHIXfZIR-1aR42kjZGxI1HjQFikbf2sgB2fO31d-c=.ff6ae993-43e2-437e-a93d-50009e07c306@github.com>
Message-ID: <Zeud45dYMb85xwuOJKXZBwVjF7vUa90y_uKwI1mkZvE=.8bf016c6-61fa-4bf0-a3c9-d482d08a4ccc@github.com>

On Fri, 13 Oct 2023 09:08:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> src/java.base/share/classes/java/net/Inet4Address.java line 190:
> 
>> 188:      * If string contains an {@linkplain IPAddressUtil#validateNumericFormatV4(String, boolean)
>> 189:      * ambiguous literal} - {@code IllegalArgumentException} is thrown irrelevant to
>> 190:      * {@code throwIAE} value.
> 
> Suggestion:
> 
>      * {@code throwIAE} value.
>      *
>      * @apiNote
>      * The given {@code addressLiteral} string is considered ambiguous if it cannot be parsed as
>      *  a valid IPv4 address literal using decimal notation, but could be
>      * interpreted as an IPv4 address in some other representation (octal, hexadecimal, or mixed).

Thanks for the suggestions Daniel. They look reasonable to me, and improve the readability. Taken them aboard in 4bd63f29386a515d63879412f80d958046e6c8c2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1358126045

From michaelm at openjdk.org  Mon Oct 16 18:01:11 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Oct 2023 18:01:11 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <RYJWKsG2Yb5aOP2-KuooHsYvS8wdTF6dzKL6ybCvnx8=.f12307ea-5197-4482-8dc0-cf80f3995610@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Changes requested by michaelm (Reviewer).

src/java.base/share/classes/java/net/Inet4Address.java line 166:

> 164:      * Creates an {@code Inet4Address} based on the provided {@linkplain
> 165:      * Inet4Address##format textual representations} of an IPv4 address.
> 166:      * <p> If the provided IPv4 address literal cannot represent a {@linkplain

"textual representations" -> "textual representation"

src/java.base/share/classes/java/net/Inet6Address.java line 500:

> 498:     /**
> 499:      * Creates an {@code InetAddress} based on the provided {@linkplain
> 500:      * Inet6Address##format textual representations} of an IPv6 address.

"textual representations" -> "textual representation"

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

PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1680636868
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1361064729
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1361058480

From aefimov at openjdk.org  Mon Oct 16 19:03:34 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 19:03:34 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <ym0iAXXf3pPq-Cz6kHfp53nGGogEOx-lfAeKHo6CDP8=.4ec0055e-febb-4726-86ba-71ba7bc25ca9@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

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

  representations -> representation, add format section links, modify headings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/4bd63f29..af87fab2

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

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

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

From aefimov at openjdk.org  Mon Oct 16 19:03:38 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 16 Oct 2023 19:03:38 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v2]
In-Reply-To: <RYJWKsG2Yb5aOP2-KuooHsYvS8wdTF6dzKL6ybCvnx8=.f12307ea-5197-4482-8dc0-cf80f3995610@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <RYJWKsG2Yb5aOP2-KuooHsYvS8wdTF6dzKL6ybCvnx8=.f12307ea-5197-4482-8dc0-cf80f3995610@github.com>
Message-ID: <LKe1S_F2onPmp6d6LK3U5Nmi6CjdjU41oIit9UDdsys=.60bd39f1-697f-412f-9bbd-d23ea26fb54f@github.com>

On Mon, 16 Oct 2023 17:57:37 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   representations -> representation, add format section links, modify headings
>
> src/java.base/share/classes/java/net/Inet4Address.java line 166:
> 
>> 164:      * Creates an {@code Inet4Address} based on the provided {@linkplain
>> 165:      * Inet4Address##format textual representations} of an IPv4 address.
>> 166:      * <p> If the provided IPv4 address literal cannot represent a {@linkplain
> 
> "textual representations" -> "textual representation"

Thanks Michael, fixed in af87fab27148daa982ab1997a4346e8c29be7604

> src/java.base/share/classes/java/net/Inet6Address.java line 500:
> 
>> 498:     /**
>> 499:      * Creates an {@code InetAddress} based on the provided {@linkplain
>> 500:      * Inet6Address##format textual representations} of an IPv6 address.
> 
> "textual representations" -> "textual representation"

Fixed in af87fab27148daa982ab1997a4346e8c29be7604

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1361148707
PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1361149058

From duke at openjdk.org  Tue Oct 17 03:58:21 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 17 Oct 2023 03:58:21 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <H62AqoHHTmeZP_6X0cKCicOVcZNtuRj-faCHJSLWkjY=.8b27efd8-3cec-4f8b-95f7-3a85031cf598@github.com>

On Mon, 16 Oct 2023 09:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

src/java.base/share/classes/java/net/ProxySelector.java line 227:

> 225:             }
> 226:             scheme = scheme.toLowerCase(Locale.ROOT);
> 227:             if (scheme.equals("http") || scheme.equals("https")) {

maybe outside the scope of this PR, but could avoid the `toLowerCase`

Suggestion:

            if (scheme.equalsIgnoreCase("http") || scheme.equalsIgnoreCase("https")) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16199#discussion_r1361478833

From jkratochvil at openjdk.org  Tue Oct 17 08:18:32 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 17 Oct 2023 08:18:32 GMT
Subject: Integrated: 8317696: Fix compilation with clang-16
In-Reply-To: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
References: <LFc0wLBbKmsV6PS8DMy2Fv3HljQ_2XPZKaAe_CCPIqs=.8caae927-3fa1-498a-8540-98f1bc775d16@github.com>
Message-ID: <lV2Bro_NQHtuDqbDzd2Uh0MxsHYj6erStQ0RobV5Zuw=.ba9e74ed-ecef-475b-aec1-275e99e6766f@github.com>

On Sat, 7 Oct 2023 16:24:29 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> `--with-toolchain-type=clang` fails the compilation for me with `clang-16.0.6-3.fc38.x86_64`
> 
> While the warnings can be disabled I find better to just fix them. The GTK prototypes in JDK reported by clang are either missing or wrong. 
> 
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>     proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>                                         ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:397:63: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                                 (*g_network_address_parse_uri)(proxies[i], 0,
>                                                               ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:402:70: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             phost = (*g_network_address_get_hostname)(conn);
>                                                                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:403:66: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>                             pport = (*g_network_address_get_port)(conn);
>                                                                  ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:445:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_strfreev)(proxies);
>                      ^
> src/java.base/unix/native/libnet/DefaultProxySelector.c:448:25: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>         (*g_clear_error)(&error);
>                         ^
> Compiling X11Renderer.c (for libawt_headless.so)
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11PMBlitLoops.c:29:
> In file included from src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h:29:
> src/java.desktop/unix/native/common/aw...

This pull request has now been integrated.

Changeset: e4329a82
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4329a823bf9fd23c772342729ef4a4fb50381ac
Stats:     15 lines in 4 files changed: 0 ins; 2 del; 13 mod

8317696: Fix compilation with clang-16

Reviewed-by: djelinski, aivanov

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

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

From djelinski at openjdk.org  Tue Oct 17 08:50:41 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Oct 2023 08:50:41 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions [v2]
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <fqeilgBbAWJghIw8G4v7qckIlShGmieT2vPCaglpkgs=.46768e19-877c-463e-9677-73a977d0a04d@github.com>

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use equalsIgnoreCase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16199/files
  - new: https://git.openjdk.org/jdk/pull/16199/files/6ed6a983..66c79fa4

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

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

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

From djelinski at openjdk.org  Tue Oct 17 08:50:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Oct 2023 08:50:44 GMT
Subject: RFR: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions [v2]
In-Reply-To: <H62AqoHHTmeZP_6X0cKCicOVcZNtuRj-faCHJSLWkjY=.8b27efd8-3cec-4f8b-95f7-3a85031cf598@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
 <H62AqoHHTmeZP_6X0cKCicOVcZNtuRj-faCHJSLWkjY=.8b27efd8-3cec-4f8b-95f7-3a85031cf598@github.com>
Message-ID: <zNiKmMj0MuN90HgrJ0_0Gly8p7DWmfshDuNYu9vyThM=.5c1b6003-eaeb-4b6b-8c9f-135e82ee6396@github.com>

On Tue, 17 Oct 2023 03:53:22 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use equalsIgnoreCase
>
> src/java.base/share/classes/java/net/ProxySelector.java line 227:
> 
>> 225:             }
>> 226:             scheme = scheme.toLowerCase(Locale.ROOT);
>> 227:             if (scheme.equals("http") || scheme.equals("https")) {
> 
> maybe outside the scope of this PR, but could avoid the `toLowerCase`
> 
> Suggestion:
> 
>             if (scheme.equalsIgnoreCase("http") || scheme.equalsIgnoreCase("https")) {

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16199#discussion_r1361751625

From egahlin at openjdk.org  Tue Oct 17 10:39:34 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 17 Oct 2023 10:39:34 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events [v2]
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Update microbenchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15908/files
  - new: https://git.openjdk.org/jdk/pull/15908/files/3b398bc4..185f6bfa

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

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

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

From mgronlun at openjdk.org  Tue Oct 17 13:00:24 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 17 Oct 2023 13:00:24 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events [v2]
In-Reply-To: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
 <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com>
Message-ID: <StL9XOAf3EgImjycW2fxpbiT8athNi2akKtgtKJR7NM=.369ca9d2-4fa6-468c-8001-36c36db1f55a@github.com>

On Tue, 17 Oct 2023 10:39:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update microbenchmark

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1682264504

From egahlin at openjdk.org  Tue Oct 17 14:03:11 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 17 Oct 2023 14:03:11 GMT
Subject: Integrated: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <xJvbr7iwS00F-ncKQiVeRlXJFjeucSZJsdAwzM00D0Q=.546043a4-19ce-4c5a-b26c-064acf65765b@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 6aa837ee
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6aa837eee62c2243689142915abcd85db85d0eed
Stats:     55 lines in 5 files changed: 26 ins; 6 del; 23 mod

8316927: JFR: Move shouldCommit check earlier for socket events

Reviewed-by: alanb, dfuchs, mgronlun

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

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

From aefimov at openjdk.org  Tue Oct 17 15:58:19 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 17 Oct 2023 15:58:19 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v3]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <xFCHxZfjQfSKnytCKMYEoDha_1d9VHo9nFlS-Y3rOlc=.fb9cd7c5-e4b6-462a-9f39-018811916fa9@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

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

  add Inet6Address##input doc section for better sections separation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/af87fab2..6b3702ba

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

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

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

From v-terrychow at microsoft.com  Tue Oct 17 23:32:05 2023
From: v-terrychow at microsoft.com (Terry Chow (SIMBA TECHNOLOGIES INC))
Date: Tue, 17 Oct 2023 23:32:05 +0000
Subject: Request for review on JDK 17 backport of Windows extended socket
 options
Message-ID: <BYAPR21MB13015DCF0901F67322280C21E1D6A@BYAPR21MB1301.namprd21.prod.outlook.com>

Hello everyone,

I have an approved unclean JDK 17 backport of JDK-8308593<https://bugs.openjdk.org/browse/JDK-8308593> ready for review right here<https://github.com/openjdk/jdk17u-dev/pull/1751>. Let me know if I need to do anything else to progress this.

Thanks again,
Terry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231017/05e64b2e/attachment-0001.htm>

From dholmes at openjdk.org  Wed Oct 18 05:35:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Oct 2023 05:35:46 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
 <UVdVKMRqhPmOAI2RgE-kY1btCkHHJAdcOzPkOSdh9tY=.f6de512d-ac41-4c00-87fb-7554c6390052@github.com>
Message-ID: <-mnRIhYxnLvgUVnwxr_thupKgzfav_NdaT79AS1PO7M=.7cb2174c-9808-42ea-beb7-312ebab3e683@github.com>

On Mon, 16 Oct 2023 15:04:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   windows aarch64 build issues
>
> Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

@MBaesken I'm not at all sure what it would look like - sorry. But there doesn't seem to be any general support from the library folk for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1767673904

From ccleary at openjdk.org  Wed Oct 18 10:19:51 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 10:19:51 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v5]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <YGcMC8bf-qqU6ej1eCdT7OlJ0BdhKhdjK_m84sqPPMI=.6e38cb1e-77fd-4c10-9466-47f898940980@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

Conor Cleary 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 12 additional commits since the last revision:

 - 8309118: Update Comment in schedule()
 - Merge remote-tracking branch 'upstream/master' into JDK-8309118
 - 8309118: Remove irrelevant comments and logs
 - 8309118: Fixed error in handleReset ReentrantLock
 - 8309118: Updates to Stream cancelImpl
 - 8309118: Refactored test, updated incoming_reset
 - Merge branch 'master' into JDK-8309118
 - 8309118: Cleanup identifiers and whitespace
 - 8309118: Removed unused try-with-resources
 - 8309118: Improve comments and annotations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8d54aa4a...d74b08a0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/94e2e1d2..d74b08a0

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

  Stats: 27406 lines in 869 files changed: 15439 ins; 5991 del; 5976 mod
  Patch: https://git.openjdk.org/jdk/pull/15664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15664/head:pull/15664

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

From ccleary at openjdk.org  Wed Oct 18 14:33:01 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 14:33:01 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v5]
In-Reply-To: <YGcMC8bf-qqU6ej1eCdT7OlJ0BdhKhdjK_m84sqPPMI=.6e38cb1e-77fd-4c10-9466-47f898940980@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <YGcMC8bf-qqU6ej1eCdT7OlJ0BdhKhdjK_m84sqPPMI=.6e38cb1e-77fd-4c10-9466-47f898940980@github.com>
Message-ID: <jAhg4x0H5eij-_bC4fxZCwosK5aPz_CZHmI0jETCOU4=.a519be36-0dc9-4427-8909-26fac4fee74f@github.com>

On Wed, 18 Oct 2023 10:19:51 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary 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 12 additional commits since the last revision:
> 
>  - 8309118: Update Comment in schedule()
>  - Merge remote-tracking branch 'upstream/master' into JDK-8309118
>  - 8309118: Remove irrelevant comments and logs
>  - 8309118: Fixed error in handleReset ReentrantLock
>  - 8309118: Updates to Stream cancelImpl
>  - 8309118: Refactored test, updated incoming_reset
>  - Merge branch 'master' into JDK-8309118
>  - 8309118: Cleanup identifiers and whitespace
>  - 8309118: Removed unused try-with-resources
>  - 8309118: Improve comments and annotations
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/1db564b9...d74b08a0

This PR has generated a lot of discussion offline. If I were to summarise it comes down to a couple of points. `pendingResponseSubscriber` can be null when `receiveDataFrame(new DataFrame(streamid, DataFrame.END_STREAM, List.of()));` is called because `readBodyAsync` has not yet been called (which triggers the setting of `pendingResponseSubsrciber`). There was a lot of confusion around this but because it is necessary to work around the constraints of the `Exchange` class, this seems alright. `readBodyAsync` won't happen until data is received from the server after the client has received response headers. If there were any **actions** to come from this it would be to improve comments around this to make this more clear.

The new `endStreamSeenFlag` is used very specifically in my changes in two cases of processing a RST_STREAM frame from the server. Firstly, in the event the `pendingResponseSubscriber` is null (as in the case described above) and an END_STREAM flag has not been received by the client (so `endStreamSeen` is `false`) `handleReset` is called then and there to complete the `requestBodyCf` exceptionally. Secondly, in the event of `requestBodyCF` not being done or we are still sending the request body, `handleReset` is called straight away here too. So in essence its being used as a short-circuit to complete the requestBodyCf exceptionally. I would like to seek feedback on this specifically if there is any.

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1768593234

From ccleary at openjdk.org  Wed Oct 18 14:51:10 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 14:51:10 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
Message-ID: <q5x1N_iLx7oN1pd4iqOlCTaO1E8jTKLaEmkK2syPZ1w=.52dedae8-0d18-483c-b5ec-83ea3f920a52@github.com>

On Mon, 9 Oct 2023 13:25:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 234:
> 
>> 232:                 connections.values().forEach(this::close);
>> 233:                 connections.remove(entry.getKey(), entry.getValue());
>> 234:             }
> 
> I'd suggest to change `this::close(Http2Connection)` to return boolean (instead of void) and make it always return`true`, and then use `removeIf` instead of forEach:
> 
> 
> connections.values().removeIf(this::close);

So effect of your suggested changes is to remove the connection if close returns `true` as supposed to just removing all connections and

This change is not entirely related to this PR. I will revert it and create a seperate issue. Though the suggestion is good and I will apply it to the give fix for that issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364020253

From ccleary at openjdk.org  Wed Oct 18 14:54:03 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 14:54:03 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
Message-ID: <Oa8Sfw2BPKUC3h-7qv_8bRaGp6GhToFVO85NJI8Zikk=.13fae658-d044-434e-9562-170049acf36d@github.com>

On Mon, 9 Oct 2023 13:29:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 195:
> 
>> 193:                     if (endStreamReceived()) {
>> 194:                         // If END_STREAM is already received, we should not receive any new RST_STREAM frames and
>> 195:                         // close the connection gracefully by processing all remaining frames in the inputQ.
> 
> Suggestion:
> 
>                         // If END_STREAM is already received, we should we should simply
>                         // complete the requestBodyCF successfuly and stop sending any
>                         // request data.

How about just

// If END_STREAM is already received, complete the requestBodyCF successfully
// and stop sending any request data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364025064

From ccleary at openjdk.org  Wed Oct 18 15:02:04 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 15:02:04 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
Message-ID: <hYTVnlmjdVPDwOx5azA6lv-KGUW65pWvsxO8SpUUjdM=.010fe426-00c2-408b-af64-ea6ca21f7dd1@github.com>

On Mon, 9 Oct 2023 13:32:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 193:
> 
>> 191:                 if (frame instanceof ResetFrame rf) {
>> 192:                     inputQ.remove();
>> 193:                     if (endStreamReceived()) {
> 
> Suggestion:
> 
>                     if (endStreamReceived() && rf.getErrorCode() == ResetFrame.NO_ERROR) {

So if we have received an end stream but receive an error code, do we want to complete exceptionally? 

The suggestion seems correct, just checking ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364033231

From dfuchs at openjdk.org  Wed Oct 18 15:02:06 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Oct 2023 15:02:06 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <hYTVnlmjdVPDwOx5azA6lv-KGUW65pWvsxO8SpUUjdM=.010fe426-00c2-408b-af64-ea6ca21f7dd1@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
 <hYTVnlmjdVPDwOx5azA6lv-KGUW65pWvsxO8SpUUjdM=.010fe426-00c2-408b-af64-ea6ca21f7dd1@github.com>
Message-ID: <zVqjnvh_PNHVOgiWjw-GRCuPCqRFfPmnUe0LT0-SlJ4=.429b0a43-47b3-492f-8bf1-2a2fb898f9d5@github.com>

On Wed, 18 Oct 2023 14:56:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 193:
>> 
>>> 191:                 if (frame instanceof ResetFrame rf) {
>>> 192:                     inputQ.remove();
>>> 193:                     if (endStreamReceived()) {
>> 
>> Suggestion:
>> 
>>                     if (endStreamReceived() && rf.getErrorCode() == ResetFrame.NO_ERROR) {
>
> So if we have received an end stream but receive an error code, do we want to complete exceptionally? 
> 
> The suggestion seems correct, just checking ?

Yes - I believe so - the peer indicates an error - so we should complete exceptionally, if that's still possible.

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 195:
>> 
>>> 193:                     if (endStreamReceived()) {
>>> 194:                         // If END_STREAM is already received, we should not receive any new RST_STREAM frames and
>>> 195:                         // close the connection gracefully by processing all remaining frames in the inputQ.
>> 
>> Suggestion:
>> 
>>                         // If END_STREAM is already received, we should we should simply
>>                         // complete the requestBodyCF successfuly and stop sending any
>>                         // request data.
>
> How about just
> 
> // If END_STREAM is already received, complete the requestBodyCF successfully
> // and stop sending any request data.

works for me

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364035697
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364030258

From Alan.Bateman at oracle.com  Wed Oct 18 15:21:41 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Oct 2023 16:21:41 +0100
Subject: Request for JCK17 tests exclusion
In-Reply-To: <MW5PR84MB1641EB7322C9F9F97392BD178BD5A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
References: <CY5PR84MB3052235066E840A0453AFD4BA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB30524F451A5C7DD29E86BAFAA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <BF925AA7-559A-4450-B985-52BA127787C9@oracle.com>
 <CY5PR84MB3052D5E84FDB5EF85D981132A1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB3052F49458087B5CB2DD3A1DA1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DS7PR10MB50082698F39A57121C51AA47F9D3A@DS7PR10MB5008.namprd10.prod.outlook.com>
 <CY5PR84MB3052C8389F229D9EC9B3B44FA1D2A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DCD3E192-1B6D-4F2E-97D8-F52AC17ED242@oracle.com>
 <MW5PR84MB16410F1CE918E4C1E4B876CE8BD7A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
 <MW5PR84MB1641EB7322C9F9F97392BD178BD5A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <e5ae4040-ab96-a639-92cd-da4133113b97@oracle.com>

On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
> Hi,
>
> Please see the discussion in the following mails. One of the TCK test 
> cases, api/java_net/MulticastSocket/ClassLevel.html is failing on 
> NonStop platform as NonStop doesn't support?IP_MULTICAST_ALL option.
>
> We would like this test case to be excluded from TCK. Please share 
> your thoughts on this request.

I realize you have been directed here but this is not the right place to 
discuss TCK exclusion requests.

 From the mails you forwarded then it looks like there are issues with 
the multicast support in your port to NonStop. The IP_MULTICAST_ALL 
socket option you mention is used in the Linux port to avoid 
interference when two sockets are bound to the same port but joined to 
different multicast groups. Linux is an outlier in this scenario so the 
socket option is set to prevent the interference. My guess is that few 
people here will know NonStop but you could being porting questions on 
this code to net-dev.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231018/d31a4656/attachment.htm>

From ccleary at openjdk.org  Wed Oct 18 15:25:04 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 18 Oct 2023 15:25:04 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
Message-ID: <3BDe9NzDN7WgHWvIl7FTK1VERd7uVYmvhJz-QrnVr0Y=.965d6f59-ad4b-4431-b700-3362fddddb94@github.com>

On Mon, 9 Oct 2023 13:35:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 ten additional commits since the last revision:
>> 
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - 8309118: Remove local test timeout value
>>  - 8309118: Add more tests for 100 ExpectContinue with HTTP/2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 584:
> 
>> 582:     void incoming_reset(ResetFrame frame) {
>> 583:         Log.logTrace("Received RST_STREAM on stream {0}", streamid);
>> 584:         Flow.Subscriber<?> subscriber = responseSubscriber == null ? pendingResponseSubscriber : responseSubscriber;
> 
> Suggestion:
> 
>         Flow.Subscriber<?> subscriber = responseSubscriber;
>         if (subscriber == null) subscriber = pendingResponseSubscriber;
> 
> (avoids reading volatile twice)

Ah yes, I see I think. In either case of the conditional expression either `responseSubscriber` and `pendingResponseSubscriber` are read or `responseSubscriber` is read and `responseSubscriber` is read. I was confused for a bit because I thought only one operand is evaluated. But actually its the case that `responseSubscriber` is read twice when `responseSubscriber == null` evaluates to false.

Good suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1364079499

From ramadasu.nandagiri at hpe.com  Mon Oct 16 10:17:09 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Mon, 16 Oct 2023 10:17:09 +0000
Subject: Fw: Request for JCK17 tests exclusion
In-Reply-To: <DCD3E192-1B6D-4F2E-97D8-F52AC17ED242@oracle.com>
References: <CY5PR84MB3052235066E840A0453AFD4BA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB30524F451A5C7DD29E86BAFAA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <BF925AA7-559A-4450-B985-52BA127787C9@oracle.com>
 <CY5PR84MB3052D5E84FDB5EF85D981132A1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB3052F49458087B5CB2DD3A1DA1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DS7PR10MB50082698F39A57121C51AA47F9D3A@DS7PR10MB5008.namprd10.prod.outlook.com>
 <CY5PR84MB3052C8389F229D9EC9B3B44FA1D2A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DCD3E192-1B6D-4F2E-97D8-F52AC17ED242@oracle.com>
Message-ID: <MW5PR84MB16410F1CE918E4C1E4B876CE8BD7A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>

Hi,

Please see the discussion in the following mails. One of the TCK test cases, api/java_net/MulticastSocket/ClassLevel.html is failing on NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.

We would like this test case to be excluded from TCK. Please share your thoughts on this request.

Regards,
Ramdas
________________________________
From: conformance-octla-private <conformance-octla-private-retn at openjdk.org> on behalf of Dmitry Bessonov <dmitry.bessonov at oracle.com>
Sent: Saturday, October 14, 2023 3:23 PM
To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>
Cc: conformance-octla-private at openjdk.java.net <conformance-octla-private at openjdk.java.net>
Subject: Re: Request for JCK17 tests exclusion

Hi Suma,

Thank you for providing more details. They seem to be reflecting NonStop implementation specifics and issues, which may not be convincing reason to exclude a JCK test.

The test looks conforming to the specification and passes on the JavaSE 17 Reference Implementation. If you believe the test is incorrect we would appreciate to know where the test is making incorrect assumption or doesn't follow the specification.

If you think that there might be a problem with JavaSE 17 specification or the implementation per spec is not possible on your platform, the place for related communication could be net-dev at openjdk.org or core-libs-dev at openjdk.org.

Kind regards,
JCK Team


> On 13 Oct 2023, at 14:30, Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com> wrote:
>
> Thanks Krushna for your response.
>
> Thanks for excluding the testcase api/java_net/MulticastSocket/SupportedOptionsTest.html.
>
> Please find additional details from our side regarding the testcase api/java_net/MulticastSocket/ClassLevel.html.
>
> Snippet from your mail:
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> Our response:  We compared NonStop Java code for socket creation with Linux specific Java code. On Linux, testcase passes because it supports IP_MULTICAST_ALL option as given below(See: code snippet). It disables IP_MULTICAST_ALL for the socket created on Linux. We have compared C and Java testcase behavior on Linux. We have observed that IP_MULTICAST_ALL makes the difference.  NonStop CIP stack (aka TCP/IP stack)  doesn't have the behavior of enabling/disabling of IP_MULTICAST_ALL option as it is not supported. Hence, the testcase fails on the NonStop platform. So, we are requesting for the exclusion of the testcase.
>
> #if defined(__linux__)
>    if (type == SOCK_DGRAM) {
>        int arg = 0;
>        int level = (domain == AF_INET6) ? IPPROTO_IPV6 : IPPROTO_IP;
>        if ((setsockopt(fd, level, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) &&
>            (errno != ENOPROTOOPT)) {
>            JNU_ThrowByNameWithLastError(env,
>                                         JNU_JAVANETPKG "SocketException",
>                                         "Unable to set IP_MULTICAST_ALL");
>            close(fd);
>            return -1;
>        }
>    }
> ..
> ..
> #endif
>
> As per the manual for IPv4 implementation on Linux:
> IP_MULTICAST_ALL (since Linux 2.6.31)
>              This option can be used to modify the delivery policy of
>              multicast messages.  The argument is a boolean integer
>              (defaults to 1).  If set to 1, the socket will receive
>              messages from all the groups that have been joined
>              globally on the whole system.  Otherwise, it will deliver
>              messages only from the groups that have been explicitly
>              joined (for example via the IP_ADD_MEMBERSHIP option) on
>              this particular socket.
>
> Please let us know if you need any other information on the same.
> Thanks and regards,
> Suma
>
> -----Original Message-----
> From: Krushnareddy Ganapureddy <krushnareddy.ganapureddy at oracle.com>
> Sent: Thursday, October 12, 2023 4:04 PM
> To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>; conformance-octla-private at openjdk.java.net
> Cc: Nandagiri, Ramadasu (NSDi) <ramadasu.nandagiri at hpe.com>; Gragg, Jeffrey <jeff.gragg at hpe.com>
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Suma,
>
> - api/java_net/MulticastSocket/ClassLevel.html
>
> The test expectations as per Java SE conformance specification: (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/MulticastSocket.html ) "When a socket subscribes to a multicast group/port, it receives datagrams sent by other hosts to the group/port, as do all other members of the group and port. A socket relinquishes membership in a group by the leaveGroup(SocketAddress mcastaddr, NetworkInterface netIf) method. "
>
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> - api/java_net/MulticastSocket/SupportedOptionsTest.html ,  we would be excluding this.
>
> Thanks & regards,
> Krushna.
>
>
> -----Original Message-----
> From: conformance-octla-private <conformance-octla-private-retn at openjdk.org> On Behalf Of Bhat, Suma Mudakare Bheema (NSDi)
> Sent: Monday, October 9, 2023 3:20 PM
> To: conformance-octla-private at openjdk.java.net; Dmitry Bessonov <dmitry.bessonov at oracle.com>
> Cc: Nandagiri, Ramadasu (NSDi) <ramadasu.nandagiri at hpe.com>; Gragg, Jeffrey <jeff.gragg at hpe.com>
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Dmitry,
> Thanks for your inputs. Please find updated tests exclusion request for two tests as below.
>
> Test Challenger Name and Company: Hewlett Packard Enterprise Specification Name(s) and Version(s): Java Platform SE 17 API Specifications Test Suite Name and Version: JCK-runtime-17 Exclude List Version: jck-17-upd-exc-23_jun_2023 Tests Name: api/java_net/MulticastSocket/ClassLevel.html
>                                           api/java_net/MulticastSocket/SupportedOptionsTest.html
>
> Complaint (argument for why test is invalid):
> For testcase : api/java_net/MulticastSocket/ClassLevel.html:
> We are challenging this test case based on " Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_ALL, and also there is no equivalent option.
> For the testcase (api/java_net/MulticastSocket/SupportedOptionsTest.html), it needs support for Multicast Socket (IP_MULTICAST_ALL) in the native platform to pass. With the lack of support for multicast support in the native platform, this testcase fails on NonStop.
> I have attached .jtr file for this issue (ClassLevel.jtr)
>
> For testcase: api/java_net/MulticastSocket/SupportedOptionsTest.html:
> We are challenging this test case based on "Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_IF on a loop back interface.
> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
> Hence, this testcase fails. We think, either check for this support should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option in the testcase, Or this testcase should be excluded.
> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>
> There is no specific mention about these socket options in our networking manual. Hence, I have attached the mail communication with our networking team regarding the non-supportability of these options on NonStop.
>
> Thanks and Regards,
> Suma
>
>
> -----Original Message-----
> From: Dmitry Bessonov <dmitry.bessonov at oracle.com>
> Sent: Tuesday, October 3, 2023 2:12 AM
> To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>
> Cc: conformance-octla-private at openjdk.java.net
> Subject: Re: Request for TCK17 tests exclusion
>
> Hi Suma,
>
> We would much appreciate to have more information regarding specifically which exact part of the normative JavaSE 17 specification the tests contradict.
>
> This would help to process the challenge following JCK17 User?s Guide, Chapter 2.3 "JCK Test Appeals Process?. It would allow to confirm each test?s validity or invalidity which are determined basing on technical correctness - see 2.3 for the possible list of justifications. Please note that the same Chapter 2.3 also mentions that "challenges based upon issues unrelated to technical correctness as defined by the specification will normally be rejected.?
>
> Thank you in advance,
>
> Best Regards,
> JCK Team
>
>> On 28 Sep 2023, at 13:55, Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com> wrote:
>>
>> Hi,
>> Test Challenger Name and Company: Hewlett Packard Enterprise
>> Specification Name(s) and Version(s): Java Platform SE 17 API
>> Specifications Test Suite Name and Version: JCK-runtime-17 Exclude
>> List Version: jck-17-upd-exc-23_jun_2023 Tests Name:
>> api/java_net/MulticastSocket/ClassLevel.html
>>
>> api/java_net/MulticastSocket/SupportedOptionsTest.html
>> Complaint (argument for why test is invalid):
>> api/java_net/MulticastSocket/ClassLevel.html:
>> For this testcase, it needs support for Multicast Socket (IP_MULTICAST_ALL)  to modify the delivery policy of multicast messages, in the native platform.
>> Our platform NonStop doesn?t have IP_MULTICAST_ALL  support.
>> With the lack of support for multicast support, this testcase fails.
>> I have attached .jtr file for this issue (ClassLevel.jtr)
>> api/java_net/MulticastSocket/SupportedOptionsTest.html:
>> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
>> Hence, this testcase fails. We think, either check for this support
>> should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option, Or this testcase should be excluded.
>> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>> Thanks and Regards, Suma
>>
>> <ClassLevel.jtr><SupportedOptionsTest.jtr>____________________________
>> ___________________ conformance-octla-private mailing list
>> conformance-octla-private at openjdk.org
>> INVALID URI REMOVED
>> conformance-octla-private__;!!NpxR!jgSANkxAYFdYELEXkxw4jk5YRV4TCNjtfsB
>> r3RNqovQ_kJm-0GhnL11uJ1NWAqPLjae2NMkD_NlG-m3Yg49hnNZf2rY$
>
>
> _______________________________________________
> conformance-octla-private mailing list
> conformance-octla-private at openjdk.org
> https://mail.openjdk.org/mailman/listinfo/conformance-octla-private

_______________________________________________
conformance-octla-private mailing list
conformance-octla-private at openjdk.org
https://mail.openjdk.org/mailman/listinfo/conformance-octla-private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231016/9b014a2b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ClassLevel.jtr
Type: application/octet-stream
Size: 15975 bytes
Desc: ClassLevel.jtr
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231016/9b014a2b/ClassLevel-0001.jtr>

From ramadasu.nandagiri at hpe.com  Wed Oct 18 14:55:04 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Wed, 18 Oct 2023 14:55:04 +0000
Subject: Request for JCK17 tests exclusion
In-Reply-To: <MW5PR84MB16410F1CE918E4C1E4B876CE8BD7A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
References: <CY5PR84MB3052235066E840A0453AFD4BA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB30524F451A5C7DD29E86BAFAA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <BF925AA7-559A-4450-B985-52BA127787C9@oracle.com>
 <CY5PR84MB3052D5E84FDB5EF85D981132A1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB3052F49458087B5CB2DD3A1DA1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DS7PR10MB50082698F39A57121C51AA47F9D3A@DS7PR10MB5008.namprd10.prod.outlook.com>
 <CY5PR84MB3052C8389F229D9EC9B3B44FA1D2A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DCD3E192-1B6D-4F2E-97D8-F52AC17ED242@oracle.com>
 <MW5PR84MB16410F1CE918E4C1E4B876CE8BD7A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <MW5PR84MB1641EB7322C9F9F97392BD178BD5A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>

Hi,

Please see the discussion in the following mails. One of the TCK test cases, api/java_net/MulticastSocket/ClassLevel.html is failing on NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.

We would like this test case to be excluded from TCK. Please share your thoughts on this request.

Regards,
Ramdas
________________________________
From: conformance-octla-private <conformance-octla-private-retn at openjdk.org> on behalf of Dmitry Bessonov <dmitry.bessonov at oracle.com>
Sent: Saturday, October 14, 2023 3:23 PM
To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>
Cc: conformance-octla-private at openjdk.java.net <conformance-octla-private at openjdk.java.net>
Subject: Re: Request for JCK17 tests exclusion

Hi Suma,

Thank you for providing more details. They seem to be reflecting NonStop implementation specifics and issues, which may not be convincing reason to exclude a JCK test.

The test looks conforming to the specification and passes on the JavaSE 17 Reference Implementation. If you believe the test is incorrect we would appreciate to know where the test is making incorrect assumption or doesn't follow the specification.

If you think that there might be a problem with JavaSE 17 specification or the implementation per spec is not possible on your platform, the place for related communication could be net-dev at openjdk.org or core-libs-dev at openjdk.org.

Kind regards,
JCK Team


> On 13 Oct 2023, at 14:30, Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com> wrote:
>
> Thanks Krushna for your response.
>
> Thanks for excluding the testcase api/java_net/MulticastSocket/SupportedOptionsTest.html.
>
> Please find additional details from our side regarding the testcase api/java_net/MulticastSocket/ClassLevel.html.
>
> Snippet from your mail:
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> Our response:  We compared NonStop Java code for socket creation with Linux specific Java code. On Linux, testcase passes because it supports IP_MULTICAST_ALL option as given below(See: code snippet). It disables IP_MULTICAST_ALL for the socket created on Linux. We have compared C and Java testcase behavior on Linux. We have observed that IP_MULTICAST_ALL makes the difference.  NonStop CIP stack (aka TCP/IP stack)  doesn't have the behavior of enabling/disabling of IP_MULTICAST_ALL option as it is not supported. Hence, the testcase fails on the NonStop platform. So, we are requesting for the exclusion of the testcase.
>
> #if defined(__linux__)
>    if (type == SOCK_DGRAM) {
>        int arg = 0;
>        int level = (domain == AF_INET6) ? IPPROTO_IPV6 : IPPROTO_IP;
>        if ((setsockopt(fd, level, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) &&
>            (errno != ENOPROTOOPT)) {
>            JNU_ThrowByNameWithLastError(env,
>                                         JNU_JAVANETPKG "SocketException",
>                                         "Unable to set IP_MULTICAST_ALL");
>            close(fd);
>            return -1;
>        }
>    }
> ..
> ..
> #endif
>
> As per the manual for IPv4 implementation on Linux:
> IP_MULTICAST_ALL (since Linux 2.6.31)
>              This option can be used to modify the delivery policy of
>              multicast messages.  The argument is a boolean integer
>              (defaults to 1).  If set to 1, the socket will receive
>              messages from all the groups that have been joined
>              globally on the whole system.  Otherwise, it will deliver
>              messages only from the groups that have been explicitly
>              joined (for example via the IP_ADD_MEMBERSHIP option) on
>              this particular socket.
>
> Please let us know if you need any other information on the same.
> Thanks and regards,
> Suma
>
> -----Original Message-----
> From: Krushnareddy Ganapureddy <krushnareddy.ganapureddy at oracle.com>
> Sent: Thursday, October 12, 2023 4:04 PM
> To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>; conformance-octla-private at openjdk.java.net
> Cc: Nandagiri, Ramadasu (NSDi) <ramadasu.nandagiri at hpe.com>; Gragg, Jeffrey <jeff.gragg at hpe.com>
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Suma,
>
> - api/java_net/MulticastSocket/ClassLevel.html
>
> The test expectations as per Java SE conformance specification: (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/MulticastSocket.html ) "When a socket subscribes to a multicast group/port, it receives datagrams sent by other hosts to the group/port, as do all other members of the group and port. A socket relinquishes membership in a group by the leaveGroup(SocketAddress mcastaddr, NetworkInterface netIf) method. "
>
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> - api/java_net/MulticastSocket/SupportedOptionsTest.html ,  we would be excluding this.
>
> Thanks & regards,
> Krushna.
>
>
> -----Original Message-----
> From: conformance-octla-private <conformance-octla-private-retn at openjdk.org> On Behalf Of Bhat, Suma Mudakare Bheema (NSDi)
> Sent: Monday, October 9, 2023 3:20 PM
> To: conformance-octla-private at openjdk.java.net; Dmitry Bessonov <dmitry.bessonov at oracle.com>
> Cc: Nandagiri, Ramadasu (NSDi) <ramadasu.nandagiri at hpe.com>; Gragg, Jeffrey <jeff.gragg at hpe.com>
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Dmitry,
> Thanks for your inputs. Please find updated tests exclusion request for two tests as below.
>
> Test Challenger Name and Company: Hewlett Packard Enterprise Specification Name(s) and Version(s): Java Platform SE 17 API Specifications Test Suite Name and Version: JCK-runtime-17 Exclude List Version: jck-17-upd-exc-23_jun_2023 Tests Name: api/java_net/MulticastSocket/ClassLevel.html
>                                           api/java_net/MulticastSocket/SupportedOptionsTest.html
>
> Complaint (argument for why test is invalid):
> For testcase : api/java_net/MulticastSocket/ClassLevel.html:
> We are challenging this test case based on " Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_ALL, and also there is no equivalent option.
> For the testcase (api/java_net/MulticastSocket/SupportedOptionsTest.html), it needs support for Multicast Socket (IP_MULTICAST_ALL) in the native platform to pass. With the lack of support for multicast support in the native platform, this testcase fails on NonStop.
> I have attached .jtr file for this issue (ClassLevel.jtr)
>
> For testcase: api/java_net/MulticastSocket/SupportedOptionsTest.html:
> We are challenging this test case based on "Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_IF on a loop back interface.
> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
> Hence, this testcase fails. We think, either check for this support should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option in the testcase, Or this testcase should be excluded.
> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>
> There is no specific mention about these socket options in our networking manual. Hence, I have attached the mail communication with our networking team regarding the non-supportability of these options on NonStop.
>
> Thanks and Regards,
> Suma
>
>
> -----Original Message-----
> From: Dmitry Bessonov <dmitry.bessonov at oracle.com>
> Sent: Tuesday, October 3, 2023 2:12 AM
> To: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>
> Cc: conformance-octla-private at openjdk.java.net
> Subject: Re: Request for TCK17 tests exclusion
>
> Hi Suma,
>
> We would much appreciate to have more information regarding specifically which exact part of the normative JavaSE 17 specification the tests contradict.
>
> This would help to process the challenge following JCK17 User?s Guide, Chapter 2.3 "JCK Test Appeals Process?. It would allow to confirm each test?s validity or invalidity which are determined basing on technical correctness - see 2.3 for the possible list of justifications. Please note that the same Chapter 2.3 also mentions that "challenges based upon issues unrelated to technical correctness as defined by the specification will normally be rejected.?
>
> Thank you in advance,
>
> Best Regards,
> JCK Team
>
>> On 28 Sep 2023, at 13:55, Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com> wrote:
>>
>> Hi,
>> Test Challenger Name and Company: Hewlett Packard Enterprise
>> Specification Name(s) and Version(s): Java Platform SE 17 API
>> Specifications Test Suite Name and Version: JCK-runtime-17 Exclude
>> List Version: jck-17-upd-exc-23_jun_2023 Tests Name:
>> api/java_net/MulticastSocket/ClassLevel.html
>>
>> api/java_net/MulticastSocket/SupportedOptionsTest.html
>> Complaint (argument for why test is invalid):
>> api/java_net/MulticastSocket/ClassLevel.html:
>> For this testcase, it needs support for Multicast Socket (IP_MULTICAST_ALL)  to modify the delivery policy of multicast messages, in the native platform.
>> Our platform NonStop doesn?t have IP_MULTICAST_ALL  support.
>> With the lack of support for multicast support, this testcase fails.
>> I have attached .jtr file for this issue (ClassLevel.jtr)
>> api/java_net/MulticastSocket/SupportedOptionsTest.html:
>> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
>> Hence, this testcase fails. We think, either check for this support
>> should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option, Or this testcase should be excluded.
>> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>> Thanks and Regards, Suma
>>
>> <ClassLevel.jtr><SupportedOptionsTest.jtr>____________________________
>> ___________________ conformance-octla-private mailing list
>> conformance-octla-private at openjdk.org
>> INVALID URI REMOVED
>> conformance-octla-private__;!!NpxR!jgSANkxAYFdYELEXkxw4jk5YRV4TCNjtfsB
>> r3RNqovQ_kJm-0GhnL11uJ1NWAqPLjae2NMkD_NlG-m3Yg49hnNZf2rY$
>
>
> _______________________________________________
> conformance-octla-private mailing list
> conformance-octla-private at openjdk.org
> https://mail.openjdk.org/mailman/listinfo/conformance-octla-private

_______________________________________________
conformance-octla-private mailing list
conformance-octla-private at openjdk.org
https://mail.openjdk.org/mailman/listinfo/conformance-octla-private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231018/2a1f762f/attachment-0001.htm>

From ramadasu.nandagiri at hpe.com  Wed Oct 18 17:47:46 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Wed, 18 Oct 2023 17:47:46 +0000
Subject: Request for JCK17 tests exclusion
In-Reply-To: <e5ae4040-ab96-a639-92cd-da4133113b97@oracle.com>
References: <CY5PR84MB3052235066E840A0453AFD4BA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB30524F451A5C7DD29E86BAFAA1C1A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <BF925AA7-559A-4450-B985-52BA127787C9@oracle.com>
 <CY5PR84MB3052D5E84FDB5EF85D981132A1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <CY5PR84MB3052F49458087B5CB2DD3A1DA1CEA@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DS7PR10MB50082698F39A57121C51AA47F9D3A@DS7PR10MB5008.namprd10.prod.outlook.com>
 <CY5PR84MB3052C8389F229D9EC9B3B44FA1D2A@CY5PR84MB3052.NAMPRD84.PROD.OUTLOOK.COM>
 <DCD3E192-1B6D-4F2E-97D8-F52AC17ED242@oracle.com>
 <MW5PR84MB16410F1CE918E4C1E4B876CE8BD7A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
 <MW5PR84MB1641EB7322C9F9F97392BD178BD5A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>
 <e5ae4040-ab96-a639-92cd-da4133113b97@oracle.com>
Message-ID: <MW5PR84MB1641D24CBEED1540D41995588BD5A@MW5PR84MB1641.NAMPRD84.PROD.OUTLOOK.COM>

Hi Alan,

Thanks for your response and the suggestion. I have copied, net-dev on my original mail. I will wait for a response from net-dev group.

Regards,
Ramdas
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Wednesday, October 18, 2023 8:51 PM
To: Nandagiri, Ramadasu (NSDi) <ramadasu.nandagiri at hpe.com>; net-dev at openjdk.org <net-dev at openjdk.org>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Bhat, Suma Mudakare Bheema (NSDi) <suma.mud.bhat at hpe.com>; Gragg, Jeffrey <jeff.gragg at hpe.com>
Subject: Re: Request for JCK17 tests exclusion

On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
Hi,

Please see the discussion in the following mails. One of the TCK test cases, api/java_net/MulticastSocket/ClassLevel.html is failing on NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.

We would like this test case to be excluded from TCK. Please share your thoughts on this request.

I realize you have been directed here but this is not the right place to discuss TCK exclusion requests.

>From the mails you forwarded then it looks like there are issues with the multicast support in your port to NonStop. The IP_MULTICAST_ALL socket option you mention is used in the Linux port to avoid interference when two sockets are bound to the same port but joined to different multicast groups. Linux is an outlier in this scenario so the socket option is set to prevent the interference. My guess is that few people here will know NonStop but you could being porting questions on this code to net-dev.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231018/c89c830f/attachment.htm>

From ccleary at openjdk.org  Thu Oct 19 12:36:22 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 19 Oct 2023 12:36:22 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

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

  schedule completes normally on NO_ERROR, incoming_reset safely accesses volataile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/d74b08a0..6bf25d12

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

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

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

From ccleary at openjdk.org  Thu Oct 19 13:56:04 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 19 Oct 2023 13:56:04 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v3]
In-Reply-To: <q5x1N_iLx7oN1pd4iqOlCTaO1E8jTKLaEmkK2syPZ1w=.52dedae8-0d18-483c-b5ec-83ea3f920a52@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <gtFQ-qL3Amj8A3YE4PEchr830d7b5dKn5bz5CjCfj1g=.4b45e1c8-ec89-4da5-8f4d-5b03a9cb43df@github.com>
 <4Pxb92hlZoaXrthV5K0bBktnr71YupMup9zopkaeJ78=.27ed1086-302f-4412-ac5e-ec40330be099@github.com>
 <q5x1N_iLx7oN1pd4iqOlCTaO1E8jTKLaEmkK2syPZ1w=.52dedae8-0d18-483c-b5ec-83ea3f920a52@github.com>
Message-ID: <RNcJDy6ZzQabbcxDWGZwvkEYGQhfr0VoQYxnSpFPXtU=.58a61f10-fccf-4320-b381-240befa6f917@github.com>

On Wed, 18 Oct 2023 14:48:04 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 234:
>> 
>>> 232:                 connections.values().forEach(this::close);
>>> 233:                 connections.remove(entry.getKey(), entry.getValue());
>>> 234:             }
>> 
>> I'd suggest to change `this::close(Http2Connection)` to return boolean (instead of void) and make it always return`true`, and then use `removeIf` instead of forEach:
>> 
>> 
>> connections.values().removeIf(this::close);
>
> So effect of your suggested changes is to remove the connection if close returns `true` as supposed to just removing all connections
> 
> This change is not entirely related to this PR. I will revert it and create a seperate issue. Though the suggestion is good and I will apply it to the give fix for that issue.

https://bugs.openjdk.org/browse/JDK-8318492

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1365584980

From Shruthi.Shruthi1 at ibm.com  Thu Oct 19 12:04:33 2023
From: Shruthi.Shruthi1 at ibm.com (Shruthi Shruthi1)
Date: Thu, 19 Oct 2023 12:04:33 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11
In-Reply-To: <SJ0PR15MB4663FA8EBE047F5DC21A4997CCE0A@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>
 <SJ0PR15MB4663715DCC2734DB0A73BA19CC1CA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <4b90ccda-5660-04f4-544d-bf9f940c1d27@oracle.com>
 <SJ0PR15MB4663FA8EBE047F5DC21A4997CCE0A@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <SJ0PR15MB46632C45E5A1DF88C4395568CCD4A@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan.,

Apologies for the delay. I ran the tests under java/nio/ch and the below 3 test cases are failing in AIX. The same tests pass in Linux

AsyncCloseAndInterrupt.java
Leaky.java

StressLoopback.java



Thanks
Shruthi

________________________________
From: Shruthi Shruthi1 <Shruthi.Shruthi1 at ibm.com>
Sent: Monday, August 28, 2023 11:02 AM
To: Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen1 <smoinud1 at in.ibm.com>
Subject: Re: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11

Hi Alan.,

Thanks for the suggestion. We are looking into these test cases and will get back on the results

Thanks
Shruthi
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Thursday, August 24, 2023 1:16 PM
To: Shruthi Shruthi1 <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen1 <smoinud1 at in.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11

On 23/08/2023 15:?16, Shruthi Shruthi1 wrote: Hi Alan.?, We are seeing the issue in AIX 7.?2 and Java 11.?0.?11+9. And SO_LINGER is not enabled. There's not much to go on here. A starting point would be to see if the nio/channels tests are passing
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2c-hSP9fQNPwMAYbeEGFjcU2NHnBhmlfjpkEeeKXyBD9eNKbCrozoi4Ezk1kwBG8z84SFfVoJQF61v-W9dNo82UWwvv7QcOuAEV9AQ$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
On 23/08/2023 15:16, Shruthi Shruthi1 wrote:
Hi Alan.,

We are seeing the issue in AIX 7.2 and Java 11.0.11+9. And SO_LINGER is not enabled.

There's not much to go on here. A starting point would be to see if the nio/channels tests are passing on this operating system. There are several tests that exercise async close. If there is OS issue then it might happen with the async close of Socket too.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20231019/91929c0f/attachment-0001.htm>

From djelinski at openjdk.org  Fri Oct 20 06:20:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 06:20:55 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
Message-ID: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>

This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.

The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.

The proposed code does not percent-encode the IPv6 addresses at all.

Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs

Tier1-3 tests passed.

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

Commit messages:
 - Do not urlencode IPv6 addresses

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

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

From djelinski at openjdk.org  Fri Oct 20 06:21:45 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 06:21:45 GMT
Subject: Integrated: 8318150: StaticProxySelector.select should not throw
 NullPointerExceptions
In-Reply-To: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
References: <ACGyDWMwuvFSidT_id3mQgkMZb-bRlxI9lfERUQWDpQ=.e9f1bf6e-6e29-48fd-8835-db29a2674cd8@github.com>
Message-ID: <vUGGkBjZ4Fs_WgNkLCjprbyotQBNFG4iegBZdSHbpx4=.8a8990d7-b465-4c81-bf50-961943ac8514@github.com>

On Mon, 16 Oct 2023 09:21:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `ProxySelector.select` and `connectFailed` methods should throw `IllegalArgumentException`s on null parameters.
> 
> Additionally, the `select` method doesn't need to be synchronized - the selector is immutable.
> 
> Tier2 green.

This pull request has now been integrated.

Changeset: d9ce525a
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9ce525a1c27f41ef66c39b3ec18e3a87bbd8dd3
Stats:     75 lines in 2 files changed: 18 ins; 25 del; 32 mod

8318150: StaticProxySelector.select should not throw NullPointerExceptions

Reviewed-by: jpai, dfuchs

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

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

From alanb at openjdk.org  Fri Oct 20 07:36:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 07:36:36 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <ZvEFMzdPKu-cZobkZx9r1RG1tnG9NaTvG8JOXKepP4E=.eb7205de-af86-42ad-bad8-b307228f3bbf@github.com>

On Thu, 19 Oct 2023 12:10:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

Reading this makes me wonder if there are cases where ProxySelector.getDefault() returns null? I had thought we would only have a ProxySelector on macOS or when there is configuration but it looks like sun.net.spi.DefaultProxySelector will always be loaded. Do I read this correctly? The reason for asking is that I'm surprised the modified code is used for the common case, I expected it would only be used when there is configuration.

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

PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1772231280

From djelinski at openjdk.org  Fri Oct 20 08:05:36 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 08:05:36 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <6vqVdRZQbpwLQICuefoSF5S93oQigvA0OfoWXx1Nyo4=.6373319a-c2de-4888-88b2-dc30cf9a3dcf@github.com>

On Thu, 19 Oct 2023 12:10:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

ProxySelector.getDefault may return null if someone explicitly calls ProxySelector.setDefault(null); otherwise it's initialized to an instance of DefaultProxySelector [here](https://github.com/openjdk/jdk/blob/4812cabaa489e99481facddce69686a9fee29c44/src/java.base/share/classes/java/net/ProxySelector.java#L73-L78).

The modified code is used for the common case. DefaultProxySelector reads system proxy settings every time.

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

PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1772269000

From alanb at openjdk.org  Fri Oct 20 08:40:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 08:40:38 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <6vqVdRZQbpwLQICuefoSF5S93oQigvA0OfoWXx1Nyo4=.6373319a-c2de-4888-88b2-dc30cf9a3dcf@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <6vqVdRZQbpwLQICuefoSF5S93oQigvA0OfoWXx1Nyo4=.6373319a-c2de-4888-88b2-dc30cf9a3dcf@github.com>
Message-ID: <IXGARmr7EVHjkQuQQmjkNjC8jmuahpomsF5PVwTA1Zk=.e9c6fb83-6142-4176-9137-b0660debbcc5@github.com>

On Fri, 20 Oct 2023 08:03:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> ProxySelector.getDefault may return null if someone explicitly calls ProxySelector.setDefault(null); otherwise it's initialized to an instance of DefaultProxySelector

Right, I guess part of my puzzlement is to understand why ProxySelector loads sun.net.spi.DefaultProxySelector reflectively. Slightly off topic from this PR but it looks like this is left over from the past.

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

PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1772317249

From djelinski at openjdk.org  Fri Oct 20 09:25:34 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 09:25:34 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <IXGARmr7EVHjkQuQQmjkNjC8jmuahpomsF5PVwTA1Zk=.e9c6fb83-6142-4176-9137-b0660debbcc5@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <6vqVdRZQbpwLQICuefoSF5S93oQigvA0OfoWXx1Nyo4=.6373319a-c2de-4888-88b2-dc30cf9a3dcf@github.com>
 <IXGARmr7EVHjkQuQQmjkNjC8jmuahpomsF5PVwTA1Zk=.e9c6fb83-6142-4176-9137-b0660debbcc5@github.com>
Message-ID: <4nvkBrafr3SJIkcupYBgcTErWZOy_OoDcVT9K5sWp9Q=.5810f884-ddc7-4aaa-9647-e2877ce760e7@github.com>

On Fri, 20 Oct 2023 08:37:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> why ProxySelector loads sun.net.spi.DefaultProxySelector reflectively.

Yeah, I was curious about that too; as far as I can tell, this won't prevent a class loader deadlock, and I can't think of any other reason. I can file a PR to simplify that.

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

PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1772383865

From michaelm at openjdk.org  Fri Oct 20 09:46:27 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 20 Oct 2023 09:46:27 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <y-Ka-W28sazLrJOmeO5-Cb4FMZHFaoyP8qS3Z1S_cUU=.87c34d45-39bb-4e40-92e5-1c83871d1f5e@github.com>

On Thu, 19 Oct 2023 12:10:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

src/java.base/share/classes/java/net/SocksSocketImpl.java line 304:

> 302:             if (epoint.getAddress() instanceof Inet6Address &&
> 303:                     (host.indexOf(':') >= 0) &&
> 304:                     isIPv6LiteralAddress(host)) {

Is the check at line 303 still needed, now we are calling `isIPv6LiteralAddress` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16265#discussion_r1366738514

From djelinski at openjdk.org  Fri Oct 20 10:45:36 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 10:45:36 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses
In-Reply-To: <y-Ka-W28sazLrJOmeO5-Cb4FMZHFaoyP8qS3Z1S_cUU=.87c34d45-39bb-4e40-92e5-1c83871d1f5e@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <y-Ka-W28sazLrJOmeO5-Cb4FMZHFaoyP8qS3Z1S_cUU=.87c34d45-39bb-4e40-92e5-1c83871d1f5e@github.com>
Message-ID: <oAtlCMwF6yyvgZ-Oj8rRtT3PllTMf0wUBvd-QjsCjZE=.94991250-7edd-4d18-85b0-50fd30d46966@github.com>

On Fri, 20 Oct 2023 09:43:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> src/java.base/share/classes/java/net/SocksSocketImpl.java line 304:
> 
>> 302:             if (epoint.getAddress() instanceof Inet6Address &&
>> 303:                     (host.indexOf(':') >= 0) &&
>> 304:                     isIPv6LiteralAddress(host)) {
> 
> Is the check at line 303 still needed, now we are calling `isIPv6LiteralAddress` ?

it's optional, as is the check for `:`. I'll remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16265#discussion_r1366805909

From djelinski at openjdk.org  Fri Oct 20 12:00:51 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 20 Oct 2023 12:00:51 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16265/files
  - new: https://git.openjdk.org/jdk/pull/16265/files/0f8e4671..9e3cd23c

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

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

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

From jpai at openjdk.org  Mon Oct 23 12:27:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 12:27:40 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
Message-ID: <c_G21Aq3XujNcBh9CpdCKTdlx8oLcXjIWotVeZ7LWqk=.2b1527d9-4096-46b1-b85e-419726618135@github.com>

On Fri, 20 Oct 2023 12:00:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant checks

src/java.base/share/classes/java/net/SocksSocketImpl.java line 307:

> 305:                 host = ParseUtil.encodePath(host);
> 306:             }
> 307:             // IPv6 literal?

Hello Daniel, this comment seems to have been misplaced. I think it should have been a few lines above just when `isIPv6LiteralAddress` is being called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16265#discussion_r1368574870

From dfuchs at openjdk.org  Mon Oct 23 13:13:39 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 23 Oct 2023 13:13:39 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
Message-ID: <nj9nkJMaVgN9DB9xusnkjuOxsEgbOLgmTwbAgWihRaU=.53c7a2be-d3f3-4ba1-9862-c0de538c4c53@github.com>

On Fri, 20 Oct 2023 12:00:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant checks

LGTM - except for the misplaced comment that Jaikiran spotted. I thought I had already commented on that Friday but it was still "pending" (sigh).

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

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692501299

From jpai at openjdk.org  Mon Oct 23 13:38:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 13:38:39 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
Message-ID: <P36G7EVtg30HP-ipRXzsE84cw9xtRdlRwhtwm3HKSlk=.5c1617ee-ce43-4eb6-83c0-0c86575fb402@github.com>

On Fri, 20 Oct 2023 12:00:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant checks

Marked as reviewed by jpai (Reviewer).

I just noticed that the test isn't marked `othervm` but changes the JVM level `ProxySelector` in its test execution. I think we should mark it `othervm` to avoid interfering (or being interefered) by other tests.

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

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692570325
PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1775214223

From djelinski at openjdk.org  Mon Oct 23 14:10:31 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Oct 2023 14:10:31 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <c_G21Aq3XujNcBh9CpdCKTdlx8oLcXjIWotVeZ7LWqk=.2b1527d9-4096-46b1-b85e-419726618135@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
 <c_G21Aq3XujNcBh9CpdCKTdlx8oLcXjIWotVeZ7LWqk=.2b1527d9-4096-46b1-b85e-419726618135@github.com>
Message-ID: <zmROlUed8-TEU6FTykhjPynz_zmw-s6gx1AOAik2BwY=.5b1dbe20-6c13-444a-a4b5-087470d4e742@github.com>

On Mon, 23 Oct 2023 12:24:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant checks
>
> src/java.base/share/classes/java/net/SocksSocketImpl.java line 307:
> 
>> 305:                 host = ParseUtil.encodePath(host);
>> 306:             }
>> 307:             // IPv6 literal?
> 
> Hello Daniel, this comment seems to have been misplaced. I think it should have been a few lines above just when `isIPv6LiteralAddress` is being called.

Good catch, this comment doesn't make much sense here. `isIPv6LiteralAddress` is descriptive enough, I'll just remove the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16265#discussion_r1368741693

From dfuchs at openjdk.org  Mon Oct 23 14:20:32 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 23 Oct 2023 14:20:32 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
Message-ID: <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>

On Thu, 19 Oct 2023 12:36:22 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   schedule completes normally on NO_ERROR, incoming_reset safely accesses volataile

Hi @c-cleary this mostly look good to me now. I do have one additional suggestion though. There is a corner case where we may have received END_STREAM but are still expecting some frames: that's the case of CONTINUATION frames: in that case the END_STREAM is carried by the HEADERS frame, and the END_HEADERS will be carried by a continuation frame that follows. If we receive a RESET at that point, we should also handle it immediately and relay an exception to the caller. I believe that could be easily handled by handling reset immediately also in the case where `finalResponseCodeReceived` is `false`. See suggestion below.

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 619:

> 617:             }
> 618:             if (!endStreamSeen) {
> 619:                 // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately

Suggestion:

            if (!endStreamSeen || !finalResponseCodeReceived) {
                // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately
                // If the final response code was not received, then we should also handle
                // the RST_STREAM immediately

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15664#pullrequestreview-1692682442
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1368747707

From djelinski at openjdk.org  Mon Oct 23 14:29:59 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Oct 2023 14:29:59 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v3]
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Run test in othervm
 - Remove leftover comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16265/files
  - new: https://git.openjdk.org/jdk/pull/16265/files/9e3cd23c..c7ec8eb9

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

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

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

From dfuchs at openjdk.org  Mon Oct 23 14:30:00 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 23 Oct 2023 14:30:00 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v3]
In-Reply-To: <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
Message-ID: <KsTia9ngjmX4lagmk-hQlj7mwVu2ta1kfwf5-FTRYZ0=.4c3293a5-97c0-4303-8275-40ce48dd9c52@github.com>

On Mon, 23 Oct 2023 14:26:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run test in othervm
>  - Remove leftover comment

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692709355

From jpai at openjdk.org  Mon Oct 23 14:30:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 14:30:01 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v3]
In-Reply-To: <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
Message-ID: <oIz8wQjchmNWmnZQTJopNYEGC-Icoc6Rb8rGoLaa6_E=.ac565238-402c-41dd-938e-b4411c513c35@github.com>

On Mon, 23 Oct 2023 14:26:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run test in othervm
>  - Remove leftover comment

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692715778

From djelinski at openjdk.org  Mon Oct 23 14:30:02 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Oct 2023 14:30:02 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v2]
In-Reply-To: <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <jt0TqKuI2xrzr8WCo2CN6DRHBe0ZSXwZjzjeEZCAB1s=.b4b1487d-db3f-469a-b4ef-da58335b5ed8@github.com>
Message-ID: <b-uKln1_Wh5y9xXGfCNOxZNBEa78z1bqCOLAH3LfUZQ=.fbee60d8-2027-447c-bff7-61f3f7186ce8@github.com>

On Fri, 20 Oct 2023 12:00:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant checks

Updated the test to run in othervm and removed the code to restore original ProxySelector.

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

PR Comment: https://git.openjdk.org/jdk/pull/16265#issuecomment-1775319873

From aefimov at openjdk.org  Mon Oct 23 14:40:39 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 23 Oct 2023 14:40:39 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v3]
In-Reply-To: <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
Message-ID: <r-jkOX--Q-Os5wcZ0ciWUxWZMYsRcwq2Qe9XxeyYjnc=.653d60f7-5dad-4877-83ab-21b2262da93c@github.com>

On Mon, 23 Oct 2023 14:29:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run test in othervm
>  - Remove leftover comment

The changes and the new test look good to me.

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

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692749800

From michaelm at openjdk.org  Mon Oct 23 14:49:39 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 23 Oct 2023 14:49:39 GMT
Subject: RFR: 8318130: SocksSocketImpl needlessly encodes hostname for IPv6
 addresses [v3]
In-Reply-To: <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
 <GjJdc1CRRQRc4x2OkNUyGoNCMZb2stN_68H48bQPhEU=.1412d555-1caa-42b5-ab8c-e40032af5b54@github.com>
Message-ID: <k28cyxnYVgmoAKB5FPQvSuKDeBeNsb34jObkpW-tVm0=.cb44da48-b35d-4f62-b5b7-b30ad511ebb9@github.com>

On Mon, 23 Oct 2023 14:29:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
>> 
>> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
>> 
>> The proposed code does not percent-encode the IPv6 addresses at all.
>> 
>> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
>> 
>> Tier1-3 tests passed.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run test in othervm
>  - Remove leftover comment

Marked as reviewed by michaelm (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16265#pullrequestreview-1692770851

From dfuchs at openjdk.org  Mon Oct 23 14:57:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 23 Oct 2023 14:57:42 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v3]
In-Reply-To: <xFCHxZfjQfSKnytCKMYEoDha_1d9VHo9nFlS-Y3rOlc=.fb9cd7c5-e4b6-462a-9f39-018811916fa9@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <xFCHxZfjQfSKnytCKMYEoDha_1d9VHo9nFlS-Y3rOlc=.fb9cd7c5-e4b6-462a-9f39-018811916fa9@github.com>
Message-ID: <aJj7seEn0YcGs13_AZGWbYNN7v2QtnBAq9XFCTmEpNg=.a5d82617-c87c-48de-9b0b-ce739b7a0636@github.com>

On Tue, 17 Oct 2023 15:58:19 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Inet6Address##input doc section for better sections separation

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1692795146

From aefimov at openjdk.org  Mon Oct 23 16:54:52 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 23 Oct 2023 16:54:52 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v4]
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <LYnDiQckm4tP2EzjMeOOnds7Rr_ta-M0YWl85XrY8s4=.ac9aa85c-b957-4c05-b79e-a7979fdefb7e@github.com>

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Aleksei Efimov 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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
 - add Inet6Address##input doc section for better sections separation
 - representations -> representation, add format section links, modify headings
 - improve the ambiguous term readability according to Daniel comments
 - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
 - Moving snippets to class-level docs per Michael suggestion, associated doc changes
 - Daniel suggestions
 - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
 - update javadoc of internal utility methods.
 - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/69ae3083...9523fbfc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15775/files
  - new: https://git.openjdk.org/jdk/pull/15775/files/6b3702ba..9523fbfc

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

  Stats: 24916 lines in 905 files changed: 15992 ins; 4652 del; 4272 mod
  Patch: https://git.openjdk.org/jdk/pull/15775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15775/head:pull/15775

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

From djelinski at openjdk.org  Tue Oct 24 05:39:46 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 24 Oct 2023 05:39:46 GMT
Subject: Integrated: 8318130: SocksSocketImpl needlessly encodes hostname for
 IPv6 addresses
In-Reply-To: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
References: <CDpjV7g2poUZrUy7CEFiGF2rdxpN4MMEDKsDU746bFc=.4a3f8d31-4b49-4a1d-a4a1-2aa56ea79fac@github.com>
Message-ID: <SQnaHRpYTbI8s8KhF6_iVQBBmTOehV0Wp11lvpM4crs=.27b0edf0-7f18-4e7a-ab19-5277067fdda8@github.com>

On Thu, 19 Oct 2023 12:10:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the encoding of IPv6 addresses in the URI provided to ProxySelector.
> 
> The original code percent-encoded the square brackets added around the IPv6 addresses, producing URIs that could not be parsed correctly.
> 
> The proposed code does not percent-encode the IPv6 addresses at all.
> 
> Added a test to verify that different forms of addresses are processed correctly. The test verifies the handling of IPv4 addresses, IPv6 without scope, IPv6 with numeric scope, IPv6 with textual scope (only if present on the machine running tests), hostnames and FQDNs
> 
> Tier1-3 tests passed.

This pull request has now been integrated.

Changeset: 728b858c
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/728b858c787567fa4eed6dd44730dfdb8b30be0f
Stats:     207 lines in 2 files changed: 199 ins; 4 del; 4 mod

8318130: SocksSocketImpl needlessly encodes hostname for IPv6 addresses

Reviewed-by: dfuchs, jpai, aefimov, michaelm

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

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

From ccleary at openjdk.org  Tue Oct 24 09:38:36 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 09:38:36 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v5]
In-Reply-To: <jAhg4x0H5eij-_bC4fxZCwosK5aPz_CZHmI0jETCOU4=.a519be36-0dc9-4427-8909-26fac4fee74f@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <YGcMC8bf-qqU6ej1eCdT7OlJ0BdhKhdjK_m84sqPPMI=.6e38cb1e-77fd-4c10-9466-47f898940980@github.com>
 <jAhg4x0H5eij-_bC4fxZCwosK5aPz_CZHmI0jETCOU4=.a519be36-0dc9-4427-8909-26fac4fee74f@github.com>
Message-ID: <X14ICqCxczsHmBhNxDCICHhvFe3WnNapOU-C3P0FxG8=.97524dc6-5056-4ad9-aa4a-ed9072158704@github.com>

On Wed, 18 Oct 2023 14:30:28 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Conor Cleary 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 12 additional commits since the last revision:
>> 
>>  - 8309118: Update Comment in schedule()
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8309118
>>  - 8309118: Remove irrelevant comments and logs
>>  - 8309118: Fixed error in handleReset ReentrantLock
>>  - 8309118: Updates to Stream cancelImpl
>>  - 8309118: Refactored test, updated incoming_reset
>>  - Merge branch 'master' into JDK-8309118
>>  - 8309118: Cleanup identifiers and whitespace
>>  - 8309118: Removed unused try-with-resources
>>  - 8309118: Improve comments and annotations
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86e9cb03...d74b08a0
>
> This PR has generated a lot of discussion offline. If I were to summarise it comes down to a couple of points. `pendingResponseSubscriber` can be null when `receiveDataFrame(new DataFrame(streamid, DataFrame.END_STREAM, List.of()));` is called because `readBodyAsync` has not yet been called (which triggers the setting of `pendingResponseSubsrciber`). There was a lot of confusion around this but because it is necessary to work around the constraints of the `Exchange` class, this seems alright. `readBodyAsync` won't happen until data is received from the server after the client has received response headers. If there were any **actions** to come from this it would be to improve comments around this to make this more clear.
> 
> The new `endStreamSeenFlag` is used very specifically in my changes in two cases of processing a RST_STREAM frame from the server. Firstly, in the event the `pendingResponseSubscriber` is null (as in the case described above) and an END_STREAM flag has not been received by the client (so `endStreamSeen` is `false`) `handleReset` is called then and there to complete the `requestBodyCf` exceptionally. Secondly, in the event of `requestBodyCF` not being done or we are still sending the request body, `handleReset` is called straight away here too. So in essence its being used as a short-circuit to complete the requestBodyCf exceptionally. I would like to seek feedback on this specifically if there is any.

> Hi @c-cleary this mostly look good to me now. I do have one additional suggestion though. There is a corner case where we may have received END_STREAM but are still expecting some frames: that's the case of CONTINUATION frames: in that case the END_STREAM is carried by the HEADERS frame, and the END_HEADERS will be carried by a continuation frame that follows. If we receive a RESET at that point, we should also handle it immediately and relay an exception to the caller. I believe that could be easily handled by handling reset immediately also in the case where `finalResponseCodeReceived` is `false`. See suggestion below.

Ah yes, I see this text now in RFC 9113 ([link here](https://www.rfc-editor.org/rfc/rfc9113.html#section-6.2)). Quote from RFC..

> A HEADERS frame with the END_STREAM flag set signals the end of a stream. However, a HEADERS frame with the END_STREAM flag set can be followed by CONTINUATION frames on the same stream. Logically, the CONTINUATION frames are part of the HEADERS frame.

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1776860554

From ccleary at openjdk.org  Tue Oct 24 09:38:39 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 09:38:39 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
 <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
Message-ID: <1jfM1rHyg2OwX4hOaBF5XeIoUYHG7jiJuM4aMUCtUu0=.653475b5-3890-4079-81e4-8f90b8df239c@github.com>

On Mon, 23 Oct 2023 14:11:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   schedule completes normally on NO_ERROR, incoming_reset safely accesses volataile
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 619:
> 
>> 617:             }
>> 618:             if (!endStreamSeen) {
>> 619:                 // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately
> 
> Suggestion:
> 
>             if (!endStreamSeen || !finalResponseCodeReceived) {
>                 // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately
>                 // If the final response code was not received, then we should also handle
>                 // the RST_STREAM immediately

So by checking if the final response code is received, this makes sure that the entire block of headers is processed therfore a status code will have been received.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1369875187

From ccleary at openjdk.org  Tue Oct 24 09:38:40 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 09:38:40 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <1jfM1rHyg2OwX4hOaBF5XeIoUYHG7jiJuM4aMUCtUu0=.653475b5-3890-4079-81e4-8f90b8df239c@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
 <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
 <1jfM1rHyg2OwX4hOaBF5XeIoUYHG7jiJuM4aMUCtUu0=.653475b5-3890-4079-81e4-8f90b8df239c@github.com>
Message-ID: <KZlllGXiVO11pJGiyPSj-z4f6CqWhVNaCFQJGC07aMo=.e0bce53f-0c68-487f-b8fd-2d409b34a7db@github.com>

On Tue, 24 Oct 2023 09:29:50 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 619:
>> 
>>> 617:             }
>>> 618:             if (!endStreamSeen) {
>>> 619:                 // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately
>> 
>> Suggestion:
>> 
>>             if (!endStreamSeen || !finalResponseCodeReceived) {
>>                 // If no END_STREAM flag seen, any RST_STREAM should be handled here immediately
>>                 // If the final response code was not received, then we should also handle
>>                 // the RST_STREAM immediately
>
> So by checking if the final response code is received, this makes sure that the entire block of headers is processed therfore a status code will have been received.

And then in the case where END_STREAM has already been seen, we call `requestBodyCF.complete(null);` to complete normally, as any RST_STREAM frames after an END_STREAM are not handled exceptionally.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1369876940

From ccleary at openjdk.org  Tue Oct 24 09:38:41 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 09:38:41 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <KZlllGXiVO11pJGiyPSj-z4f6CqWhVNaCFQJGC07aMo=.e0bce53f-0c68-487f-b8fd-2d409b34a7db@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
 <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
 <1jfM1rHyg2OwX4hOaBF5XeIoUYHG7jiJuM4aMUCtUu0=.653475b5-3890-4079-81e4-8f90b8df239c@github.com>
 <KZlllGXiVO11pJGiyPSj-z4f6CqWhVNaCFQJGC07aMo=.e0bce53f-0c68-487f-b8fd-2d409b34a7db@github.com>
Message-ID: <uXlso7AKTvEeOr4QACZ5eoq0RHisLh3BuCCfaRMoh-Y=.e82480bc-2d9e-454b-90ed-35b806d3f221@github.com>

On Tue, 24 Oct 2023 09:31:19 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> So by checking if the final response code is received, this makes sure that the entire block of headers is processed therfore a status code will have been received.
>
> And then in the case where END_STREAM has already been seen, we call `requestBodyCF.complete(null);` to complete normally, as any RST_STREAM frames after an END_STREAM are not handled exceptionally.

I'll give these changes a go and test them, will update here when I do

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1369878101

From ccleary at openjdk.org  Tue Oct 24 12:51:44 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 12:51:44 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
Message-ID: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>

If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 

Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

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

Commit messages:
 - 8318492: Http2ClientImpl should attempt to close and remove connection in stop()

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

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

From ccleary at openjdk.org  Tue Oct 24 13:46:46 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 13:46:46 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v6]
In-Reply-To: <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <byPuME_Dek214qDO2L5m2PSGo6bE9AB1r5Fuhr6qbzI=.eeb3a82c-4693-4839-bc7b-ce64f1c6cef3@github.com>
 <dq0Yf-nBBt1oxxwsAo8tzySUdAse6_KV0_d34M2rDWI=.a74b4708-1997-4b57-9e94-f76e3f0be373@github.com>
Message-ID: <Vc62Jpw0X7xOKIzl505xB4no6x-LGPG_f7k1pAEkELE=.ee09ce64-43b0-4c25-8ca3-197f9b1050ff@github.com>

On Mon, 23 Oct 2023 14:17:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   schedule completes normally on NO_ERROR, incoming_reset safely accesses volataile
>
> Hi @c-cleary this mostly look good to me now. I do have one additional suggestion though. There is a corner case where we may have received END_STREAM but are still expecting some frames: that's the case of CONTINUATION frames: in that case the END_STREAM is carried by the HEADERS frame, and the END_HEADERS will be carried by a continuation frame that follows. If we receive a RESET at that point, we should also handle it immediately and relay an exception to the caller. I believe that could be easily handled by handling reset immediately also in the case where `finalResponseCodeReceived` is `false`. See suggestion below.

Updated with your feedback @dfuch 

Seems stable and makes sense ?

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1777236288

From ccleary at openjdk.org  Tue Oct 24 13:46:43 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 24 Oct 2023 13:46:43 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v7]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

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

  8309118: Add final response code check to incompleteRequestBodyReset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/6bf25d12..795b3461

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

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

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

From dfuchs at openjdk.org  Tue Oct 24 16:28:38 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 24 Oct 2023 16:28:38 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <zOQcaXaxTlADdt6sCgbNoFH5hDjEopBjGWDrmtO5HMs=.62a4aa18-5fbb-44c2-9a01-de05a6493923@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
> 
> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16340#pullrequestreview-1695364579

From dfuchs at openjdk.org  Tue Oct 24 16:30:38 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 24 Oct 2023 16:30:38 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v7]
In-Reply-To: <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
Message-ID: <whkmimyi9JRGhjFIOPwNofUsiCmCyquZGiAg6U6z4m8=.898f2573-c440-46c0-916f-ac8cce216f0f@github.com>

On Tue, 24 Oct 2023 13:46:43 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: Add final response code check to incompleteRequestBodyReset

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15664#pullrequestreview-1695368312

From djelinski at openjdk.org  Wed Oct 25 08:43:58 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Oct 2023 08:43:58 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java fails
 on machines with no IPv6 link-local addresses
Message-ID: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>

The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.

I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

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

Commit messages:
 - Skip test if no link-local addresses found

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

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

From djelinski at openjdk.org  Wed Oct 25 08:47:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Oct 2023 08:47:40 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v7]
In-Reply-To: <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
Message-ID: <hu1dVrqqmWRjLC5qkR0asozmSPLgIjrIEeCrP97RPN8=.441634ef-87ab-470b-99b8-2d03111ef646@github.com>

On Tue, 24 Oct 2023 13:46:43 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: Add final response code check to incompleteRequestBodyReset

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 215:

> 213:                     Log.logTrace("responseSubscriber.onComplete");
> 214:                     if (debug.on()) debug.log("incoming: onComplete");
> 215:                     if (inputQ.isEmpty()) sched.stop();

I think you should remove all references to sched.stop() from this method; while adding `if (inputQ.isEmpty())` reduces the risk of races, there's still a small window where an incoming reset frame can be lost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1371381881

From jpai at openjdk.org  Wed Oct 25 08:58:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 08:58:37 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <bh4hF2G39-DzL0uq6NuB7OZRvmbD4K7AkI6mV9YzngQ=.3c45871c-37d7-41a0-aa9a-0b7823c4ddb2@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

Hello Daniel, the change looks OK to me. Is it intentional that you want to test only one of the IP addresses (if available) from the stream instead of using a loop to test all of them (when available)?

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

PR Comment: https://git.openjdk.org/jdk/pull/16356#issuecomment-1778815352

From jpai at openjdk.org  Wed Oct 25 09:29:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:29:25 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <Q2ACAdAzsQvDrxn0v8qahoduxvqR97DSpGau8WfU2ic=.adc19c37-43be-41fb-a6d9-4713dba7b452@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16356#pullrequestreview-1696813511

From jpai at openjdk.org  Wed Oct 25 09:29:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:29:28 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <c2ZTKL2w8AszFEPzMjRVM6t5XdmVVyX5nBTarmlnyQw=.0a33b03c-01c2-4dc1-b858-21c7d1d957f0@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
> 
> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 231:

> 229:         }
> 230:         do {
> 231:             connections.values().removeIf(this::close);

Hello Conor, I'm just wondering if doing this will have some unexpected race or some such similar issue in the `connections` management.

Right now, before this change, to remove a connection from a pool we call the `Http2ClientImpl.removeFromPool(conn)` which then obtains a `connectionPoolLock` lock before removing it from the pool. In this proposed change, we are bypassing the `connectionPoolLock` lock. The `connections` itself is a `ConcurrentHashMap` but its usages are currently guarded through the `connectionPoolLock`, so I wonder if we should be calling `removeFromPool` method here instead of `removeIf`, something like:


        do {
            connections.values().forEach((c) -> {
                if (close(c)) {
                    removeFromPool(c);
                }
            });
        } while (!connections.isEmpty());

I haven't done any kind of testing on this use of `removeFromPool` - it could be that it might have issues of its own.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16340#discussion_r1371437292

From djelinski at openjdk.org  Wed Oct 25 09:29:26 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Oct 2023 09:29:26 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <xrFSlzx7m7jaKMDwPIW3U-DvFwQsJeKeQP1UDmXpaQI=.a7f5d17f-1c31-485b-b73b-1bd2df72182f@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

Hi Jaikiran, thanks for checking! Testing a single address should be sufficient to verify the functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/16356#issuecomment-1778864379

From dfuchs at openjdk.org  Wed Oct 25 09:37:39 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Oct 2023 09:37:39 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <pttUQsOTQAoRsZ61pbJ3zS5brSHp9LBi1ChYJaMdxQE=.6c8b90f1-9b6d-42e9-a6ff-8cd331d60b6b@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16356#pullrequestreview-1696828201

From jpai at openjdk.org  Wed Oct 25 09:39:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:39:37 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <W6whPJNoEk5tUpqo90ln6H8T2DlL9v1PQUqKxpj5oB0=.6aa48704-e49e-45a1-8750-8441f256f3b3@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> removes the Http2Connection from the connection pool to prevent inactive connections from remaining in there rather than just closing it.

I believe you are already aware, but just to avoid any confusion, the pool of connections represented by the `connections` field in `Http2ClientImpl` is pool of active connections.

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

PR Comment: https://git.openjdk.org/jdk/pull/16340#issuecomment-1778883976

From dfuchs at openjdk.org  Wed Oct 25 09:54:40 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Oct 2023 09:54:40 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v7]
In-Reply-To: <hu1dVrqqmWRjLC5qkR0asozmSPLgIjrIEeCrP97RPN8=.441634ef-87ab-470b-99b8-2d03111ef646@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
 <hu1dVrqqmWRjLC5qkR0asozmSPLgIjrIEeCrP97RPN8=.441634ef-87ab-470b-99b8-2d03111ef646@github.com>
Message-ID: <oNBw1QJ0fJb3_5f0ogbUdZbg2iH_deYUg7u6eS0UPiU=.1ea70971-9603-49c0-ae6e-4fd283dbb768@github.com>

On Wed, 25 Oct 2023 08:44:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8309118: Add final response code check to incompleteRequestBodyReset
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 215:
> 
>> 213:                     Log.logTrace("responseSubscriber.onComplete");
>> 214:                     if (debug.on()) debug.log("incoming: onComplete");
>> 215:                     if (inputQ.isEmpty()) sched.stop();
> 
> I think you should remove all references to sched.stop() from this method; while adding `if (inputQ.isEmpty())` reduces the risk of races, there's still a small window where an incoming reset frame can be lost.

The only thing we could do with the reset after this point in the schedule() method, if the reset had not yet been inserted into the inputQueue, is to complete the `requestBodyCF` and this would have already been taken care of at line 595 in incoming_reset. So I don't believe the scheduler would need to run again after this line (or the other like it)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1371469922

From dfuchs at openjdk.org  Wed Oct 25 10:21:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Oct 2023 10:21:36 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <c2ZTKL2w8AszFEPzMjRVM6t5XdmVVyX5nBTarmlnyQw=.0a33b03c-01c2-4dc1-b858-21c7d1d957f0@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
 <c2ZTKL2w8AszFEPzMjRVM6t5XdmVVyX5nBTarmlnyQw=.0a33b03c-01c2-4dc1-b858-21c7d1d957f0@github.com>
Message-ID: <PjwqdMwxKIATWW2A4l977X1KJwOk-55pigfa9LNib8k=.a30fc9f6-2cab-43a6-99ec-242e65a0ae8f@github.com>

On Wed, 25 Oct 2023 09:26:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
>> 
>> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 231:
> 
>> 229:         }
>> 230:         do {
>> 231:             connections.values().removeIf(this::close);
> 
> Hello Conor, I'm just wondering if doing this will have some unexpected race or some such similar issue in the `connections` management.
> 
> Right now, before this change, to remove a connection from a pool we call the `Http2ClientImpl.removeFromPool(conn)` which then obtains a `connectionPoolLock` lock before removing it from the pool. In this proposed change, we are bypassing the `connectionPoolLock` lock. The `connections` itself is a `ConcurrentHashMap` but its usages are currently guarded through the `connectionPoolLock`, so I wonder if we should be calling `removeFromPool` method here instead of `removeIf`, something like:
> 
> 
>         do {
>             connections.values().forEach((c) -> {
>                 if (close(c)) {
>                     removeFromPool(c);
>                 }
>             });
>         } while (!connections.isEmpty());
> 
> I haven't done any kind of testing on this use of `removeFromPool` - it could be that it might have issues of its own.

@jaikiran we are stopping the client at that point. The main reason for the connectionPoolLock is to avoid adding connections to the pool or handing off connections from the pool if `stopping` has been set to true. `removeFromPool` does nothing more than logging and removing the connection from the pool. Locking is necessary here because we don't want a connection to be handed off if it's going to be removed, but that logic is not necessary at client stop. Of course this only works because our connections map is a ConcurrentHashMap, but so is removing from within a loop. So I believe using removeIf here is appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16340#discussion_r1371501650

From dfuchs at openjdk.org  Wed Oct 25 10:30:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Oct 2023 10:30:26 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <W6whPJNoEk5tUpqo90ln6H8T2DlL9v1PQUqKxpj5oB0=.6aa48704-e49e-45a1-8750-8441f256f3b3@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
 <W6whPJNoEk5tUpqo90ln6H8T2DlL9v1PQUqKxpj5oB0=.6aa48704-e49e-45a1-8750-8441f256f3b3@github.com>
Message-ID: <zCaG1Txg7pr0qTZvknVPgaaaCGfNX0baLQsUucUK2wE=.c773c58c-b7ef-47b0-aa27-e4218f06e15c@github.com>

On Wed, 25 Oct 2023 09:37:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I believe you are already aware, but just to avoid any confusion, the pool of connections represented by the connections field in Http2ClientImpl is pool of active connections.

Yes - but the connections we're removing have been closed, so they are inactive, which is kind of the point.

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

PR Comment: https://git.openjdk.org/jdk/pull/16340#issuecomment-1778964381

From jpai at openjdk.org  Wed Oct 25 12:08:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 12:08:28 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <5uWkh480w187MxDt4p2kyxOVNjTvZFXys4AbPf9QuwE=.19e80dab-6674-4a2b-abd1-6d5c3f20174c@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
> 
> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16340#pullrequestreview-1697129938

From jpai at openjdk.org  Wed Oct 25 12:08:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 12:08:32 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <PjwqdMwxKIATWW2A4l977X1KJwOk-55pigfa9LNib8k=.a30fc9f6-2cab-43a6-99ec-242e65a0ae8f@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
 <c2ZTKL2w8AszFEPzMjRVM6t5XdmVVyX5nBTarmlnyQw=.0a33b03c-01c2-4dc1-b858-21c7d1d957f0@github.com>
 <PjwqdMwxKIATWW2A4l977X1KJwOk-55pigfa9LNib8k=.a30fc9f6-2cab-43a6-99ec-242e65a0ae8f@github.com>
Message-ID: <Vl-4rQxEMGtoUmot1pAkzGdqY_EiTCsSbgZT4np42ls=.0e772484-fe97-407d-888a-66d667eae261@github.com>

On Wed, 25 Oct 2023 10:18:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 231:
>> 
>>> 229:         }
>>> 230:         do {
>>> 231:             connections.values().removeIf(this::close);
>> 
>> Hello Conor, I'm just wondering if doing this will have some unexpected race or some such similar issue in the `connections` management.
>> 
>> Right now, before this change, to remove a connection from a pool we call the `Http2ClientImpl.removeFromPool(conn)` which then obtains a `connectionPoolLock` lock before removing it from the pool. In this proposed change, we are bypassing the `connectionPoolLock` lock. The `connections` itself is a `ConcurrentHashMap` but its usages are currently guarded through the `connectionPoolLock`, so I wonder if we should be calling `removeFromPool` method here instead of `removeIf`, something like:
>> 
>> 
>>         do {
>>             connections.values().forEach((c) -> {
>>                 if (close(c)) {
>>                     removeFromPool(c);
>>                 }
>>             });
>>         } while (!connections.isEmpty());
>> 
>> I haven't done any kind of testing on this use of `removeFromPool` - it could be that it might have issues of its own.
>
> @jaikiran we are stopping the client at that point. The main reason for the connectionPoolLock is to avoid adding connections to the pool or handing off connections from the pool if `stopping` has been set to true. `removeFromPool` does nothing more than logging and removing the connection from the pool. Locking is necessary here because we don't want a connection to be handed off if it's going to be removed, but that logic is not necessary at client stop. Of course this only works because our connections map is a ConcurrentHashMap, but so is removing from within a loop. So I believe using removeIf here is appropriate.

Thank you for that additional detail Daniel.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16340#discussion_r1371634222

From michaelm at openjdk.org  Wed Oct 25 15:20:37 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 25 Oct 2023 15:20:37 GMT
Subject: RFR: 8272215: Add InetAddress methods for parsing IP address
 literals [v4]
In-Reply-To: <LYnDiQckm4tP2EzjMeOOnds7Rr_ta-M0YWl85XrY8s4=.ac9aa85c-b957-4c05-b79e-a7979fdefb7e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
 <LYnDiQckm4tP2EzjMeOOnds7Rr_ta-M0YWl85XrY8s4=.ac9aa85c-b957-4c05-b79e-a7979fdefb7e@github.com>
Message-ID: <PsvsN4ZBGspPNVQfi3rwJLtrhV1rEuA5PQomzqWuvuk=.5a51133a-a3a1-4fb4-9ae5-711d606e97b1@github.com>

On Mon, 23 Oct 2023 16:54:52 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary 
>> 
>> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>>  `java.net.Inet6Address` classes to parse IP address literals:
>>  ```
>> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
>> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> ``` 
>> 
>> ### How new methods differ from existing ones
>> 
>> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
>> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
>> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
>> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
>> 
>> ### The list of noteworthy changes
>> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
>> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
>> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
>> 
>> ### Testing 
>> 
>> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
>> 
>> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
>> 
>> Added Methods
>> -------------
>> 
>> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
>> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
>> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan...
>
> Aleksei Efimov 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
>  - add Inet6Address##input doc section for better sections separation
>  - representations -> representation, add format section links, modify headings
>  - improve the ambiguous term readability according to Daniel comments
>  - test update: run IPv6-scoped address with wrong scope-id test case only with at least 2 NI
>  - Moving snippets to class-level docs per Michael suggestion, associated doc changes
>  - Daniel suggestions
>  - Merge branch 'master' into JDK-8272215_API_parse_IP_literals
>  - update javadoc of internal utility methods.
>  - updates for Inet6Address.ofLiteral return type, javadoc and the regression test
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/fac5e330...9523fbfc

LGTM

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15775#pullrequestreview-1697654910

From mbaesken at openjdk.org  Thu Oct 26 07:31:31 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 26 Oct 2023 07:31:31 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <P-vP5D4upzv3BwV3AKhce6U5LpbfoFxDyZVg9ZTOgbU=.09f5bf66-e7f0-458d-8927-3bfa81cc159b@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

Fixed our issues on AIX that were observed one day ago in the test  java/net/Socks/SocksSocketProxySelectorTest.java .

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16356#pullrequestreview-1698906056

From djelinski at openjdk.org  Thu Oct 26 08:52:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 08:52:42 GMT
Subject: RFR: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <c05Da1YjNQakit8b0BKOZwB6zv0IKwxaucx_tc9ki7A=.55b84abf-4725-4975-8d6c-c4501a284b48@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

Thanks for checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/16356#issuecomment-1780681877

From djelinski at openjdk.org  Thu Oct 26 08:52:43 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 08:52:43 GMT
Subject: Integrated: 8318788: java/net/Socks/SocksSocketProxySelectorTest.java
 fails on machines with no IPv6 link-local addresses
In-Reply-To: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
References: <QV99YOg1Y_iskpr2jttFfIQBP7U6kHil-O5mkH1zdDs=.eb199676-118b-4042-920b-63ab88f1d9ae@github.com>
Message-ID: <WNbJstb0-Uw_K_CSXOZIww1f3ZsknEvGnQIyTo41RSo=.26f6e1db-6346-4093-ba43-0c2bc99d4274@github.com>

On Wed, 25 Oct 2023 08:31:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The test was failing on machines with no link-local addresses configured; JUnit's ParameterizedTest fails if the parameter source returns no parameters, and `linkLocalIpv6Literals` was used as a parameter source.
> 
> I changed the test to non-parameterized; the test now uses the first address from `linkLocalIpv6Literals`, and is aborted if the method returns no addresses.

This pull request has now been integrated.

Changeset: 970cd202
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/970cd202049f592946f9c1004ea92dbd58abf6fb
Stats:     10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8318788: java/net/Socks/SocksSocketProxySelectorTest.java fails on machines with no IPv6 link-local addresses

Reviewed-by: jpai, dfuchs, mbaesken

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

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

From ccleary at openjdk.org  Thu Oct 26 12:00:52 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 26 Oct 2023 12:00:52 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v8]
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

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

  8309118: New comments, remove stop() from schedule()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15664/files
  - new: https://git.openjdk.org/jdk/pull/15664/files/795b3461..37685cce

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

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

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

From dfuchs at openjdk.org  Thu Oct 26 12:40:34 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Oct 2023 12:40:34 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v8]
In-Reply-To: <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
Message-ID: <HHABAfO6gKHi1ETMuiFyy2D16IQYeVZMsBJx0Gk6CAE=.b3db2eb3-18e0-4279-a574-330e44518ca2@github.com>

On Thu, 26 Oct 2023 12:00:52 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: New comments, remove stop() from schedule()

>  remove stop() from schedule()](https://github.com/openjdk/jdk/pull/15664/commits/37685ccef9b94be224acf6d94b75e8a694cfd61d)

With this change the scheduler may never get stopped. As long as we are sure that there won't be any subsequent call to schedule() (idle wake-ups), and that any non-idle wake-up would cause it to stop, it may be OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1781038968

From djelinski at openjdk.org  Thu Oct 26 13:19:36 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 13:19:36 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v8]
In-Reply-To: <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
Message-ID: <9hbnJnxxENbIrU4xOoBKjvFIMqiem91sH3r36rRY3YE=.f8ff3188-33ca-4b79-94cd-efbc0cac4d24@github.com>

On Thu, 26 Oct 2023 12:00:52 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: New comments, remove stop() from schedule()

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15664#pullrequestreview-1699612414

From ccleary at openjdk.org  Thu Oct 26 14:01:37 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 26 Oct 2023 14:01:37 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v7]
In-Reply-To: <oNBw1QJ0fJb3_5f0ogbUdZbg2iH_deYUg7u6eS0UPiU=.1ea70971-9603-49c0-ae6e-4fd283dbb768@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <-sLlDW7dmaNWTkJZBH_QSTV1F90DuumRvAib6CkGHeM=.95c6c68a-45f1-4c9b-9715-7049e17fa6c6@github.com>
 <hu1dVrqqmWRjLC5qkR0asozmSPLgIjrIEeCrP97RPN8=.441634ef-87ab-470b-99b8-2d03111ef646@github.com>
 <oNBw1QJ0fJb3_5f0ogbUdZbg2iH_deYUg7u6eS0UPiU=.1ea70971-9603-49c0-ae6e-4fd283dbb768@github.com>
Message-ID: <fyD4Jt7slgrCktJAUTE21E2cKaliyBO_M7Dn7phnRro=.e869a7b7-f64f-4b5a-bc21-d1e3767ad775@github.com>

On Wed, 25 Oct 2023 09:52:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 215:
>> 
>>> 213:                     Log.logTrace("responseSubscriber.onComplete");
>>> 214:                     if (debug.on()) debug.log("incoming: onComplete");
>>> 215:                     if (inputQ.isEmpty()) sched.stop();
>> 
>> I think you should remove all references to sched.stop() from this method; while adding `if (inputQ.isEmpty())` reduces the risk of races, there's still a small window where an incoming reset frame can be lost.
>
> The only thing we could do with the reset after this point in the schedule() method, if the reset had not yet been inserted into the inputQueue, is to complete the `requestBodyCF` and this would have already been taken care of at line 595 in incoming_reset. So I don't believe the scheduler would need to run again after this line (or the other like it)

I think maybe its better to let the scheduler complete without these checks. I think the effect of `stop()` is that it makes all subsequent calls to `runOrSchedule()` no-ops. I think it might be best to remove the call to stop() and allow scheduler to complete the requestBodyCf in a similar manner to how its done in `incoming_reset()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1373230487

From aefimov at openjdk.org  Thu Oct 26 18:27:48 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 26 Oct 2023 18:27:48 GMT
Subject: Integrated: 8272215: Add InetAddress methods for parsing IP address
 literals
In-Reply-To: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
References: <-YUa82ajVJwcpeTiOUz4gYaWQBKsyArXLZxSjgqyEno=.3ec50176-1370-4050-9115-10e3d735c74e@github.com>
Message-ID: <esLRc_eEu67PnmRCreHDBQ95uptsELfXVQlWOCga4J4=.189518a8-8dd4-4275-bee6-f221ee058baf@github.com>

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary 
> 
> The changes in this PR add new API to `java.net.InetAddress`, `java.net.Inet4Address`, and
>  `java.net.Inet6Address` classes to parse IP address literals:
>  ```
> method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)
> method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> ``` 
> 
> ### How new methods differ from existing ones
> 
> These methods differ from `InetAddress.getByName` and `InetAddress.getAllByName` in the following ways:
> 1. If a string supplied is not an address literal it is not forwarded to the system-wide resolver, but IllegalArgumentException is thrown instead. The system-wide resolver is never called from these new methods.
> 2. No reverse lookup is performed to resolve a hostname for the supplied address literal - the `InetAddress[46 ]` instances returned by the new `ofLiteral` API has no hostname set.
> 3. Each `ofLiteral` static method returns addresses of its class only. It gives the ability to check if an IP address literal is of a specific address type. 
> 
> ### The list of noteworthy changes
> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require some special handling in the new API to implement all supported IP address types.  
> - All address literal parsing code has been moved from `InetAddress.getAllByName` to address type-specific `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` methods.
> - The text with scoped IPv6 addresses architecture draft IETF file has been replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added as `@ spec` into Inet6Address class-level Javadoc.
> 
> ### Testing 
> 
> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the changes.
> 
> `java/net` JCK tests are failing with new methods added failure (CSR is planned for this change):
> 
> Added Methods
> -------------
> 
> java.net.Inet4Address:                  method public static java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String)
> java.net.Inet6Address:                  method public static java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

This pull request has now been integrated.

Changeset: 77fe0fd9
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77fe0fd9e6f1e1f775a5191640411c37eb51b415
Stats:     663 lines in 6 files changed: 581 ins; 57 del; 25 mod

8272215: Add InetAddress methods for parsing IP address literals

Reviewed-by: dfuchs, michaelm

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

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

From djelinski at openjdk.org  Fri Oct 27 16:54:50 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Oct 2023 16:54:50 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
Message-ID: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>

This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.

Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.

No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

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

Commit messages:
 - Check if connection is still idle before closing
 - Do not handle incoming requests on connections are being closing

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

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

From jpai at openjdk.org  Mon Oct 30 06:15:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Oct 2023 06:15:34 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <L1S9VB8eAIgPu9yfngoifGorLGz4kzFeKJELwTHDjyc=.3f15bf49-a6f3-4f4d-baf8-312535188b95@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

Thank you Daniel for addressing this. This looks OK to me, I just have one related question which I've added inline. Finally, given this relates to intermittent/racy issue, it would be good to verify that this change continues to work with a test-repeat of maybe 50.

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

PR Comment: https://git.openjdk.org/jdk/pull/16366#issuecomment-1784543527

From jpai at openjdk.org  Mon Oct 30 06:19:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Oct 2023 06:19:36 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <u7mpRyqVgsp7OLmFt6yhyV51TrKuNve2tBLZcrNNv8g=.0b3ae82d-25f1-412a-a8b3-779981feaa1e@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 531:

> 529:                                         // has now started on this connection.
> 530:                                         requestStarted(conn);
> 531:                                         handle (chan, conn);

In its current proposed form, if the connection wasn't in the newlyAcceptedConnections or idleConnections set, we don't seem to do anything (and expect the connection to be closed in a concurrent thread). Perhaps we should move this if block a few lines above and only cancel the key and put the channel in blocking mode, if this `if` condition satisfies?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16366#discussion_r1375714901

From djelinski at openjdk.org  Mon Oct 30 09:06:34 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Oct 2023 09:06:34 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <u7mpRyqVgsp7OLmFt6yhyV51TrKuNve2tBLZcrNNv8g=.0b3ae82d-25f1-412a-a8b3-779981feaa1e@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
 <u7mpRyqVgsp7OLmFt6yhyV51TrKuNve2tBLZcrNNv8g=.0b3ae82d-25f1-412a-a8b3-779981feaa1e@github.com>
Message-ID: <hYvRwuGmajuqYlwK20d47HZY-mTTtY0yKq2261GN5W8=.8838d5f3-ab66-4bee-8e76-2d91137d5555@github.com>

On Mon, 30 Oct 2023 06:17:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
>> 
>> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
>> 
>> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 531:
> 
>> 529:                                         // has now started on this connection.
>> 530:                                         requestStarted(conn);
>> 531:                                         handle (chan, conn);
> 
> In its current proposed form, if the connection wasn't in the newlyAcceptedConnections or idleConnections set, we don't seem to do anything (and expect the connection to be closed in a concurrent thread). Perhaps we should move this if block a few lines above and only cancel the key and put the channel in blocking mode, if this `if` condition satisfies?

It's complicated, and perhaps deserves a separate fix.
If the connection is plain HTTP, it doesn't matter; we close the connection, and this succeeds regardless if the connection is blocking or not.
If the connection is HTTPS, we send an alert to the peer using this code:
https://github.com/openjdk/jdk/blob/3934127b087ade1c1286008df3497ca6d84778a5/src/jdk.httpserver/share/classes/sun/net/httpserver/SSLStreams.java#L294-L296
And here again the blocking vs. non-blocking mode doesn't matter: if there's room in the send buffer, the send will succeed immediately, and if there's no room, it will block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16366#discussion_r1375881139

From jpai at openjdk.org  Tue Oct 31 06:01:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 31 Oct 2023 06:01:30 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <FnAu3GllTmgT8I5-UAbuNudS9wKcCYptAGRjaUSHC0Y=.f205b0ff-5630-48dc-b645-8fd95bba4db8@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16366#pullrequestreview-1705498897

From jpai at openjdk.org  Tue Oct 31 06:01:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 31 Oct 2023 06:01:32 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <hYvRwuGmajuqYlwK20d47HZY-mTTtY0yKq2261GN5W8=.8838d5f3-ab66-4bee-8e76-2d91137d5555@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
 <u7mpRyqVgsp7OLmFt6yhyV51TrKuNve2tBLZcrNNv8g=.0b3ae82d-25f1-412a-a8b3-779981feaa1e@github.com>
 <hYvRwuGmajuqYlwK20d47HZY-mTTtY0yKq2261GN5W8=.8838d5f3-ab66-4bee-8e76-2d91137d5555@github.com>
Message-ID: <GVCeH5KFuqIZwjU5tWHhl3aTTNTuEOUG_ugQUMwkkuI=.44805267-7c5c-4cb5-9295-1709733dbe30@github.com>

On Mon, 30 Oct 2023 09:04:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 531:
>> 
>>> 529:                                         // has now started on this connection.
>>> 530:                                         requestStarted(conn);
>>> 531:                                         handle (chan, conn);
>> 
>> In its current proposed form, if the connection wasn't in the newlyAcceptedConnections or idleConnections set, we don't seem to do anything (and expect the connection to be closed in a concurrent thread). Perhaps we should move this if block a few lines above and only cancel the key and put the channel in blocking mode, if this `if` condition satisfies?
>
> It's complicated, and perhaps deserves a separate fix.
> If the connection is plain HTTP, it doesn't matter; we close the connection, and this succeeds regardless if the connection is blocking or not.
> If the connection is HTTPS, we send an alert to the peer using this code:
> https://github.com/openjdk/jdk/blob/3934127b087ade1c1286008df3497ca6d84778a5/src/jdk.httpserver/share/classes/sun/net/httpserver/SSLStreams.java#L294-L296
> And here again the blocking vs. non-blocking mode doesn't matter: if there's room in the send buffer, the send will succeed immediately, and if there's no room, it will block.

Hello Daniel,

> It's complicated, and perhaps deserves a separate fix.

That's OK with me. The current state of this PR then looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16366#discussion_r1377088659

From ccleary at openjdk.org  Tue Oct 31 08:51:41 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 31 Oct 2023 08:51:41 GMT
Subject: RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2 [v8]
In-Reply-To: <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
 <UDxOCVeUsoJ0b7ztdsVZMQPMCbILyr6hGQEzvtdcJG4=.1279f340-7f58-4281-be11-62f62d5392ed@github.com>
Message-ID: <fkCS2jMhP7N9VIHFThDW2zrgOWPemPPMywN0hife0rU=.35d27691-9f3f-47c4-b635-fdbc9033932d@github.com>

On Thu, 26 Oct 2023 12:00:52 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### **Issue Description**
>> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
>> 
>> ### **Solution Details**
>> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
>> 
>> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
>> 
>> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
>> 
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309118: New comments, remove stop() from schedule()

Thanks for the reviews! If there is no additional feedback, I will integrate these changes today.

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

PR Comment: https://git.openjdk.org/jdk/pull/15664#issuecomment-1786764512

From ccleary at openjdk.org  Tue Oct 31 08:51:32 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 31 Oct 2023 08:51:32 GMT
Subject: RFR: 8318492: Http2ClientImpl should attempt to close and remove
 connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <UaCliTTZMgLYVjCxXGuL-4Uebt7bX3Yo7qlenJSa6JE=.c7701894-cdef-4e9e-8c6a-92a16893540d@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
> 
> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

Thanks for the reviews! I will integrate this change shortly

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

PR Comment: https://git.openjdk.org/jdk/pull/16340#issuecomment-1786763687

From michaelm at openjdk.org  Tue Oct 31 09:31:35 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 31 Oct 2023 09:31:35 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <qu9ntQbBricHW6vQFBZlL8QQc8-ivLhBfzzI7xzYutM=.0312bdb5-efee-42b6-84bd-8be1b3fbd5b6@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 1032:

> 1030:             ArrayList<HttpConnection> toClose = new ArrayList<>();
> 1031: 
> 1032:             connections.forEach(c -> {

Shouldn't we still be synchronizing on `connections` as per the advice in `Collections::synchronizedSet` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16366#discussion_r1377288530

From djelinski at openjdk.org  Tue Oct 31 09:55:34 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 31 Oct 2023 09:55:34 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <qu9ntQbBricHW6vQFBZlL8QQc8-ivLhBfzzI7xzYutM=.0312bdb5-efee-42b6-84bd-8be1b3fbd5b6@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
 <qu9ntQbBricHW6vQFBZlL8QQc8-ivLhBfzzI7xzYutM=.0312bdb5-efee-42b6-84bd-8be1b3fbd5b6@github.com>
Message-ID: <WcvSgI_chlMVu9s6w1p-pEGm30Xa7bdfbb2ddtt8AHk=.fd8a25ea-5680-48a2-aec2-a667d6264b76@github.com>

On Tue, 31 Oct 2023 09:28:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
>> 
>> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
>> 
>> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 1032:
> 
>> 1030:             ArrayList<HttpConnection> toClose = new ArrayList<>();
>> 1031: 
>> 1032:             connections.forEach(c -> {
> 
> Shouldn't we still be synchronizing on `connections` as per the advice in `Collections::synchronizedSet` ?

It's only necessary for iterator and stream; forEach (the non-stream version) is internally synchronized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16366#discussion_r1377324101

From ccleary at openjdk.org  Tue Oct 31 10:01:48 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 31 Oct 2023 10:01:48 GMT
Subject: Integrated: 8318492: Http2ClientImpl should attempt to close and
 remove connection in stop()
In-Reply-To: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
References: <hOPW9J10zF8RV2pTZ7SYnsmXbwT5iSgKLgKmuZ9VtWk=.3fab0129-5ce9-42e0-bb13-2f4357fcff22@github.com>
Message-ID: <1sRgWLHJyYfIF6WzN-V658cJQ0OITqxMsHVqmiELcMo=.57c6fb9e-9bac-434a-8fe3-b93e6c9c25d0@github.com>

On Tue, 24 Oct 2023 09:46:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> If Http2ClientImpl::stop() is called, it will loop through the connections map and call the close() method on each connection. The changes in this PR make sure that the connection thread (where close is called from) removes the `Http2Connection` from the connection pool to prevent inactive connections from remaining in there rather than just closing it. 
> 
> Even though the connection can be and usually is removed from the pool in other places (reader or writer thread), this change ensures removal from the pool in cases where the connection is shutdown by an exception, reset, etc. The issue was first spotted when a RST_STREAM triggered repeated attempts to remove idle connections from the pool before a regular shutdown could occur.

This pull request has now been integrated.

Changeset: 576c9bcc
Author:    Conor Cleary <ccleary at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/576c9bccfbe6718fe8fe409bc165000bd1554589
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8318492: Http2ClientImpl should attempt to close and remove connection in stop()

Reviewed-by: dfuchs, jpai

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

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

From michaelm at openjdk.org  Tue Oct 31 14:16:37 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 31 Oct 2023 14:16:37 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <tZVD5IWWbGL1uog7B5wkS1tGRYb10iS0o_FVUjNOTfg=.903e1594-bf16-40c9-905c-0e0a020b4fb4@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

Looks fine

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16366#pullrequestreview-1706421881

From dfuchs at openjdk.org  Tue Oct 31 14:29:31 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 31 Oct 2023 14:29:31 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <IzrVPmr8GkSUWfedmXtk2rxbm8urO9jfwdiNW1Itjjw=.86a97858-8a2d-4d82-8b83-2b53d78f13fc@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16366#pullrequestreview-1706454275

From ccleary at openjdk.org  Tue Oct 31 14:49:53 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 31 Oct 2023 14:49:53 GMT
Subject: Integrated: 8309118: HttpClient: Add more tests for 100 ExpectContinue
 with HTTP/2
In-Reply-To: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
References: <x_gPnoqGtb-njWxALK_EIkcvkTmdZ4L1I-ea9DJiLmU=.b350e99d-230a-4713-b832-cfcaa2c3e5c4@github.com>
Message-ID: <hqiLcUYyO6oFA801R2lD5NVmpafqdf8vfNv015x1peI=.523bad62-0f6e-4339-8715-7b06f090216d@github.com>

On Mon, 11 Sep 2023 15:09:22 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> ### **Issue Description**
> There is missing test coverage for the implementation of partial/informational responses (status code 1xx in server response headers) for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 - HTTP/2, details the behavior of any client in these situations. Small changes and new test cases are needed to verify compliance with this specification.  This issue primarily concerns how the client reacts to receiving a `RST_STREAM` frame at various stages of a partial/informational response from a server.
> 
> ### **Solution Details**
> Changes were made in `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to improve the handling client's handling of receiving a `RST_STREAM`. `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM` frame if an `END_STREAM` flag has been received _and_ the request body has completed sending. Previously it would be ignored only if an `END_STREAM` flag was seen which caused cancelled partial responses to 'hang' indefinitely should a client be transmitting data in a POST/PUT request. An overhaul of how `incoming_reset()` was done in an effore to simplify the method and make it easier to debug in the future.
> 
> Some changes where also made to the `schedule()` method in Stream (L190) to ensure both the sending of the Request Body and receipt of a RST_STREAM at various stages of an exchange do not cause unexpected behavior. Minor changes were made to the `Http2TestServer` implementation to improve the convinience of testing edge cases involving the sending of `HTTP/2` response headers. 
> 
> Concerning the new test cases, I have listed below the specifics of each case and the expected behavior of the client in the given scenario.
> 
> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code. Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set before an END_STREAM is received from the server.
>        - Expected/Observed Client Behavior: Client completes exceptionally in both cases.
> - Client sends a POST request with the `Expect: 100-Continue` header included
>    - Server responds with a `HEADERS` frame including a 100 status code and reads the request body. Server then sends Response Headers with status code 200 to complete the response. Server then sends RST_STREAM with code `NO_ERROR` or `PROTOCOL_ERROR` set...

This pull request has now been integrated.

Changeset: 3a7525d5
Author:    Conor Cleary <ccleary at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a7525d5c382985fb272f0b68316d7807b76f14a
Stats:     500 lines in 5 files changed: 362 ins; 72 del; 66 mod

8309118: HttpClient: Add more tests for 100 ExpectContinue with HTTP/2

Reviewed-by: dfuchs, djelinski

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

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

From djelinski at openjdk.org  Tue Oct 31 15:56:39 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 31 Oct 2023 15:56:39 GMT
Subject: RFR: 8299058: AssertionError in sun.net.httpserver.ServerImpl when
 connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <NOE9e7er5YStKsGwbVTli4zXsSnQMExpA9cgSVcHRTw=.80202e98-b5a1-475a-93d7-84bd5ef3b71f@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16366#issuecomment-1787497894

From djelinski at openjdk.org  Tue Oct 31 15:56:39 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 31 Oct 2023 15:56:39 GMT
Subject: Integrated: 8299058: AssertionError in sun.net.httpserver.ServerImpl
 when connection is idle
In-Reply-To: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
References: <Iy4QWrEyeJJcRRv3-PjGGj9iAStKUyjkDyxcla5A2VE=.e6cb2205-4806-4cbc-9a7a-0ae333cf8090@github.com>
Message-ID: <09ngcALmHo9qNjvzMfd9b_g8-q13nKDe1Qy4rFnjtGE=.9ced8363-2055-4dcc-b74e-41d1df90bc33@github.com>

On Wed, 25 Oct 2023 17:27:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes a race between the selector thread and the IdleTimeoutTask which closes connections that were idle for longer than IDLE_INTERVAL. With this patch, only the thread that successfully removes the connection from idleConnections is permitted to change it. If any data arrives after the IdleTimeoutTask removes the connection from idleConnections, the data is ignored.
> 
> Additionally, this patch reduces the time interval between when the IdleTimeoutTask removes the connection from idleConnections and when the connection is closed, back to pre-JDK-8286918 level.
> 
> No new test; with platform sockets it's next to impossible to reliably get the timing right. Existing tier1-3 tests pass.

This pull request has now been integrated.

Changeset: 47624f6f
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47624f6fc699aa66c58587460ce7f39fce5a86c7
Stats:     35 lines in 1 file changed: 8 ins; 13 del; 14 mod

8299058: AssertionError in sun.net.httpserver.ServerImpl when connection is idle

Reviewed-by: jpai, michaelm, dfuchs

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

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