From michaelm at openjdk.java.net  Tue May  3 09:15:30 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 3 May 2022 09:15:30 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v6]
In-Reply-To: <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
Message-ID: <bTvE7ov3fnkBLUUVJzBpZo8MU7_7NKjhnkZlN_A38ho=.e4ff549b-150a-4357-8708-8b74e1e68f26@github.com>

On Sat, 30 Apr 2022 09:55:16 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @requires jtreg tag rather than check in code

Changes requested by michaelm (Reviewer).

test/jdk/java/net/Inet4Address/PingThis.java line 32:

> 30:  * @requires os.family != "windows" && os.family != "aix"
> 31:  * @library /test/lib
> 32:  * @summary InetAddress.isReachable is returning false

'&&' double ampersand syntax does not work here. Should be a single ampersand as suggested by Aleksei.

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From aefimov at openjdk.java.net  Tue May  3 11:24:26 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 3 May 2022 11:24:26 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v6]
In-Reply-To: <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
Message-ID: <DG_iIuHNygMrGTeRZu31puAnCgECIsI3V3ZCJorfins=.19baa32a-46af-4be2-92af-ecc90a583a00@github.com>

On Sat, 30 Apr 2022 09:55:16 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @requires jtreg tag rather than check in code

test/jdk/java/net/Inet4Address/PingThis.java line 33:

> 31:  * @library /test/lib
> 32:  * @summary InetAddress.isReachable is returning false
> 33:  *          for InetAdress 0.0.0.0 and ::0

Typo: `InetAdress` -> `InetAddress`

test/jdk/java/net/Inet4Address/PingThis.java line 37:

> 35:  *          but does not respond as 127.0.0.1 (i.e., only responds
> 36:  *          when an external device reacts to 0.0.0.0)
> 37:  */

This line should be removed to fix formatting of the comment section, ie unbalanced `*/`

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From ccleary at openjdk.java.net  Wed May  4 10:06:41 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 4 May 2022 10:06:41 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
Message-ID: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>

**Issue**
A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 

- Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
- Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 

**Proposed Solution**
The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 

In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

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

Commit messages:
 - 8284585: PushPromiseContinuation test fails intermittently in timeout

Changes: https://git.openjdk.java.net/jdk/pull/8518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8518&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284585
  Stats: 63 lines in 4 files changed: 43 ins; 17 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8518/head:pull/8518

PR: https://git.openjdk.java.net/jdk/pull/8518

From dfuchs at openjdk.java.net  Wed May  4 11:12:26 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 4 May 2022 11:12:26 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
In-Reply-To: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
Message-ID: <W_sX1sMTMPVR7Hg4_7rbAe5N64Ow9aapgeHaaykmzyk=.d6d16986-37b0-4628-acf1-8c5d2e951f34@github.com>

On Tue, 3 May 2022 15:00:51 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
> 
> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
> 
> **Proposed Solution**
> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
> 
> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 881:

> 879:             nextPushStream += 2;
> 880:         }
> 881: 

Hi Conor - sorry for suggesting to move this code up into `handlePushPromise`. Now that I see the whole picture I believe these lines should have stayed where they were, in `completePushPromise`. The main reason is that we need to properly identify and decode possible ContinuationFrames as being part of the push promise in order to maintain the HPack encoders/decoders in sync, and we can only do that if we keep the `pushContinuationState` in place until we have received the END_HEADERS flag.

Sorry for suggesting that wrong move - it was my mistake.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 949:

> 947:             decrementStreamsCount(streamid);
> 948:             closeStream(streamid);
> 949:             System.err.println("closeStream");

Either remove or use a debug logger for this new trace.

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From dfuchs at openjdk.java.net  Wed May  4 11:25:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 4 May 2022 11:25:21 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
In-Reply-To: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
Message-ID: <jDqP4Dncc4imDs2-LQ6mJdksg6BED7c-Y4xOeJzT4UE=.63afc00c-dfe8-4ba7-b7f8-fa95383d9161@github.com>

On Tue, 3 May 2022 15:00:51 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
> 
> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
> 
> **Proposed Solution**
> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
> 
> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java line 949:

> 947:         pp.streamid(op.parentStream);
> 948:         writeFrame(pp);
> 949:         if (pp.getFlags() != HeadersFrame.END_HEADERS && op.hasContinuations()) {

Maybe you could just drop `op.hasContinuations()`

test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java line 950:

> 948:         writeFrame(pp);
> 949:         if (pp.getFlags() != HeadersFrame.END_HEADERS && op.hasContinuations()) {
> 950:             LinkedList<ContinuationFrame> continuations = new LinkedList<>(op.getContinuations());

That copy seems unneeded?

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 39:

> 37:     final InputStream is;
> 38:     final int parentStream; // not the pushed streamid
> 39:     private LinkedList<ContinuationFrame> continuations;

Make this `final` and instantiate it in the constructor instead. 
Could use `List<ContinuationFrame>` here - or even `List<Http2Frame>` if you want to simulate the bug we had before - e.g - you could add a `HeaderFrame` instead of a `ContinuationFrame`, and verify the client no longer hangs and rightfully closes the connection...

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 56:

> 54:             continuations = new LinkedList<>();
> 55:         continuations.add(cf);
> 56:     }

I would suggest adding a constructor that takes a list of continuations/frames instead. This way you could have an immutable list (use List.of/List.copyOf)

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 60:

> 58:     public boolean hasContinuations() {
> 59:         return !continuations.isEmpty();
> 60:     }

That method is not needed. Plus it will throw if `continuations` is null.

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 64:

> 62:     public LinkedList<ContinuationFrame> getContinuations() {
> 63:         return continuations;
> 64:     }

Same remark here - you could use `List` instead of `LinkedList`.

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Wed May  4 11:39:25 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 4 May 2022 11:39:25 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
In-Reply-To: <W_sX1sMTMPVR7Hg4_7rbAe5N64Ow9aapgeHaaykmzyk=.d6d16986-37b0-4628-acf1-8c5d2e951f34@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <W_sX1sMTMPVR7Hg4_7rbAe5N64Ow9aapgeHaaykmzyk=.d6d16986-37b0-4628-acf1-8c5d2e951f34@github.com>
Message-ID: <6rd8O49KmEE4_DcFXR65ngmx5F57qd1L71djP0N8QX0=.77d1dee9-4a1c-429f-9bc9-1c9fa85029f2@github.com>

On Wed, 4 May 2022 11:05:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 881:
> 
>> 879:             nextPushStream += 2;
>> 880:         }
>> 881: 
> 
> Hi Conor - sorry for suggesting to move this code up into `handlePushPromise`. Now that I see the whole picture I believe these lines should have stayed where they were, in `completePushPromise`. The main reason is that we need to properly identify and decode possible ContinuationFrames as being part of the push promise in order to maintain the HPack encoders/decoders in sync, and we can only do that if we keep the `pushContinuationState` in place until we have received the END_HEADERS flag.
> 
> Sorry for suggesting that wrong move - it was my mistake.

No problem at all Daniel. I see what you're saying, essentially that if the Continuation does come in on the wrong stream id, it still needs to be decoded and identified as a part of the Push Promise before being rejected with the wrong stream id.

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Wed May  4 13:35:21 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 4 May 2022 13:35:21 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
In-Reply-To: <jDqP4Dncc4imDs2-LQ6mJdksg6BED7c-Y4xOeJzT4UE=.63afc00c-dfe8-4ba7-b7f8-fa95383d9161@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <jDqP4Dncc4imDs2-LQ6mJdksg6BED7c-Y4xOeJzT4UE=.63afc00c-dfe8-4ba7-b7f8-fa95383d9161@github.com>
Message-ID: <MuR1URJuKVZ445dGIhXnq5GcReO6LhlR0_K_lIQbbbg=.231af9f7-b465-4b7c-a03c-f0324268fa2e@github.com>

On Wed, 4 May 2022 11:13:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java line 949:
> 
>> 947:         pp.streamid(op.parentStream);
>> 948:         writeFrame(pp);
>> 949:         if (pp.getFlags() != HeadersFrame.END_HEADERS && op.hasContinuations()) {
> 
> Maybe you could just drop `op.hasContinuations()`

I had it like this to account for a case where a test could incorrectly add continuations to an OutgoingPushPromise without correctly setting the END_HEADERS flag on the PushPromiseFrame. This could possibly be handled in OutgoingPushPromise though.

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Wed May  4 13:50:15 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 4 May 2022 13:50:15 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout
In-Reply-To: <jDqP4Dncc4imDs2-LQ6mJdksg6BED7c-Y4xOeJzT4UE=.63afc00c-dfe8-4ba7-b7f8-fa95383d9161@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <jDqP4Dncc4imDs2-LQ6mJdksg6BED7c-Y4xOeJzT4UE=.63afc00c-dfe8-4ba7-b7f8-fa95383d9161@github.com>
Message-ID: <KIctpkDyiyYqURQj0LYP39QHuBiwidxsaIdI7T8vjhM=.871c6e9d-65c0-49fa-bf6d-6e76e97e7eff@github.com>

On Wed, 4 May 2022 11:17:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 56:
> 
>> 54:             continuations = new LinkedList<>();
>> 55:         continuations.add(cf);
>> 56:     }
> 
> I would suggest adding a constructor that takes a list of continuations/frames instead. This way you could have an immutable list (use List.of/List.copyOf)

Ah, good suggestion!

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From duke at openjdk.java.net  Thu May  5 12:55:57 2022
From: duke at openjdk.java.net (Michael Felt)
Date: Thu, 5 May 2022 12:55:57 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
Message-ID: <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>

> with IP "0.0.0.0"
> 
> - it either does nothing and ping fails, or, in some virtual environments
> is treated as the default route address.
> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
> as a vaild psuedo IPv6 address. '::1' must be used instead.
> 
> ping: bind: The socket name is not available on this system.
> ping: bind: The socket name is not available on this system.
> PING ::1: (::1): 56 data bytes
> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
> 
> --- ::1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max = 0/0/0 ms
> PING ::1: (::1): 56 data bytes
> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
> 
> --- ::1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> 
> 
> A long commit message. 
> 
> This came to light because some systems failed with IPv4 (those that passed
> replaced 0.0.0.0 with the default router. but most just fail - not substituting
> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
> which compares well with other platform's behavior.

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

  Changes per review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7013/files
  - new: https://git.openjdk.java.net/jdk/pull/7013/files/56c37474..afe59252

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From duke at openjdk.java.net  Thu May  5 12:55:58 2022
From: duke at openjdk.java.net (Michael Felt)
Date: Thu, 5 May 2022 12:55:58 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v6]
In-Reply-To: <bTvE7ov3fnkBLUUVJzBpZo8MU7_7NKjhnkZlN_A38ho=.e4ff549b-150a-4357-8708-8b74e1e68f26@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
 <bTvE7ov3fnkBLUUVJzBpZo8MU7_7NKjhnkZlN_A38ho=.e4ff549b-150a-4357-8708-8b74e1e68f26@github.com>
Message-ID: <RW17w301KnqfaHtMIUqtcs_NdFuIAiIf-p7RDGg2T0g=.26d2cd65-63d5-40f8-8a6f-3f0fb1b4fc3d@github.com>

On Tue, 3 May 2022 09:11:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use @requires jtreg tag rather than check in code
>
> test/jdk/java/net/Inet4Address/PingThis.java line 32:
> 
>> 30:  * @requires os.family != "windows" && os.family != "aix"
>> 31:  * @library /test/lib
>> 32:  * @summary InetAddress.isReachable is returning false
> 
> '&&' double ampersand syntax does not work here. Should be a single ampersand as suggested by Aleksei.

Once a C programmer, hard to resist. Thx. :)

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From duke at openjdk.java.net  Thu May  5 12:55:59 2022
From: duke at openjdk.java.net (Michael Felt)
Date: Thu, 5 May 2022 12:55:59 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v6]
In-Reply-To: <DG_iIuHNygMrGTeRZu31puAnCgECIsI3V3ZCJorfins=.19baa32a-46af-4be2-92af-ecc90a583a00@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <bpe_0sd09VAn3x9bMS7iZn1YFiLJy_3bdN8z_tXrrTI=.7f020a82-ec1d-43ad-afc5-01c0c8d9ca44@github.com>
 <DG_iIuHNygMrGTeRZu31puAnCgECIsI3V3ZCJorfins=.19baa32a-46af-4be2-92af-ecc90a583a00@github.com>
Message-ID: <3jwL4usrGHJYUoB5H4jY3odIqQf4jpBVyhb7-_tPqGE=.36553c65-164f-4b17-8b9c-49bfcc081f3c@github.com>

On Tue, 3 May 2022 11:13:37 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use @requires jtreg tag rather than check in code
>
> test/jdk/java/net/Inet4Address/PingThis.java line 33:
> 
>> 31:  * @library /test/lib
>> 32:  * @summary InetAddress.isReachable is returning false
>> 33:  *          for InetAdress 0.0.0.0 and ::0
> 
> Typo: `InetAdress` -> `InetAddress`

I did not actually change that line - but fixing :)

> test/jdk/java/net/Inet4Address/PingThis.java line 37:
> 
>> 35:  *          but does not respond as 127.0.0.1 (i.e., only responds
>> 36:  *          when an external device reacts to 0.0.0.0)
>> 37:  */
> 
> This line should be removed to fix formatting of the comment section, ie unbalanced `*/`

Thx!

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From ccleary at openjdk.java.net  Thu May  5 13:37:08 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 5 May 2022 13:37:08 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v2]
In-Reply-To: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
Message-ID: <yGFjIK_DukudwIXrRx5HMWYleP7zAG76yCW9JU9J5J8=.a892bdf6-d961-4b30-b691-b9ad4c0c88ac@github.com>

> **Issue**
> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
> 
> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
> 
> **Proposed Solution**
> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
> 
> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

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

  8284585: New constructor & minor improvements

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8518/files
  - new: https://git.openjdk.java.net/jdk/pull/8518/files/cb6c189b..24e702a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8518&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8518&range=00-01

  Stats: 48 lines in 4 files changed: 18 ins; 16 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8518/head:pull/8518

PR: https://git.openjdk.java.net/jdk/pull/8518

From michaelm at openjdk.java.net  Thu May  5 14:18:27 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 5 May 2022 14:18:27 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
Message-ID: <l3NfCsHk9wCpzir0cgMOtajK_eiTWm5vUtZhFGgW7fM=.5919373b-fdbf-40c1-8094-f10bc43194cb@github.com>

On Thu, 5 May 2022 12:55:57 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes per review

LGTM

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

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7013

From dfuchs at openjdk.java.net  Thu May  5 19:47:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 5 May 2022 19:47:36 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
Message-ID: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>

Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`

A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.

The fix comprises several cleanup - in particular:

- `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
- `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
- `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
- `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
- `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

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

Commit messages:
 - 8286194: ExecutorShutdown test fails intermittently

Changes: https://git.openjdk.java.net/jdk/pull/8562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286194
  Stats: 135 lines in 7 files changed: 107 ins; 3 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8562/head:pull/8562

PR: https://git.openjdk.java.net/jdk/pull/8562

From aefimov at openjdk.java.net  Thu May  5 22:45:09 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 5 May 2022 22:45:09 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
Message-ID: <uBRayky52EhhdslJsosLe56_F2TpwEYuRbluirfmE0I=.834fbdd7-aeb6-4f76-9f27-1500979a3e39@github.com>

On Thu, 5 May 2022 12:55:57 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes per review

Latest changes look good to me. Will check that the test runs/not runs with our CI and will sponsor it once I have the results.

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

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7013

From jpai at openjdk.java.net  Fri May  6 04:53:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 04:53:47 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com>

On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

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

> 1037:                 e.abort(selectorClosedException());
> 1038:             } else {
> 1039:                 selector.wakeup();

Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK?

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From jpai at openjdk.java.net  Fri May  6 05:00:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 05:00:47 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com>

On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java line 784:

> 782: 
> 783:                 while (Utils.synchronizedRemaining(writeList) > 0 || hsTriggered() || needWrap()) {
> 784:                     if (scheduler.isStopped()) return;

If the `scheduler` is stopped then would this task instance be ever called again? If it won't be called again, then do you think we should perhaps drain the queued `writeList` to reduce any memory resource accumulation till the next GC cycle?

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From jpai at openjdk.java.net  Fri May  6 05:19:50 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 05:19:50 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <FKhV8WSqy7TNu6kYv10HaTXz_xqzCZdC9se_ZtKgd5o=.2bff30f2-839d-4707-90ea-52d2009ca729@github.com>

On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java line 347:

> 345: 
> 346:     void upstreamWindowUpdate() {
> 347:         if (pushScheduler.isStopped()) return;

A similar question here. It looks to me that the contract with a `SequentialScheduler` is that the runnable task itself (or someone with access to the scheduler), is responsible for invoking the `runOrSchedule` method so that a next invocation of the task happens. When such a scheduler instance is already stopped, then the call to `runOrSchedule` is kind of a noop, with no next execution of the task taking place. In cases like here, where the task detects that the scheduler has already stopped, do you think the tasks should do some cleanup work like clearing up the `outputQ` of `ByteBuffers`?

The question really isn't directly related to the PR, but I have been reviewing some unrelated test failures where a large number of HttpClient instances get created, so in that context, I was wondering if there's anything we could do to help reduce any potential memory usage.

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From jpai at openjdk.java.net  Fri May  6 05:25:55 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 05:25:55 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <jn9b-rYh29dikczpfmrPwOFVGjHTvfb4qJqTYyPeUI4=.5064564b-9a1c-43a4-a096-fe3c794755f9@github.com>

On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

test/jdk/java/net/httpclient/ReferenceTracker.java line 95:

> 93:     }
> 94: 
> 95:     private static String toString(ThreadInfo info) {

Should we perhaps add a comment to this method explaining why we are duplicating the implementation of `ThreadInfo#toString()` here?

I can't find in commit logs or the documentation of the `ThreadInfo` class on why its `toString()` implementation just outputs only 8 stacktrace elements. Do you think we should remove that restriction or document it in a separate issue?

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From dfuchs at openjdk.java.net  Fri May  6 09:18:48 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 09:18:48 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com>
Message-ID: <hYE4-QCI_2F_dXlu-Ruzw0QULuft-4t9wlM8VrMt3zI=.5aa53171-bc1c-4478-8d8d-61d35b97e9d4@github.com>

On Fri, 6 May 2022 04:49:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
>> 
>> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
>> 
>> The fix comprises several cleanup - in particular:
>> 
>> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
>> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
>> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
>> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
>> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1039:
> 
>> 1037:                 e.abort(selectorClosedException());
>> 1038:             } else {
>> 1039:                 selector.wakeup();
> 
> Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK?

And this is what (or at least a part of what) was causing the issue. We need to add the event to the `registrations` list within a synchronized block because that's a plain ArrayList whose access is controlled by synchronizing on `this`. However the event should not be invoked within the synchronized and block, and if you look at the calling method (eventUpdated) you will see that this is what we are doing there too (raising the event without synchronizing).

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From duke at openjdk.java.net  Fri May  6 09:22:01 2022
From: duke at openjdk.java.net (Michael Felt)
Date: Fri, 6 May 2022 09:22:01 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
Message-ID: <5pdPpiW1RsG4nIcmju0FzeUR1oPXNYSjFYajQs6oQvY=.079889e3-1311-4a5c-9503-27f8999eea16@github.com>

On Thu, 5 May 2022 12:55:57 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes per review

- Thx all for your assistance and patience.
- (Hoping you will consider this for backport as well).

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From dfuchs at openjdk.java.net  Fri May  6 09:27:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 09:27:46 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com>
Message-ID: <zf3mj-IuUioCih9-atEqR9sXfl2_Fed6Zqhe6B-yk70=.2b3911e5-061d-4746-a7ba-994a86431c0d@github.com>

On Fri, 6 May 2022 04:57:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
>> 
>> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
>> 
>> The fix comprises several cleanup - in particular:
>> 
>> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
>> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
>> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
>> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
>> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java line 784:
> 
>> 782: 
>> 783:                 while (Utils.synchronizedRemaining(writeList) > 0 || hsTriggered() || needWrap()) {
>> 784:                     if (scheduler.isStopped()) return;
> 
> If the `scheduler` is stopped then would this task instance be ever called again? If it won't be called again, then do you think we should perhaps drain the queued `writeList` to reduce any memory resource accumulation till the next GC cycle?

if the scheduler is closed the connection is being stopped and will be shortly eligible for garbage collection, so I wouldn't bother with trying to clear the queue.

> test/jdk/java/net/httpclient/ReferenceTracker.java line 95:
> 
>> 93:     }
>> 94: 
>> 95:     private static String toString(ThreadInfo info) {
> 
> Should we perhaps add a comment to this method explaining why we are duplicating the implementation of `ThreadInfo#toString()` here?
> 
> I can't find in commit logs or the documentation of the `ThreadInfo` class on why its `toString()` implementation just outputs only 8 stacktrace elements. Do you think we should remove that restriction or document it in a separate issue?

Good idea to add a comment. I have also wondered if we should add a new method to ThreadInfo that would take a "maxdepth" integer. I don't know why the output is limited to 8 element. Maybe we should log an enhancement request and let the maintainers of ThreadInfo decide if they want to remove the limitation or provide a new method, or do nothing.

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From dfuchs at openjdk.java.net  Fri May  6 09:38:38 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 09:38:38 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2]
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <ZgCnp6suMi_shyAj-zOzDeUQHaCAc0yZmrF1KEsFxds=.f99f2049-1857-40ec-bee6-3a67ad6cb35a@github.com>

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

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

  Added a comment to ReferenceTracker.java as suggested in the review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8562/files
  - new: https://git.openjdk.java.net/jdk/pull/8562/files/0a674cef..ce8ad93d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From jpai at openjdk.java.net  Fri May  6 09:46:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 09:46:49 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2]
In-Reply-To: <ZgCnp6suMi_shyAj-zOzDeUQHaCAc0yZmrF1KEsFxds=.f99f2049-1857-40ec-bee6-3a67ad6cb35a@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <ZgCnp6suMi_shyAj-zOzDeUQHaCAc0yZmrF1KEsFxds=.f99f2049-1857-40ec-bee6-3a67ad6cb35a@github.com>
Message-ID: <6EY0ZcPkoG2pbgwWnhqLyanBq8k-bBdZ04v23UfxwzQ=.1de41265-fb62-4f58-a3bb-076e738bb5f3@github.com>

On Fri, 6 May 2022 09:38:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
>> 
>> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
>> 
>> The fix comprises several cleanup - in particular:
>> 
>> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
>> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
>> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
>> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
>> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a comment to ReferenceTracker.java as suggested in the review

The updated PR with the `ThreadInfo.toString()` comment, looks good to me.

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

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8562

From jpai at openjdk.java.net  Fri May  6 09:46:50 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 6 May 2022 09:46:50 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2]
In-Reply-To: <hYE4-QCI_2F_dXlu-Ruzw0QULuft-4t9wlM8VrMt3zI=.5aa53171-bc1c-4478-8d8d-61d35b97e9d4@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com>
 <hYE4-QCI_2F_dXlu-Ruzw0QULuft-4t9wlM8VrMt3zI=.5aa53171-bc1c-4478-8d8d-61d35b97e9d4@github.com>
Message-ID: <h4INGW1jnapv05Q1Kvz0i0PNSlEUTzq6VUfMqOD2WQM=.891b8cbc-9c78-4d87-8655-1a2b3c7ab639@github.com>

On Fri, 6 May 2022 09:14:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1039:
>> 
>>> 1037:                 e.abort(selectorClosedException());
>>> 1038:             } else {
>>> 1039:                 selector.wakeup();
>> 
>> Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK?
>
> And this is what (or at least a part of what) was causing the issue. We need to add the event to the `registrations` list within a synchronized block because that's a plain ArrayList whose access is controlled by synchronizing on `this`. However the event should not be invoked within the synchronized and block, and if you look at the calling method (eventUpdated) you will see that this is what we are doing there too (raising the event without synchronizing).

Thank you for that explanation. I understand this change better now.

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From dfuchs at openjdk.java.net  Fri May  6 09:46:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 09:46:50 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2]
In-Reply-To: <FKhV8WSqy7TNu6kYv10HaTXz_xqzCZdC9se_ZtKgd5o=.2bff30f2-839d-4707-90ea-52d2009ca729@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <FKhV8WSqy7TNu6kYv10HaTXz_xqzCZdC9se_ZtKgd5o=.2bff30f2-839d-4707-90ea-52d2009ca729@github.com>
Message-ID: <Icej3VelNFfBtqjYTR2Ss_1C2pmEuFE6ruLRPSBpywM=.5a8d684d-8494-4d02-8f15-fc4b095884ff@github.com>

On Fri, 6 May 2022 05:16:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a comment to ReferenceTracker.java as suggested in the review
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java line 347:
> 
>> 345: 
>> 346:     void upstreamWindowUpdate() {
>> 347:         if (pushScheduler.isStopped()) return;
> 
> A similar question here. It looks to me that the contract with a `SequentialScheduler` is that the runnable task itself (or someone with access to the scheduler), is responsible for invoking the `runOrSchedule` method so that a next invocation of the task happens. When such a scheduler instance is already stopped, then the call to `runOrSchedule` is kind of a noop, with no next execution of the task taking place. In cases like here, where the task detects that the scheduler has already stopped, do you think the tasks should do some cleanup work like clearing up the `outputQ` of `ByteBuffers`?
> 
> The question really isn't directly related to the PR, but I have been reviewing some unrelated test failures where a large number of HttpClient instances get created, so in that context, I was wondering if there's anything we could do to help reduce any potential memory usage.

What happens here is a bit more subtle: if we don't return, the code is going to request more data from upstream, even though that data won't be processed, and that will fill up the queue, and potentially cause more data to be wrapped by the SSLEngine and sent down stream. I have observed that some activity was still ongoing in the SSLTube/SSLFlowDelegate after the underlying TCP channel had been closed, when there's no chance that this data will be ever sent, and the logs I was observing showed that returning at this point was effectively stopping that useless activity early. The fact that the channel is bidirectional and that the implementation is fully asynchronous means that several tasks may be executing in background threads at the time the TCP connection is closed. If the effect of these task is to simply request, process and submit data that will be later ignored (or cause more exceptions to be relayed) - then we should stop them early.

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From ccleary at openjdk.java.net  Fri May  6 10:33:31 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 6 May 2022 10:33:31 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v6]
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <UmiJP4Tr69prktvrkhz6DHLeT9xC088Px3mmE1pYqZc=.ea04b8be-61f1-4e7d-8762-8b345702d3ef@github.com>

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

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

  8283544: Improved logging, drain input stream

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8017/files
  - new: https://git.openjdk.java.net/jdk/pull/8017/files/c1ef7d29..83c6ca6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From dfuchs at openjdk.java.net  Fri May  6 10:44:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 10:44:56 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v6]
In-Reply-To: <UmiJP4Tr69prktvrkhz6DHLeT9xC088Px3mmE1pYqZc=.ea04b8be-61f1-4e7d-8762-8b345702d3ef@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <UmiJP4Tr69prktvrkhz6DHLeT9xC088Px3mmE1pYqZc=.ea04b8be-61f1-4e7d-8762-8b345702d3ef@github.com>
Message-ID: <2Hhr09GCN-Ep1qMGblWdPp90kc1MKiNj89ZXBZ_HgIA=.f07aa506-7e08-46cb-9efe-e1af93690b8e@github.com>

On Fri, 6 May 2022 10:33:31 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Improved logging, drain input stream

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 311:

> 309:                 streaming = true;
> 310:                 systemHeadersBuilder.setHeader("Transfer-encoding", "chunked");
> 311:             }

With that - and if I'm not mistaken, lines 294-299 can be removed now.

test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 105:

> 103:                 .uri(URI.create(testContentLengthURI + NO_BODY_PATH))
> 104:                 .build();
> 105:         HttpClient hc = HttpClient.newHttpClient();

It would be better to reuse the same client for all tests. Also better to configure it with NO_PROXY.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From dfuchs at openjdk.java.net  Fri May  6 10:54:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 10:54:44 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v2]
In-Reply-To: <yGFjIK_DukudwIXrRx5HMWYleP7zAG76yCW9JU9J5J8=.a892bdf6-d961-4b30-b691-b9ad4c0c88ac@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <yGFjIK_DukudwIXrRx5HMWYleP7zAG76yCW9JU9J5J8=.a892bdf6-d961-4b30-b691-b9ad4c0c88ac@github.com>
Message-ID: <o3crXQ03-OqsSf990Kd2HFrXKDIZ49TQMiYwy2QV7gk=.8e8127a4-50e5-4fba-a0dd-c1f3b4b76ef2@github.com>

On Thu, 5 May 2022 13:37:08 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284585: New constructor & minor improvements

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 41:

> 39:     final InputStream is;
> 40:     final int parentStream; // not the pushed streamid
> 41:     private final List<ContinuationFrame> continuations;

Looks much better - thanks. If you changed that to `List<Http2Frame>` instead it would allow you to add a test case where the server would send a regular HeaderFrame on the pushPromiseStream before sending the continuation on the original stream. You'd just have to put a HeaderFrame in that list before the ContinuationFrame. That would reproduce the failure we had before your fix, and that would allow you to verify that the bug that got the client hanging has been fixed on the client side too.

test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java line 54:

> 52:         this.continuations = null;
> 53:     }
> 54: 

This constuctor should call the other consdtructor below:


    public OutgoingPushPromise(int parentStream,
                               URI uri,
                               HttpHeaders headers,
                               InputStream is) {
        this(parentStream, uri, headers, is, List.of());
    }

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From dfuchs at openjdk.java.net  Fri May  6 11:12:10 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 11:12:10 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry
 should use less resources
Message-ID: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>

Hi,

Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
The test is split to test GET and POST separately and avoids testing GET twice.

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

Commit messages:
 - 8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry should use less resources

Changes: https://git.openjdk.java.net/jdk/pull/8569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286293
  Stats: 501 lines in 5 files changed: 315 ins; 172 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8569/head:pull/8569

PR: https://git.openjdk.java.net/jdk/pull/8569

From ccleary at openjdk.java.net  Fri May  6 13:46:41 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 6 May 2022 13:46:41 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

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

  8283544: Removed unecessary control flow

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8017/files
  - new: https://git.openjdk.java.net/jdk/pull/8017/files/83c6ca6e..f6efc915

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=05-06

  Stats: 22 lines in 2 files changed: 7 ins; 15 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8017/head:pull/8017

PR: https://git.openjdk.java.net/jdk/pull/8017

From dfuchs at openjdk.java.net  Fri May  6 14:02:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 14:02:37 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v6]
In-Reply-To: <2Hhr09GCN-Ep1qMGblWdPp90kc1MKiNj89ZXBZ_HgIA=.f07aa506-7e08-46cb-9efe-e1af93690b8e@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <UmiJP4Tr69prktvrkhz6DHLeT9xC088Px3mmE1pYqZc=.ea04b8be-61f1-4e7d-8762-8b345702d3ef@github.com>
 <2Hhr09GCN-Ep1qMGblWdPp90kc1MKiNj89ZXBZ_HgIA=.f07aa506-7e08-46cb-9efe-e1af93690b8e@github.com>
Message-ID: <bpqoxi2jDfxlZPaNKAgvVtc6oJTejGj5Iz7sjvIhbZY=.33c4129a-84cb-45c0-b287-f921ecb85e92@github.com>

On Fri, 6 May 2022 10:39:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8283544: Improved logging, drain input stream
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 311:
> 
>> 309:                 streaming = true;
>> 310:                 systemHeadersBuilder.setHeader("Transfer-encoding", "chunked");
>> 311:             }
> 
> With that - and if I'm not mistaken, lines 294-299 can be removed now.

hmmm... some parts seem to be missing now. I believe what we need is:


// Absence of a requestPublisher indicates a request with no body
// (GET, HEAD, DELETE), in which case we don't explicitly set any
//  Content-Length header
if (requestPublisher != null) {
    contentLength = requestPublisher.contentLength();
    if (contentLength == 0) {
        systemHeadersBuilder.setHeader("Content-Length", "0");
    } else if (contentLength > 0) {
        systemHeadersBuilder.setHeader("Content-Length", Long.toString(contentLength));
        streaming = false;
    } else {
        streaming = true;
        systemHeadersBuilder.setHeader("Transfer-encoding", "chunked");
    }
}

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From aefimov at openjdk.java.net  Fri May  6 16:18:59 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 6 May 2022 16:18:59 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <5pdPpiW1RsG4nIcmju0FzeUR1oPXNYSjFYajQs6oQvY=.079889e3-1311-4a5c-9503-27f8999eea16@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
 <5pdPpiW1RsG4nIcmju0FzeUR1oPXNYSjFYajQs6oQvY=.079889e3-1311-4a5c-9503-27f8999eea16@github.com>
Message-ID: <GE00H2ROyC4anCRDAT2IYkvoDz8vL1IJ5pNlOmsD55U=.0e8b62cc-9be4-4da6-9d84-b3d2c8bb903f@github.com>

On Fri, 6 May 2022 09:18:33 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes per review
>
> - Thx all for your assistance and patience.
> - (Hoping you will consider this for backport as well).

Hi @aixtools,
The test runs fine on non-windows/non-aix platforms. The fix is ready for the integration: I will sponsor it after you issue `/integrate` [command](https://github.com/openjdk/jdk/pull/7013#issuecomment-1111165207).

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From dfuchs at openjdk.java.net  Fri May  6 16:31:45 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 6 May 2022 16:31:45 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
Message-ID: <a3mFp0TM4IWZKC9ayIwfx5syKFuUsvefXtsDazSMPE0=.5d6a2640-a4d9-46fc-9701-06f3f93216bf@github.com>

On Thu, 5 May 2022 12:55:57 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> with IP "0.0.0.0"
>> 
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psuedo IPv6 address. '::1' must be used instead.
>> 
>> ping: bind: The socket name is not available on this system.
>> ping: bind: The socket name is not available on this system.
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> round-trip min/avg/max = 0/0/0 ms
>> PING ::1: (::1): 56 data bytes
>> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms
>> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms
>> 
>> --- ::1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0% packet loss
>> 
>> 
>> A long commit message. 
>> 
>> This came to light because some systems failed with IPv4 (those that passed
>> replaced 0.0.0.0 with the default router. but most just fail - not substituting
>> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1
>> which compares well with other platform's behavior.
>
> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes per review

The last version looks good to me too. I agree that using `@requires` is a cleaner way to skip or select the test. Thanks for making this change!

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7013

From duke at openjdk.java.net  Fri May  6 17:54:09 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 6 May 2022 17:54:09 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
Message-ID: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>

JDK-6725221 Standardize obtaining boolean properties with defaults

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

Commit messages:
 - Merge
 - first iteration

Changes: https://git.openjdk.java.net/jdk/pull/8559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6725221
  Stats: 27 lines in 10 files changed: 1 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559

PR: https://git.openjdk.java.net/jdk/pull/8559

From alanb at openjdk.java.net  Fri May  6 17:59:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 17:59:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:

> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
> 776:             printStackWhenAccessFails = GetBooleanAction.
> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");

Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From prr at openjdk.java.net  Fri May  6 18:29:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 6 May 2022 18:29:44 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <Kz5T3kPgGZRt1KyyScVHeqSmylZ1ZIEaYJa5JOQOl4Q=.6008f002-655c-42e6-8100-89b018436ca8@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

The xtoolkit change is fine. I've not looked at anything else
You'll clearly need multiple reviewers for this one.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8559

From wetmore at openjdk.java.net  Sat May  7 00:08:45 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sat, 7 May 2022 00:08:45 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <pM6XyY27LGmxI28uQudn3alEQB8R_jnmU5uW7uHYaC8=.ae1daeea-8ddd-4a1d-bcfe-b56a02bb137a@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

Sorry for the confusion.

The original intent of this bug 14 years ago was to standardize the seclibs code where simple getProperty calls were needed in the context of an AccessController, without having to provide the doProvided calls. i.e. GetBooleanAction.privilegedGetProperty(). This was not intended not other parts of the JDK.

For example: ChannelImpl.java provides a getBooleanProperty() method, which is very similar to GetBooleanAction. I noticed other places in the security where this was being done.

Some of the classes like Debug have been rewritten (SSLLogger), so the issue does not appear to exist there any logger.

The certpath code is working with Security.getProperty(), so that was a red herring.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From dfuchs at openjdk.java.net  Sat May  7 11:46:32 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Sat, 7 May 2022 11:46:32 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources [v2]
In-Reply-To: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
Message-ID: <TQq9ZYA7TnAQfShXl7zVO6VTTswq8rl2t_zOCn59ulY=.8227e4ba-01f8-4930-a77e-e6a6192e0f1b@github.com>

> Hi,
> 
> Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
> The test is split to test GET and POST separately and avoids testing GET twice.

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

 - Merge branch 'master' into ShortResponseBody
 - 8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry should use less resources

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8569/files
  - new: https://git.openjdk.java.net/jdk/pull/8569/files/b212c007..11959ee8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8569&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8569&range=00-01

  Stats: 109734 lines in 1343 files changed: 97735 ins; 5210 del; 6789 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8569/head:pull/8569

PR: https://git.openjdk.java.net/jdk/pull/8569

From dfuchs at openjdk.java.net  Sat May  7 11:46:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Sat, 7 May 2022 11:46:37 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3]
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

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

 - Merge branch 'master' into ExecutorShutdown-intermittent-8286194
 - Added a comment to ReferenceTracker.java as suggested in the review
 - 8286194: ExecutorShutdown test fails intermittently

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8562/files
  - new: https://git.openjdk.java.net/jdk/pull/8562/files/ce8ad93d..12bf40b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=01-02

  Stats: 102369 lines in 1228 files changed: 93484 ins; 3845 del; 5040 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8562/head:pull/8562

PR: https://git.openjdk.java.net/jdk/pull/8562

From prr at openjdk.java.net  Sun May  8 02:25:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 8 May 2022 02:25:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

I did wonder why it has security-libs as the sub-category and if the intent was not what we see here.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From alanb at openjdk.java.net  Sun May  8 05:18:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 8 May 2022 05:18:49 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>
Message-ID: <oPrZ1ZcTJkse6eEWRomgXys5m0pRmNAP2AFKf0Rd9Uo=.5f682889-5e10-400f-a43a-d0c54610fcb2@github.com>

On Sun, 8 May 2022 02:22:08 GMT, Phil Race <prr at openjdk.org> wrote:

> I did wonder why it has security-libs as the sub-category and if the intent was not what we see here.

I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The issue is that it changes the meaning of the empty value case in at least two places so each one will require careful attention.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From jpai at openjdk.java.net  Mon May  9 07:52:29 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 9 May 2022 07:52:29 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v17]
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <sFd_ifvauzJmleLhNKPPEQ-GmSdnFBPXY2PC3ShRrqM=.439bf96a-231e-4bb5-b9a5-69d60f2b7713@github.com>

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge latest from master branch
 - add a @build to force jtreg to show consistent test results and add the relevant permissions for security manager testing
 - Change the new API to accept an InetAddress instead of an InetSocketAddress, after inputs from Michael, Daniel and others
 - Merge latest from master
 - Implement HttpServerAdapters in test as suggested by Daniel
 - fix check when security manager is enabled
 - Add a unit test for the new HttpClient.Builder.localAddress method
 - Implement Daniel's suggestion - only support InetSocketAddress with port 0
 - Merge latest from master branch
 - Merge latest from master branch
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/b490a58e...d4a19dea

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

Changes: https://git.openjdk.java.net/jdk/pull/6690/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=16
  Stats: 530 lines in 11 files changed: 521 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6690.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690

PR: https://git.openjdk.java.net/jdk/pull/6690

From michaelm at openjdk.java.net  Mon May  9 12:01:16 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 9 May 2022 12:01:16 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources [v2]
In-Reply-To: <TQq9ZYA7TnAQfShXl7zVO6VTTswq8rl2t_zOCn59ulY=.8227e4ba-01f8-4930-a77e-e6a6192e0f1b@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
 <TQq9ZYA7TnAQfShXl7zVO6VTTswq8rl2t_zOCn59ulY=.8227e4ba-01f8-4930-a77e-e6a6192e0f1b@github.com>
Message-ID: <2jVr0JK6umyms-MJ3wCGljZL2zU24NS-cQEehV-cKUg=.8254058d-2f51-4bb0-8e1a-bf24680f8332@github.com>

On Sat, 7 May 2022 11:46:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
>> The test is split to test GET and POST separately and avoids testing GET twice.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into ShortResponseBody
>  - 8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry should use less resources

test/jdk/java/net/httpclient/ShortResponseBodyPost.java line 31:

> 29:  * @library /test/lib
> 30:  * @build jdk.test.lib.net.SimpleSSLContext ShortResponseBody ShortResponseBodyGet
> 31:  * @run testng/othervm

Seems like the build directive should refer to ShortResponseBodyPost instead of ShortResponseBodyGet

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

PR: https://git.openjdk.java.net/jdk/pull/8569

From dfuchs at openjdk.java.net  Mon May  9 12:37:59 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 9 May 2022 12:37:59 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources [v3]
In-Reply-To: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
Message-ID: <jauKFevs_5ZcXEBlz8vBxkfGG6heVmh2qe9mBIj5F3M=.b449b60a-bb8c-4531-811a-849e8d875022@github.com>

> Hi,
> 
> Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
> The test is split to test GET and POST separately and avoids testing GET twice.

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

  Fixed @build

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8569/files
  - new: https://git.openjdk.java.net/jdk/pull/8569/files/11959ee8..17cc353a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8569&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8569&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8569

From michaelm at openjdk.java.net  Mon May  9 12:57:48 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 9 May 2022 12:57:48 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources [v3]
In-Reply-To: <jauKFevs_5ZcXEBlz8vBxkfGG6heVmh2qe9mBIj5F3M=.b449b60a-bb8c-4531-811a-849e8d875022@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
 <jauKFevs_5ZcXEBlz8vBxkfGG6heVmh2qe9mBIj5F3M=.b449b60a-bb8c-4531-811a-849e8d875022@github.com>
Message-ID: <VIvkz0nQjBfRaixEOzoHP4WGi-hrSR1tVrWjvcO5qo4=.69c689d4-28d5-442e-bc1d-c37c91e4a7e7@github.com>

On Mon, 9 May 2022 12:37:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
>> The test is split to test GET and POST separately and avoids testing GET twice.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed @build

LGTM

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

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8569

From dfuchs at openjdk.java.net  Mon May  9 12:57:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 9 May 2022 12:57:50 GMT
Subject: RFR: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources [v2]
In-Reply-To: <2jVr0JK6umyms-MJ3wCGljZL2zU24NS-cQEehV-cKUg=.8254058d-2f51-4bb0-8e1a-bf24680f8332@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
 <TQq9ZYA7TnAQfShXl7zVO6VTTswq8rl2t_zOCn59ulY=.8227e4ba-01f8-4930-a77e-e6a6192e0f1b@github.com>
 <2jVr0JK6umyms-MJ3wCGljZL2zU24NS-cQEehV-cKUg=.8254058d-2f51-4bb0-8e1a-bf24680f8332@github.com>
Message-ID: <sucEppADAplTRf2UeOJZBgpvPg7RQqdBJ7olmLBLvBU=.b6730b6b-5c65-4fa8-b145-531f95c66ce3@github.com>

On Mon, 9 May 2022 11:57:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into ShortResponseBody
>>  - 8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry should use less resources
>
> test/jdk/java/net/httpclient/ShortResponseBodyPost.java line 31:
> 
>> 29:  * @library /test/lib
>> 30:  * @build jdk.test.lib.net.SimpleSSLContext ShortResponseBody ShortResponseBodyGet
>> 31:  * @run testng/othervm
> 
> Seems like the build directive should refer to ShortResponseBodyPost instead of ShortResponseBodyGet

Oh! You're right. Updated.

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

PR: https://git.openjdk.java.net/jdk/pull/8569

From dfuchs at openjdk.java.net  Mon May  9 13:05:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 9 May 2022 13:05:50 GMT
Subject: Integrated: 8286293: Tests ShortResponseBody and
 ShortResponseBodyWithRetry should use less resources
In-Reply-To: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
References: <zB2KO_jGuxcL1dwXiJhfhvnU9w5CgsGRSZuxz3wiO6g=.73179249-938c-4803-8814-cf0e23ffe3fd@github.com>
Message-ID: <taJoK9R18DruyNbK5GzY-YANE98HrflsxOTXkSjnIyc=.313bf825-cd88-43da-9a73-6a96629571e0@github.com>

On Fri, 6 May 2022 11:04:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a simple test fix that re-architecture ShortResponseBody for better resource usage.
> The test is split to test GET and POST separately and avoids testing GET twice.

This pull request has now been integrated.

Changeset: f1433861
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f143386109bce2a2e7241f685e2df26849a0ad48
Stats:     501 lines in 5 files changed: 315 ins; 172 del; 14 mod

8286293: Tests ShortResponseBody and ShortResponseBodyWithRetry should use less resources

Reviewed-by: michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/8569

From dfuchs at openjdk.java.net  Mon May  9 14:01:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 9 May 2022 14:01:04 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v17]
In-Reply-To: <sFd_ifvauzJmleLhNKPPEQ-GmSdnFBPXY2PC3ShRrqM=.439bf96a-231e-4bb5-b9a5-69d60f2b7713@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <sFd_ifvauzJmleLhNKPPEQ-GmSdnFBPXY2PC3ShRrqM=.439bf96a-231e-4bb5-b9a5-69d60f2b7713@github.com>
Message-ID: <PP2RHbSp_NZHfg9AIurtwLp0anEmNEesRNKnPWSZSzk=.2407a981-2b01-4ba2-ba9d-f2a5445c297e@github.com>

On Mon, 9 May 2022 07:52:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge latest from master branch
>  - add a @build to force jtreg to show consistent test results and add the relevant permissions for security manager testing
>  - Change the new API to accept an InetAddress instead of an InetSocketAddress, after inputs from Michael, Daniel and others
>  - Merge latest from master
>  - Implement HttpServerAdapters in test as suggested by Daniel
>  - fix check when security manager is enabled
>  - Add a unit test for the new HttpClient.Builder.localAddress method
>  - Implement Daniel's suggestion - only support InetSocketAddress with port 0
>  - Merge latest from master branch
>  - Merge latest from master branch
>  - ... and 27 more: https://git.openjdk.java.net/jdk/compare/b490a58e...d4a19dea

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/java/net/http/HttpClient.java line 398:

> 396:          *
> 397:          * @implSpec If the {@link #localAddress(InetAddress) local address} is a non-null
> 398:          * <i>Internet Protocol</i> address and a security manager is installed, then

Here and in the @throws bellow we could now remove mention of `<i>Internet Protocol</i>`.
For instance, here we could say 

... is a non-null address and a security ...

src/java.net.http/share/classes/java/net/http/HttpClient.java line 411:

> 409:          *         the {@link #localAddress(InetAddress) local address} is an
> 410:          *         <i>Internet Protocol</i> address and the
> 411:          *         security manager's {@link SecurityManager#checkListen checkListen}

``` 
... has been installed and the security manager's {@link SecurityManager#checkListen checkListen} ...

test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 274:

> 272:         // setting null should work fine
> 273:         builder.localAddress(null);
> 274:         builder.localAddress(InetAddress.getLoopbackAddress());

We probably also need a MockHttpClientBuilder to test the behaviour of the default implementation (check that it throws UOE).

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Tue May 10 12:37:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 12:37:47 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v18]
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Daniel's review suggestion - add a test to verify the behaviour of the localAddress() default method implementation on HttpClient.Builder
 - Daniel's review suggestion - remove reference to "Internet Protocol" in javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6690/files
  - new: https://git.openjdk.java.net/jdk/pull/6690/files/d4a19dea..3a6f2b6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=16-17

  Stats: 74 lines in 2 files changed: 70 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6690.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Tue May 10 12:56:01 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 12:56:01 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v17]
In-Reply-To: <PP2RHbSp_NZHfg9AIurtwLp0anEmNEesRNKnPWSZSzk=.2407a981-2b01-4ba2-ba9d-f2a5445c297e@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <sFd_ifvauzJmleLhNKPPEQ-GmSdnFBPXY2PC3ShRrqM=.439bf96a-231e-4bb5-b9a5-69d60f2b7713@github.com>
 <PP2RHbSp_NZHfg9AIurtwLp0anEmNEesRNKnPWSZSzk=.2407a981-2b01-4ba2-ba9d-f2a5445c297e@github.com>
Message-ID: <I9jPp-m5iCVATcOIB2mOuOqVHBvYtBpPs-js0Jep1A4=.bc6fa1ca-a643-4287-9b92-fcd7bfb43a8a@github.com>

On Mon, 9 May 2022 13:31:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge latest from master branch
>>  - add a @build to force jtreg to show consistent test results and add the relevant permissions for security manager testing
>>  - Change the new API to accept an InetAddress instead of an InetSocketAddress, after inputs from Michael, Daniel and others
>>  - Merge latest from master
>>  - Implement HttpServerAdapters in test as suggested by Daniel
>>  - fix check when security manager is enabled
>>  - Add a unit test for the new HttpClient.Builder.localAddress method
>>  - Implement Daniel's suggestion - only support InetSocketAddress with port 0
>>  - Merge latest from master branch
>>  - Merge latest from master branch
>>  - ... and 27 more: https://git.openjdk.java.net/jdk/compare/b490a58e...d4a19dea
>
> src/java.net.http/share/classes/java/net/http/HttpClient.java line 398:
> 
>> 396:          *
>> 397:          * @implSpec If the {@link #localAddress(InetAddress) local address} is a non-null
>> 398:          * <i>Internet Protocol</i> address and a security manager is installed, then
> 
> Here and in the @throws bellow we could now remove mention of `<i>Internet Protocol</i>`.
> For instance, here we could say 
> 
> ... is a non-null address and a security ...

Done. Updated this and the other javadoc comment to follow this suggestion.

> test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 274:
> 
>> 272:         // setting null should work fine
>> 273:         builder.localAddress(null);
>> 274:         builder.localAddress(InetAddress.getLoopbackAddress());
> 
> We probably also need a MockHttpClientBuilder to test the behaviour of the default implementation (check that it throws UOE).

I've now updated this PR to add a new test method which tests the default method implementation of `localAddress`.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Tue May 10 13:41:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 13:41:49 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v18]
In-Reply-To: <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
Message-ID: <IEsUUe93-eH9LMSemHXAjEjx_qCOKmAMszNWpRW2Yvo=.ca5b5f7b-4a62-4daf-9a72-23cf8629454d@github.com>

On Tue, 10 May 2022 12:37:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Daniel's review suggestion - add a test to verify the behaviour of the localAddress() default method implementation on HttpClient.Builder
>  - Daniel's review suggestion - remove reference to "Internet Protocol" in javadoc

test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 268:

> 266:     /**
> 267:      * Tests the {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} method
> 268:      * behaviour when that method is called on a builder returned by {@link HttpClient#newBuilder()}

/**
  * Tests the {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} method
  ```
  This `{@link` looks broken - the `HttpClient,` prefix probably need to be removed?

test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 283:

> 281:      * Tests that the default method implementation of
> 282:      * {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} throws
> 283:      * an {@link UnsupportedOperationException}

Same remark here

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Tue May 10 13:41:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 13:41:49 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v18]
In-Reply-To: <IEsUUe93-eH9LMSemHXAjEjx_qCOKmAMszNWpRW2Yvo=.ca5b5f7b-4a62-4daf-9a72-23cf8629454d@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
 <IEsUUe93-eH9LMSemHXAjEjx_qCOKmAMszNWpRW2Yvo=.ca5b5f7b-4a62-4daf-9a72-23cf8629454d@github.com>
Message-ID: <F5e3QcwPIivcml0PNPOJYQIkCcpGWBj-ZzrlqkKBTms=.82821c7a-05ad-45e9-a5c2-89867db6607d@github.com>

On Tue, 10 May 2022 13:36:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Daniel's review suggestion - add a test to verify the behaviour of the localAddress() default method implementation on HttpClient.Builder
>>  - Daniel's review suggestion - remove reference to "Internet Protocol" in javadoc
>
> test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 283:
> 
>> 281:      * Tests that the default method implementation of
>> 282:      * {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} throws
>> 283:      * an {@link UnsupportedOperationException}
> 
> Same remark here

Otherwise things look good to me - you should update the CSR if it needs to be updated.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Tue May 10 13:51:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 13:51:37 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

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

  fix javadoc link in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6690/files
  - new: https://git.openjdk.java.net/jdk/pull/6690/files/3a6f2b6b..d9f7b077

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=17-18

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Tue May 10 13:51:38 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 13:51:38 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v18]
In-Reply-To: <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
Message-ID: <fCxGUrcjtGC4YmY63Z0ZBt9aYhRGv_RodCXhbB_l9CY=.c7697d5e-df00-41ce-bb73-3a6a6b98c079@github.com>

On Tue, 10 May 2022 12:37:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Daniel's review suggestion - add a test to verify the behaviour of the localAddress() default method implementation on HttpClient.Builder
>  - Daniel's review suggestion - remove reference to "Internet Protocol" in javadoc

I've triggered some internal CI runs against the current state of PR to see all works fine. Now that we have decided on the nature of this API, I'll go ahead and file a CSR for this.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Tue May 10 13:51:38 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 13:51:38 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v18]
In-Reply-To: <IEsUUe93-eH9LMSemHXAjEjx_qCOKmAMszNWpRW2Yvo=.ca5b5f7b-4a62-4daf-9a72-23cf8629454d@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <iWySmQV0fZcRN3llLAhp6SOnIoTODqJmCRuYDvxJsOI=.285c0289-c16b-401b-b342-aad556da9b23@github.com>
 <IEsUUe93-eH9LMSemHXAjEjx_qCOKmAMszNWpRW2Yvo=.ca5b5f7b-4a62-4daf-9a72-23cf8629454d@github.com>
Message-ID: <LGzHLD_mYDGkC-DeX_H3onZ_wN_Q01c7CueSJp9-pII=.ce54120e-fd1a-43cd-ba81-bf927d24d49d@github.com>

On Tue, 10 May 2022 13:35:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Daniel's review suggestion - add a test to verify the behaviour of the localAddress() default method implementation on HttpClient.Builder
>>  - Daniel's review suggestion - remove reference to "Internet Protocol" in javadoc
>
> test/jdk/java/net/httpclient/HttpClientBuilderTest.java line 268:
> 
>> 266:     /**
>> 267:      * Tests the {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} method
>> 268:      * behaviour when that method is called on a builder returned by {@link HttpClient#newBuilder()}
> 
> /**
>   * Tests the {@link HttpClient,java.net.http.HttpClient.Builder#localAddress(InetAddress)} method
>   ```
>   This `{@link` looks broken - the `HttpClient,` prefix probably need to be removed?

Indeed. That prefix wasn't intentional. I'm not sure how I ended up with that. I just pushed an update to fix this. Thank you for flagging this.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Tue May 10 15:24:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 15:24:02 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
Message-ID: <Z2NpYjvfaGeoIGDrQNyvKqWIb0lDsEEziEDBttxBcZI=.74e964d1-2fd5-40ab-a900-d2df8d0b9ef7@github.com>

On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix javadoc link in test

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6690

From duke at openjdk.java.net  Tue May 10 19:27:50 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 10 May 2022 19:27:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
Message-ID: <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>

On Fri, 6 May 2022 17:56:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
> 
>> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>> 776:             printStackWhenAccessFails = GetBooleanAction.
>> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
> 
> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.

You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From rriggs at openjdk.java.net  Tue May 10 21:38:19 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 21:38:19 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
Message-ID: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>

PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>From the CSR:

"If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."

This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
Since these casts are truncating the value, there might be a different refactoring that avoids the cast
but a direct replacement was chosen here.

(Advise and suggestions will inform similar updates to other OpenJDK modules).

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

Commit messages:
 - 8286378: Address possibly lossy conversions in java.base

Changes: https://git.openjdk.java.net/jdk/pull/8642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286378
  Stats: 57 lines in 33 files changed: 1 ins; 3 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From naoto at openjdk.java.net  Tue May 10 22:02:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 22:02:49 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <zCrdVr1pkcm4Awm7gTH7s6oXP6GeF7Sj9GLgvCnG5tY=.58c9151b-d43a-4c2b-9276-1dcbe603ef05@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Looks good. Assuming copyright years will be updated.

src/java.base/share/classes/java/time/es line 1:

> 1: X

Looks like a random file was added by accident?

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From xuelei at openjdk.java.net  Tue May 10 22:16:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 10 May 2022 22:16:47 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <7lDCcjqL3nlin4_E8rebEkaoQ96_Tz2jbarFVJVF3PY=.88a6da8e-6f79-4889-88f3-4248037609e1@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

The update in security area looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From bpb at openjdk.java.net  Tue May 10 22:57:49 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 10 May 2022 22:57:49 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <7I3Y3hwAO8Sirtab0JkW7SPyjqZlDAhGciKVD47qXOE=.22ddd9bd-1491-4b39-94ed-de1977181c1f@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

IO, math, and NIO changes look fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From rriggs at openjdk.java.net  Tue May 10 23:01:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 23:01:33 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

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

  remove stray file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Tue May 10 23:43:50 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 10 May 2022 23:43:50 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <3fC2CcoKgf_ux4zmAYxkMlZqFTxsp8BShZMjUtXmsl8=.509c28c2-7431-40da-a986-0d2d0957cfb8@github.com>

On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

I don't yet count as a reviewer, but your changes look good to me. You might want to let IntelliJ check for problems before you integrate.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From wetmore at openjdk.java.net  Wed May 11 00:43:48 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 11 May 2022 00:43:48 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>

On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

Finished the SSLEngine/tests, starting on the SSLCipher.  Here's the notes so far.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1:

> 1: /*

Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 51:

> 49: public class ReadOnlyEngine {
> 50: 
> 51:     private static String pathToStores = "../etc";

These 6 can be final if you want.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 96:

> 94:                     status = engine.getHandshakeStatus();
> 95:                     break;
> 96:                 case FINISHED:

Can combine FINISHED/NOT_HANDSHAKING?

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157:

> 155:         // Do TLS handshake
> 156:         do {
> 157:             statusClient = doHandshake(client, out, in);

It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works.  No need to change.

Is this style something you copied from another test?  The  SSLEngineTemplate in the templates directory is what I often use.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 160:

> 158:             statusServer = doHandshake(server, in, out);
> 159:         } while (statusClient != HandshakeStatus.NOT_HANDSHAKING ||
> 160:             statusServer != HandshakeStatus.NOT_HANDSHAKING);

Minor indent problem.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162:

> 160:             statusServer != HandshakeStatus.NOT_HANDSHAKING);
> 161: 
> 162:         // Read NST

What is NST?

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172:

> 170:         out.clear();
> 171:         String testString = "ASDF";
> 172:         in.put(testString.getBytes()).flip();

If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here.

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 188:

> 186:         in.clear();
> 187:         System.out.println("2: Server send: " + testString);
> 188:         in.put(testString.getBytes()).flip();

Same

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 189:

> 187:         System.out.println("2: Server send: " + testString);
> 188:         in.put(testString.getBytes()).flip();
> 189:         send(server, in, out);

Did you want to try asReadOnlyBuffer() here also?

test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 191:

> 189:         send(server, in, out);
> 190:         in.clear();
> 191:         receive(client, out, in);

And here?

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From wetmore at openjdk.java.net  Wed May 11 01:19:52 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 11 May 2022 01:19:52 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <f1QjT_ZvMVzafN1hmKO8OrX1dRO18nP96anp4DMfTj8=.3e0028a9-523d-4c03-aadd-fa528d41fa12@github.com>

On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

All of the comments observed are minor.  

Please consider some of the test changes, but otherwise looks good.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8462

From alanb at openjdk.java.net  Wed May 11 05:26:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 05:26:39 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
Message-ID: <KkBl61XjKZOSpP2maNzaPqPMvLJX_g6gT7wut_06Jq4=.136be44a-5c06-477d-9128-013cd0936574@github.com>

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while we here?

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615:

> 613:         if (outputStackTop >= elements) {
> 614:             outputStackTop -= (short)elements;
> 615:         } else {

I think we usually try to avoid changing the ASM code if possible but maybe you have to do this because the compiler option is used for compiling java.base?

src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123:

> 121:                     // timed poll interrupted so need to adjust timeout
> 122:                     long adjust = System.nanoTime() - startTime;
> 123:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

This one can also be changed to:

`to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);`

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From xuelei at openjdk.java.net  Wed May 11 05:55:38 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 11 May 2022 05:55:38 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <uGKqWvO2uiFe-hV9dGOuqKcXWh1fRVKHk-lBVrb-UH0=.5f717c25-c402-4ce8-8724-4b1bc8f4150f@github.com>

On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677:

> 675:      * @see     #unwrap(ByteBuffer, ByteBuffer[], int, int)
> 676:      *
> 677:      * @implNote The data in {@code src} may be modified during the decryption

It looks like a note for the API users to me.  Is apiNote tag more appropriate here?

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From asotona at openjdk.java.net  Wed May 11 08:06:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 08:06:39 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
Message-ID: <rK40I9ndXoo7IaC7c3WnDFboRAkIjuSRI9nT-fmkSYc=.6ee6adba-88cd-413b-a25e-a9e6a6dd454f@github.com>

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

I can confirm this patch clears all warnings from java.base.

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From michaelm at openjdk.java.net  Wed May 11 08:16:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 11 May 2022 08:16:40 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
Message-ID: <o305R6q0VdXjfI4_nlX4Q1fvyPk-1aQH8Sxs1YBHHu8=.bbc83b49-2427-4854-bf79-1d42b2fb15be@github.com>

On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix javadoc link in test

src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:

> 376:          *
> 377:          * @implSpec The default implementation of this method throws
> 378:          * {@code UnsupportedOperationException}. {@code Builder}s obtained

I think the implSpec here is correct, but will be confusing for most users. I'm not sure what value it adds. Do we really need it?

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Wed May 11 08:57:51 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 08:57:51 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <o305R6q0VdXjfI4_nlX4Q1fvyPk-1aQH8Sxs1YBHHu8=.bbc83b49-2427-4854-bf79-1d42b2fb15be@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
 <o305R6q0VdXjfI4_nlX4Q1fvyPk-1aQH8Sxs1YBHHu8=.bbc83b49-2427-4854-bf79-1d42b2fb15be@github.com>
Message-ID: <YcKpXZOrZRTy04QF8hUSbFgZuLh8ij0vhfN_feuEcGE=.f94bc19d-791e-4ab7-b83b-bf6f4de3edeb@github.com>

On Wed, 11 May 2022 08:12:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix javadoc link in test
>
> src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:
> 
>> 376:          *
>> 377:          * @implSpec The default implementation of this method throws
>> 378:          * {@code UnsupportedOperationException}. {@code Builder}s obtained
> 
> I think the implSpec here is correct, but will be confusing for most users. I'm not sure what value it adds. Do we really need it?

Hello Michael,
Most users will be using the `HttpClient.newBuilder()` to create the builder, so this note about `UnsupportedOperationException` can be confusing. However, for implementations (libraries?) which provide their  own implementation of the `java.net.http.HttpClient.Builder`, I think, this note would be relevant. This approach is similar to what we already have on `java.net.http.HttpClient.newWebSocketBuilder()` method.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From michaelm at openjdk.java.net  Wed May 11 11:37:45 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 11 May 2022 11:37:45 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <YcKpXZOrZRTy04QF8hUSbFgZuLh8ij0vhfN_feuEcGE=.f94bc19d-791e-4ab7-b83b-bf6f4de3edeb@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
 <o305R6q0VdXjfI4_nlX4Q1fvyPk-1aQH8Sxs1YBHHu8=.bbc83b49-2427-4854-bf79-1d42b2fb15be@github.com>
 <YcKpXZOrZRTy04QF8hUSbFgZuLh8ij0vhfN_feuEcGE=.f94bc19d-791e-4ab7-b83b-bf6f4de3edeb@github.com>
Message-ID: <P-eelxXDMz10NQT83IVqSemXYQ_KeHCIjVdDSMYPTYY=.fd2e4866-d7b6-46d3-b371-e63111a3fc98@github.com>

On Wed, 11 May 2022 08:54:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:
>> 
>>> 376:          *
>>> 377:          * @implSpec The default implementation of this method throws
>>> 378:          * {@code UnsupportedOperationException}. {@code Builder}s obtained
>> 
>> I think the implSpec here is correct, but will be confusing for most users. I'm not sure what value it adds. Do we really need it?
>
> Hello Michael,
> Most users will be using the `HttpClient.newBuilder()` to create the builder, so this note about `UnsupportedOperationException` can be confusing. However, for implementations (libraries?) which provide their  own implementation of the `java.net.http.HttpClient.Builder`, I think, this note would be relevant. This approach is similar to what we already have on `java.net.http.HttpClient.newWebSocketBuilder()` method.

Sure, I just think when most developers read "The default implementation of this method throws UOE" they will think they can't use it without implementing something themselves. Library developers will figure it out anyway.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Wed May 11 12:18:58 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 12:18:58 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
Message-ID: <HyR5qnJh9ZCFP1HODjV9RUXpvGE6YzznzJ7KbQSdMXw=.70c4b164-39cc-445e-8d0b-8aa5522ce9b3@github.com>

On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix javadoc link in test

I've now created a CSR for this change https://bugs.openjdk.java.net/browse/JDK-8286583

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Wed May 11 12:19:00 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 12:19:00 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v19]
In-Reply-To: <P-eelxXDMz10NQT83IVqSemXYQ_KeHCIjVdDSMYPTYY=.fd2e4866-d7b6-46d3-b371-e63111a3fc98@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <7jbvm4fb_iZlE-y-BnP4SSnirDLk9lvk5BxTcFgBXEA=.8d6a6e1a-347d-40e7-9259-a5635d20a838@github.com>
 <o305R6q0VdXjfI4_nlX4Q1fvyPk-1aQH8Sxs1YBHHu8=.bbc83b49-2427-4854-bf79-1d42b2fb15be@github.com>
 <YcKpXZOrZRTy04QF8hUSbFgZuLh8ij0vhfN_feuEcGE=.f94bc19d-791e-4ab7-b83b-bf6f4de3edeb@github.com>
 <P-eelxXDMz10NQT83IVqSemXYQ_KeHCIjVdDSMYPTYY=.fd2e4866-d7b6-46d3-b371-e63111a3fc98@github.com>
Message-ID: <9qqmhE8jJHA-S0NnOgELPEr_4L67QFD_bvww0o59_1U=.beb71d02-3715-4e79-bf3f-69eafa4c8033@github.com>

On Wed, 11 May 2022 11:34:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hello Michael,
>> Most users will be using the `HttpClient.newBuilder()` to create the builder, so this note about `UnsupportedOperationException` can be confusing. However, for implementations (libraries?) which provide their  own implementation of the `java.net.http.HttpClient.Builder`, I think, this note would be relevant. This approach is similar to what we already have on `java.net.http.HttpClient.newWebSocketBuilder()` method.
>
> Sure, I just think when most developers read "The default implementation of this method throws UOE" they will think they can't use it without implementing something themselves. Library developers will figure it out anyway.

This is the standard wording that has been used throughout the JDK to document the behavior of default methods on interfaces. Unless we receive different feedback during the CSR review I'd suggest to leave it that way. The second sentence makes it clear that our concrete implementations override that default behavior.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Wed May 11 15:50:15 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 15:50:15 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
Message-ID: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>

In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

Commit messages:
 - Fix comments
 - 8286386: Address possibly lossy conversions in java.net.http

Changes: https://git.openjdk.java.net/jdk/pull/8656/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286386
  Stats: 27 lines in 3 files changed: 15 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 15:50:15 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 15:50:15 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <ojrN40JjSBSx484otAzKsMhmFVIZgQeIszqZJPWQk2M=.53e4fa28-7d47-4634-a240-466744d90c70@github.com>

On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

@pavelrappo I would appreciate if you could review these changes

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Wed May 11 16:30:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 16:30:41 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

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

  Updated copyrights
  Fixed cast style to add a space after cast, (where consistent with file style)
  Improved code per review comments in PollSelectors.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/7ff806a5..a6679ce7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01-02

  Stats: 41 lines in 24 files changed: 0 ins; 0 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From michaelm at openjdk.java.net  Wed May 11 16:58:56 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 11 May 2022 16:58:56 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>

On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java line 739:

> 737:                         buffer |= (codeValueOf(c) >>> bufferLen); // append
> 738:                         bufferLen += (int) len;
> 739:                         pos++;

Would it be cleaner to do the cast in the codeLengthOf method, so it returns an int?

src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 222:

> 220:                 // compiler will emit a warning if not cast
> 221:                 firstChar &= (char) ~0b10000000_00000000;
> 222:             }

Am I right in believing that there was an implicit cast to char here before and the only change is to make it explicit? ie. there is no actual behavior change?

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 17:08:00 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 17:08:00 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
Message-ID: <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>

On Wed, 11 May 2022 16:55:16 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 222:
> 
>> 220:                 // compiler will emit a warning if not cast
>> 221:                 firstChar &= (char) ~0b10000000_00000000;
>> 222:             }
> 
> Am I right in believing that there was an implicit cast to char here before and the only change is to make it explicit? ie. there is no actual behavior change?

Yes - that's my understanding.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From bpb at openjdk.java.net  Wed May 11 17:11:46 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 17:11:46 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <M8J7eiMXE_ic0gKwIkiKrfJ-F-CYmnfhm9Naq1Q20aM=.d19d5079-b6cd-41b4-92ad-9e1ac06d3009@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From dfuchs at openjdk.java.net  Wed May 11 17:13:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 17:13:47 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
Message-ID: <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>

On Wed, 11 May 2022 16:52:07 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java line 739:
> 
>> 737:                         buffer |= (codeValueOf(c) >>> bufferLen); // append
>> 738:                         bufferLen += (int) len;
>> 739:                         pos++;
> 
> Would it be cleaner to do the cast in the codeLengthOf method, so it returns an int?

I believe the method returns an "unsigned int" - having the method return an int would then potentially cause `bufferLen + len <= 64` to yield true when it shouldn't. Hopefully @pavelrappo will comment.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Wed May 11 17:40:45 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 17:40:45 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
Message-ID: <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>

On Wed, 11 May 2022 17:04:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 222:
>> 
>>> 220:                 // compiler will emit a warning if not cast
>>> 221:                 firstChar &= (char) ~0b10000000_00000000;
>>> 222:             }
>> 
>> Am I right in believing that there was an implicit cast to char here before and the only change is to make it explicit? ie. there is no actual behavior change?
>
> Yes - that's my understanding.

These methods either set or clear a single bit in `firstChar`.
The constant is an `int` so its complement is a 32 bit int.

It could also be written as `~ (char) 0b1000000_0000000`.   Then the 16 bit unsigned char would be complemented.
Either way, the cast is needed to be explicit about the size of the constant.

Another way to avoid the cast would be to define the bit positions as:

`private static final char FIN_BIT = 0b10000000_00000000;
... etc.
`
Then the code in the methods would not need the cast.


    if (value) { 
        firstChar |= FIN_BIT;
    } else {
        firstChar &= ~FIN_BIT;
    }

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 17:52:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 17:52:51 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
Message-ID: <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>

On Wed, 11 May 2022 17:37:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes - that's my understanding.
>
> These methods either set or clear a single bit in `firstChar`.
> The constant is an `int` so its complement is a 32 bit int.
> 
> It could also be written as `~ (char) 0b1000000_0000000`.   Then the 16 bit unsigned char would be complemented.
> Either way, the cast is needed to be explicit about the size of the constant.
> 
> Another way to avoid the cast would be to define the bit positions as:
> 
> `private static final char FIN_BIT = 0b10000000_00000000;
> ... etc.
> `
> Then the code in the methods would not need the cast.
> 
> 
>     if (value) { 
>         firstChar |= FIN_BIT;
>     } else {
>         firstChar &= ~FIN_BIT;
>     }

Ah! Good point. Maybe I should use a constant and get rid of the cast.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Wed May 11 17:52:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 17:52:52 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
In-Reply-To: <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
Message-ID: <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>

On Wed, 11 May 2022 17:46:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> These methods either set or clear a single bit in `firstChar`.
>> The constant is an `int` so its complement is a 32 bit int.
>> 
>> It could also be written as `~ (char) 0b1000000_0000000`.   Then the 16 bit unsigned char would be complemented.
>> Either way, the cast is needed to be explicit about the size of the constant.
>> 
>> Another way to avoid the cast would be to define the bit positions as:
>> 
>> `private static final char FIN_BIT = 0b10000000_00000000;
>> ... etc.
>> `
>> Then the code in the methods would not need the cast.
>> 
>> 
>>     if (value) { 
>>         firstChar |= FIN_BIT;
>>     } else {
>>         firstChar &= ~FIN_BIT;
>>     }
>
> Ah! Good point. Maybe I should use a constant and get rid of the cast.

?? I'd put `_MASK` in the name along with whatever name is used for the bits in the frame spec .

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:05:42 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:05:42 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v2]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <xihPd1IeuL6va0x41_bXw2S-o6OmExGuU7rfwgn01uo=.d3f52cba-b9b2-4fb0-8e21-40ed3297a330@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Use char constant to avoid casts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/6ef906e0..bbcf238b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=00-01

  Stats: 29 lines in 1 file changed: 5 ins; 15 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Wed May 11 18:05:42 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 18:05:42 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v2]
In-Reply-To: <xihPd1IeuL6va0x41_bXw2S-o6OmExGuU7rfwgn01uo=.d3f52cba-b9b2-4fb0-8e21-40ed3297a330@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <xihPd1IeuL6va0x41_bXw2S-o6OmExGuU7rfwgn01uo=.d3f52cba-b9b2-4fb0-8e21-40ed3297a330@github.com>
Message-ID: <oae-4_hOhePE5ygsTu99aPZuRsvfogpiBdeHvnPRGmE=.92fa67d9-3734-4301-b1bd-16293fa613af@github.com>

On Wed, 11 May 2022 18:02:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use char constant to avoid casts

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:05:42 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:05:42 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v2]
In-Reply-To: <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
 <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
Message-ID: <8yv9kQ3DyBV6y-B32wVT0kL0DbsEXefayZzhn7OWe6c=.92f6efa9-2a49-4737-b134-3ea9be353c64@github.com>

On Wed, 11 May 2022 17:49:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ah! Good point. Maybe I should use a constant and get rid of the cast.
>
> ?? I'd put `_MASK` in the name along with whatever name is used for the bits in the frame spec .

Done

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:17:24 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:17:24 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v3]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <Acf8Ah-yZtGJzBBcnzwAL11KzuyJGnobz1K-9jOPElU=.74154696-b0b7-452e-a366-96f77bb0d83e@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Add _MASK suffix to char constants

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/bbcf238b..ec344eef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:31:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:31:02 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v3]
In-Reply-To: <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
 <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
Message-ID: <kgAHLKzqx12fpAu7UTTu6_sud17PEekQVAviuAEpxDw=.78d35174-52c7-4a91-8260-79f725d40afa@github.com>

On Wed, 11 May 2022 17:49:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ah! Good point. Maybe I should use a constant and get rid of the cast.
>
> ?? I'd put `_MASK` in the name along with whatever name is used for the bits in the frame spec .

@RogerRiggs Actually - I'm no longer sure that this will work:


jshell> char x = 0b10000000_00000000
x ==> '?'

jshell> var y = ~x
y ==> -32769

jshell> char y = ~x
|  Error:
|  incompatible types: possible lossy conversion from int to char
|  char y = ~x;
|           ^^

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:31:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:31:02 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v3]
In-Reply-To: <kgAHLKzqx12fpAu7UTTu6_sud17PEekQVAviuAEpxDw=.78d35174-52c7-4a91-8260-79f725d40afa@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
 <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
 <kgAHLKzqx12fpAu7UTTu6_sud17PEekQVAviuAEpxDw=.78d35174-52c7-4a91-8260-79f725d40afa@github.com>
Message-ID: <Zf0AiLkt3Vd4flsjyNdsQG2yeZkR2bB1iVJ1SJdV6AQ=.1b102671-4a0e-402d-a703-d00268daafc8@github.com>

On Wed, 11 May 2022 18:23:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> ?? I'd put `_MASK` in the name along with whatever name is used for the bits in the frame spec .
>
> @RogerRiggs Actually - I'm no longer sure that this will work:
> 
> 
> jshell> char x = 0b10000000_00000000
> x ==> '?'
> 
> jshell> var y = ~x
> y ==> -32769
> 
> jshell> char y = ~x
> |  Error:
> |  incompatible types: possible lossy conversion from int to char
> |  char y = ~x;
> |           ^^

So if x is a char, ~x seems to be an int :-(

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:37:39 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:37:39 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v4]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <QW3q4_ZxSQESWv3ocYsb8Q3Zq99sRXMGa5tJCy3a96c=.263a14d3-6bde-4d71-9cb6-29ebec625c71@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Revert adding char constants

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/ec344eef..fbf3c9a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=02-03

  Stats: 29 lines in 1 file changed: 15 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:37:40 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:37:40 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v4]
In-Reply-To: <Zf0AiLkt3Vd4flsjyNdsQG2yeZkR2bB1iVJ1SJdV6AQ=.1b102671-4a0e-402d-a703-d00268daafc8@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
 <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
 <kgAHLKzqx12fpAu7UTTu6_sud17PEekQVAviuAEpxDw=.78d35174-52c7-4a91-8260-79f725d40afa@github.com>
 <Zf0AiLkt3Vd4flsjyNdsQG2yeZkR2bB1iVJ1SJdV6AQ=.1b102671-4a0e-402d-a703-d00268daafc8@github.com>
Message-ID: <-RBDvW76tAiEXVWLGl9p1gxbE0JX38bRAmYS8PfB0MQ=.aac8c78f-2073-4eb3-8c16-6a20cf16068e@github.com>

On Wed, 11 May 2022 18:25:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @RogerRiggs Actually - I'm no longer sure that this will work:
>> 
>> 
>> jshell> char x = 0b10000000_00000000
>> x ==> '?'
>> 
>> jshell> var y = ~x
>> y ==> -32769
>> 
>> jshell> char y = ~x
>> |  Error:
>> |  incompatible types: possible lossy conversion from int to char
>> |  char y = ~x;
>> |           ^^
>
> So if x is a char, ~x seems to be an int :-(

I have reverted adding constant fields. Too bad - the casts are back.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Wed May 11 18:42:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 May 2022 18:42:46 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <ersf3va5rN2ez7rVs4tQBht10rY1DySOoEmzArKS-2I=.55a9b0d8-8641-49fb-9e2d-13a384c9ff05@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Revert adding char constants

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/fbf3c9a1..2334b747

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Wed May 11 18:53:54 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 18:53:54 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <-RBDvW76tAiEXVWLGl9p1gxbE0JX38bRAmYS8PfB0MQ=.aac8c78f-2073-4eb3-8c16-6a20cf16068e@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <PWHJZ6l29Qp1xybncKPKhN75B5VC3NwKL-s2L0rpu4w=.a1726593-d73a-4205-8c5f-e4552a2af28a@github.com>
 <Kt9Lel0uT41L7x106WaKRVb76f2C4OuIpqQHuLNDXSA=.0597f889-23a0-45af-871a-697011b5dd83@github.com>
 <EbphlNY8dQWsZYMDupf9aMFZv5GVfwRaW9tflf1Gs8I=.42f85e2b-7fb7-437c-befd-91c3ae92b4a6@github.com>
 <6YwRec6HY019oJx-PBiM8vjzDArF-ypFq0ysoDnxqiw=.39751dde-4288-4dd5-9f95-37567c263644@github.com>
 <kgAHLKzqx12fpAu7UTTu6_sud17PEekQVAviuAEpxDw=.78d35174-52c7-4a91-8260-79f725d40afa@github.com>
 <Zf0AiLkt3Vd4flsjyNdsQG2yeZkR2bB1iVJ1SJdV6AQ=.1b102671-4a0e-402d-a703-d00268daafc8@github.com>
 <-RBDvW76tAiEXVWLGl9p1gxbE0JX38bRAmYS8PfB0MQ=.aac8c78f-2073-4eb3-8c16-6a20cf16068e@github.com>
Message-ID: <jz5A0eOVloR6UYP2_Wb_EgbGxjsR2o8utUKqWiuWdMU=.b55f9cec-2da1-4e6c-9666-8f837aa2f294@github.com>

On Wed, 11 May 2022 18:33:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> So if x is a char, ~x seems to be an int :-(
>
> I have reverted adding constant fields. Too bad - the casts are back.

Phooey:  Sorry to have lead you astray.  :(
And casting before `~` does the same not wanted result.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From alanb at openjdk.java.net  Wed May 11 19:10:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 19:10:45 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <FVhsC0KYqrXqSWOt69MdFgvJZjIgrMc2LTVGsam2aDY=.1c3e2519-be3e-462d-a6a0-627e45c02c12@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From michaelm at openjdk.java.net  Wed May 11 20:34:42 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 11 May 2022 20:34:42 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
Message-ID: <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>

On Wed, 11 May 2022 17:10:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java line 739:
>> 
>>> 737:                         buffer |= (codeValueOf(c) >>> bufferLen); // append
>>> 738:                         bufferLen += (int) len;
>>> 739:                         pos++;
>> 
>> Would it be cleaner to do the cast in the codeLengthOf method, so it returns an int?
>
> I believe the method returns an "unsigned int" - having the method return an int would then potentially cause `bufferLen + len <= 64` to yield true when it shouldn't. Hopefully @pavelrappo will comment.

codeLengthOf() returns long. It could be changed to return int with a cast internally and then you could avoid the two new casts.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From ascarpino at openjdk.java.net  Wed May 11 22:28:56 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 11 May 2022 22:28:56 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
Message-ID: <lmFEoQtVXIFLJSs_aDtdYVpsjsO5CguBG2HDts471fo=.83e6b958-cfa0-412e-a15a-9866badb3067@github.com>

On Mon, 9 May 2022 23:15:40 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1:
> 
>> 1: /*
> 
> Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher.

I can move it.. I created it from another test which happen to be in that directory

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From ascarpino at openjdk.java.net  Wed May 11 22:41:47 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 11 May 2022 22:41:47 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
Message-ID: <GDlWyHWTAQJd3zp1ipR5CBBwoswIFkEp23BU1YHLqdI=.9974ccac-6dc9-4748-9d33-f980d6ff6f75@github.com>

On Mon, 9 May 2022 23:48:24 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157:
> 
>> 155:         // Do TLS handshake
>> 156:         do {
>> 157:             statusClient = doHandshake(client, out, in);
> 
> It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works.  No need to change.
> 
> Is this style something you copied from another test?  The  SSLEngineTemplate in the templates directory is what I often use.

I got it from somewhere that I don't remember off hand.  I'm just trying to get through the handshake.

> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162:
> 
>> 160:             statusServer != HandshakeStatus.NOT_HANDSHAKING);
>> 161: 
>> 162:         // Read NST
> 
> What is NST?

New Session Ticket

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From ascarpino at openjdk.java.net  Wed May 11 22:52:50 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 11 May 2022 22:52:50 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <uGKqWvO2uiFe-hV9dGOuqKcXWh1fRVKHk-lBVrb-UH0=.5f717c25-c402-4ce8-8724-4b1bc8f4150f@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <uGKqWvO2uiFe-hV9dGOuqKcXWh1fRVKHk-lBVrb-UH0=.5f717c25-c402-4ce8-8724-4b1bc8f4150f@github.com>
Message-ID: <rt-xNXC9muWJS8iZkpVAgb83kZxwuGyZrZqt5Lf7iEY=.685990d0-7552-4d73-bb3c-ea96c5120ae0@github.com>

On Wed, 11 May 2022 05:52:38 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677:
> 
>> 675:      * @see     #unwrap(ByteBuffer, ByteBuffer[], int, int)
>> 676:      *
>> 677:      * @implNote The data in {@code src} may be modified during the decryption
> 
> It looks like a note for the API users to me.  Is apiNote tag more appropriate here?

The CSR and this code is changing, the note I was adding was already documented, but its existing wording should be more clear.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From ascarpino at openjdk.java.net  Wed May 11 23:07:40 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 11 May 2022 23:07:40 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
Message-ID: <G8pEYv3opmQS6oiF7MBwoZrhSqpKlIO9CdkExbYNhSo=.f40918d2-8701-481b-b2bd-306acf60a95d@github.com>

On Wed, 11 May 2022 00:31:23 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172:
> 
>> 170:         out.clear();
>> 171:         String testString = "ASDF";
>> 172:         in.put(testString.getBytes()).flip();
> 
> If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here.

setting the input to UTF8 isn't a concern.  The latter line to decode it changes it from using the ByteBuffer.toString() to the contents of the ByteBuffer in a String.

> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 188:
> 
>> 186:         in.clear();
>> 187:         System.out.println("2: Server send: " + testString);
>> 188:         in.put(testString.getBytes()).flip();
> 
> Same

Same :)

> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 189:
> 
>> 187:         System.out.println("2: Server send: " + testString);
>> 188:         in.put(testString.getBytes()).flip();
>> 189:         send(server, in, out);
> 
> Did you want to try asReadOnlyBuffer() here also?

Yeah, they should have been.  I must have undid it to test something

> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 191:
> 
>> 189:         send(server, in, out);
>> 190:         in.clear();
>> 191:         receive(client, out, in);
> 
> And here?

Same

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From xuelei at openjdk.java.net  Thu May 12 04:40:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 12 May 2022 04:40:49 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <rt-xNXC9muWJS8iZkpVAgb83kZxwuGyZrZqt5Lf7iEY=.685990d0-7552-4d73-bb3c-ea96c5120ae0@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <uGKqWvO2uiFe-hV9dGOuqKcXWh1fRVKHk-lBVrb-UH0=.5f717c25-c402-4ce8-8724-4b1bc8f4150f@github.com>
 <rt-xNXC9muWJS8iZkpVAgb83kZxwuGyZrZqt5Lf7iEY=.685990d0-7552-4d73-bb3c-ea96c5120ae0@github.com>
Message-ID: <6oUg2vg_n11wCSlyvzZZtPj8iVTGByT9bMRvYT2wt-o=.2f57f210-0bed-45ab-a5d3-89364496a396@github.com>

On Wed, 11 May 2022 22:49:02 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677:
>> 
>>> 675:      * @see     #unwrap(ByteBuffer, ByteBuffer[], int, int)
>>> 676:      *
>>> 677:      * @implNote The data in {@code src} may be modified during the decryption
>> 
>> It looks like a note for the API users to me.  Is apiNote tag more appropriate here?
>
> The CSR and this code is changing, the note I was adding was already documented, but its existing wording should be more clear.

I like the new update as specified in the CSR.  I added my name as Reviewer for the CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From dfuchs at openjdk.java.net  Thu May 12 08:45:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 08:45:51 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
Message-ID: <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>

On Wed, 11 May 2022 20:31:00 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I believe the method returns an "unsigned int" - having the method return an int would then potentially cause `bufferLen + len <= 64` to yield true when it shouldn't. Hopefully @pavelrappo will comment.
>
> codeLengthOf() returns long. It could be changed to return int with a cast internally and then you could avoid the two new casts.

No because the int returned could be negative, while the long will not. Assuming bufferLen is 0 and codeLengthOf() returns some value that has the 32th bit set to 1 then when codeLengthOf() returns long, bufferLen + codeLengthOf() will be a positive long > 64, and we won't enter the `if` here but if codeLengthOf() returns `int`, then bufferLen + codeLengthOf() would be negative and the `if` would be wrongly entered. I am not 100% sure this is a scenario that might occur (codeLengthOf() returning large "unsigned int" values) - but I'd prefer to stay on the safe side and assume that it can.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 09:03:53 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 09:03:53 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
Message-ID: <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>

On Thu, 12 May 2022 08:42:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> codeLengthOf() returns long. It could be changed to return int with a cast internally and then you could avoid the two new casts.
>
> No because the int returned could be negative, while the long will not. Assuming bufferLen is 0 and codeLengthOf() returns some value that has the 32th bit set to 1 then when codeLengthOf() returns long, bufferLen + codeLengthOf() will be a positive long > 64, and we won't enter the `if` here but if codeLengthOf() returns `int`, then bufferLen + codeLengthOf() would be negative and the `if` would be wrongly entered. I am not 100% sure this is a scenario that might occur (codeLengthOf() returning large "unsigned int" values) - but I'd prefer to stay on the safe side and assume that it can.

This is what I mean:

jshell> long codeLengthOf = (long)Integer.MAX_VALUE + 1
codeLengthOf ==> 2147483648

jshell> int bufferLen = 0
bufferLen ==> 0

jshell> bufferLen + codeLengthOf <= 64
$3 ==> false

jshell> bufferLen + (int)codeLengthOf <= 64
$4 ==> true

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 09:03:54 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 09:03:54 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
 <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
Message-ID: <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>

On Thu, 12 May 2022 08:56:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> No because the int returned could be negative, while the long will not. Assuming bufferLen is 0 and codeLengthOf() returns some value that has the 32th bit set to 1 then when codeLengthOf() returns long, bufferLen + codeLengthOf() will be a positive long > 64, and we won't enter the `if` here but if codeLengthOf() returns `int`, then bufferLen + codeLengthOf() would be negative and the `if` would be wrongly entered. I am not 100% sure this is a scenario that might occur (codeLengthOf() returning large "unsigned int" values) - but I'd prefer to stay on the safe side and assume that it can.
>
> This is what I mean:
> 
> jshell> long codeLengthOf = (long)Integer.MAX_VALUE + 1
> codeLengthOf ==> 2147483648
> 
> jshell> int bufferLen = 0
> bufferLen ==> 0
> 
> jshell> bufferLen + codeLengthOf <= 64
> $3 ==> false
> 
> jshell> bufferLen + (int)codeLengthOf <= 64
> $4 ==> true

Yes, inserting explicit casts seems less clean than changing `codeLengthOf` to this:

    private static int codeLengthOf(char c) {
        return (int) (codes[c] & 0x00000000ffffffffL);
    }

There are 256 elements in constant `long[] codes`. One could easily check that each element when ANDed with `0x00000000ffffffffL` results in a value that fits into the first 31 bits of `int`.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 09:19:59 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 09:19:59 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <ersf3va5rN2ez7rVs4tQBht10rY1DySOoEmzArKS-2I=.55a9b0d8-8641-49fb-9e2d-13a384c9ff05@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <ersf3va5rN2ez7rVs4tQBht10rY1DySOoEmzArKS-2I=.55a9b0d8-8641-49fb-9e2d-13a384c9ff05@github.com>
Message-ID: <1TdgMhWr8LbUCa8EDfmF9RqYRRk7r9qqufh34Uy8khE=.c56fe496-a86b-4078-a2ef-97f86798c8e8@github.com>

On Wed, 11 May 2022 18:42:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert adding char constants

src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 291:

> 289: 
> 290:         HeaderWriter noMask() {
> 291:             // The negation "~" sets the high order bits

Rubber-stamping this in front of every of the four closely sitting casts seems excessive:

                // The negation "~" sets the high order bits
                // so the value is more than 16 bits and the
                // compiler will emit a warning if not cast

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 10:12:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 10:12:07 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
 <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
 <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>
Message-ID: <QKHvsBX6GN6dwVWxHvN3dnniRpwrXKT8ET0rDQ1gqsI=.d3fd4ec3-7e1f-4199-9f8c-c06df26b6f01@github.com>

On Thu, 12 May 2022 09:00:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This is what I mean:
>> 
>> jshell> long codeLengthOf = (long)Integer.MAX_VALUE + 1
>> codeLengthOf ==> 2147483648
>> 
>> jshell> int bufferLen = 0
>> bufferLen ==> 0
>> 
>> jshell> bufferLen + codeLengthOf <= 64
>> $3 ==> false
>> 
>> jshell> bufferLen + (int)codeLengthOf <= 64
>> $4 ==> true
>
> Yes, inserting explicit casts seems less clean than changing `codeLengthOf` to this:
> 
>     private static int codeLengthOf(char c) {
>         return (int) (codes[c] & 0x00000000ffffffffL);
>     }
> 
> There are 256 elements in constant `long[] codes`. One could easily check that each element when ANDed with `0x00000000ffffffffL` results in a value that fits into the first 31 bits of `int`.

OK -  I will change codeLengthOf as suggested. It was not immediately obvious to me that the values would fit in the first 31 bits.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 10:12:09 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 10:12:09 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <1TdgMhWr8LbUCa8EDfmF9RqYRRk7r9qqufh34Uy8khE=.c56fe496-a86b-4078-a2ef-97f86798c8e8@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <ersf3va5rN2ez7rVs4tQBht10rY1DySOoEmzArKS-2I=.55a9b0d8-8641-49fb-9e2d-13a384c9ff05@github.com>
 <1TdgMhWr8LbUCa8EDfmF9RqYRRk7r9qqufh34Uy8khE=.c56fe496-a86b-4078-a2ef-97f86798c8e8@github.com>
Message-ID: <C6GZzMs6H2ChMJZYTPkyheGjequH7pIcSDRdXOwO5lE=.1b43ee6b-854f-488c-b673-d216f02ecabe@github.com>

On Thu, 12 May 2022 09:15:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert adding char constants
>
> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 291:
> 
>> 289: 
>> 290:         HeaderWriter noMask() {
>> 291:             // The negation "~" sets the high order bits
> 
> Rubber-stamping this in front of every of the four closely sitting casts seems excessive:
> 
>                 // The negation "~" sets the high order bits
>                 // so the value is more than 16 bits and the
>                 // compiler will emit a warning if not cast

I don't disagree. I had the same feeling. But I don't necessarily read a file from top to bottom - and someone just glancing at one of these methods might wonder why one line has the cast and the other hasn't.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 10:51:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 10:51:04 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v6]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <Rk1vPqEeuI5X32tPzj1uuQKlCo4BAoeYfOv_a8Ifghs=.e4739943-4d2f-4e28-95e9-7d738b66409e@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  lengthOfCode() returns int; Removed excessive comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/2334b747..deb22998

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=04-05

  Stats: 16 lines in 2 files changed: 2 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 11:34:56 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 11:34:56 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v6]
In-Reply-To: <Rk1vPqEeuI5X32tPzj1uuQKlCo4BAoeYfOv_a8Ifghs=.e4739943-4d2f-4e28-95e9-7d738b66409e@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <Rk1vPqEeuI5X32tPzj1uuQKlCo4BAoeYfOv_a8Ifghs=.e4739943-4d2f-4e28-95e9-7d738b66409e@github.com>
Message-ID: <fulXZfZy9ZXMyOhtXHOVY86xrhhekcmrCoyG89kX7Is=.9ee77eb7-c719-408c-a29c-12ea8f1dae0e@github.com>

On Thu, 12 May 2022 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lengthOfCode() returns int; Removed excessive comments

src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java line 736:

> 734:                     }
> 735:                     int len = codeLengthOf(c);
> 736:                     assert len >= 0;

This `assert` could be better if placed into `codeLengthOf`, which is called from one more place.

src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 220:

> 218:                 // Explicit cast required:
> 219:                 // The negation "~" sets the high order bits
> 220:                 // so the value is more than 16 bits and the

Consider using: the value *becomes longer* than 16 bits

src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 287:

> 285:         HeaderWriter noMask() {
> 286:             // The negation "~" sets the high order bits
> 287:             // so the value is more than 16 bits and the

Again, consider: *becomes longer*

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 11:34:59 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 11:34:59 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v5]
In-Reply-To: <C6GZzMs6H2ChMJZYTPkyheGjequH7pIcSDRdXOwO5lE=.1b43ee6b-854f-488c-b673-d216f02ecabe@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <ersf3va5rN2ez7rVs4tQBht10rY1DySOoEmzArKS-2I=.55a9b0d8-8641-49fb-9e2d-13a384c9ff05@github.com>
 <1TdgMhWr8LbUCa8EDfmF9RqYRRk7r9qqufh34Uy8khE=.c56fe496-a86b-4078-a2ef-97f86798c8e8@github.com>
 <C6GZzMs6H2ChMJZYTPkyheGjequH7pIcSDRdXOwO5lE=.1b43ee6b-854f-488c-b673-d216f02ecabe@github.com>
Message-ID: <3fPESJjlOOAHkPvVKIHKdXSw2rnj74hulLRB6ZsyQzY=.d759a085-8cc6-4997-89d2-576ff1591cf2@github.com>

On Thu, 12 May 2022 10:08:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 291:
>> 
>>> 289: 
>>> 290:         HeaderWriter noMask() {
>>> 291:             // The negation "~" sets the high order bits
>> 
>> Rubber-stamping this in front of every of the four closely sitting casts seems excessive:
>> 
>>                 // The negation "~" sets the high order bits
>>                 // so the value is more than 16 bits and the
>>                 // compiler will emit a warning if not cast
>
> I don't disagree. I had the same feeling. But I don't necessarily read a file from top to bottom - and someone just glancing at one of these methods might wonder why one line has the cast and the other hasn't.

Readers should always consider as much of the context as practical; but I like your solution.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 11:43:08 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 11:43:08 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v6]
In-Reply-To: <QKHvsBX6GN6dwVWxHvN3dnniRpwrXKT8ET0rDQ1gqsI=.d3fd4ec3-7e1f-4199-9f8c-c06df26b6f01@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
 <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
 <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>
 <QKHvsBX6GN6dwVWxHvN3dnniRpwrXKT8ET0rDQ1gqsI=.d3fd4ec3-7e1f-4199-9f8c-c06df26b6f01@github.com>
Message-ID: <1calWONAo_1JKW4RUjTHVZx7wx82lX5DdlzP-Es3di0=.16e57f8e-4634-4ee8-8a70-feb2d8e38f0c@github.com>

On Thu, 12 May 2022 10:05:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> OK - I will change codeLengthOf as suggested. It was not immediately obvious to me that the values would fit in the first 31 bits.

In fact, it would even fit into the first 30 bits. There's a top-level comment that explains the layout of `code` elements. Maybe you can improve it somehow or carry over that specific part about the length into `codeLengthOf`. Alternatively, you can always slap `assert` in `codeLengthOf`.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From ccleary at openjdk.java.net  Thu May 12 11:54:55 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 12 May 2022 11:54:55 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v3]
In-Reply-To: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
Message-ID: <rh8UUzemmjXYnjjXRM-UrHPU6lCEJTTMPjIqs1-YO6M=.9ca962c0-07bc-48b5-9253-f7a515500f69@github.com>

> **Issue**
> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
> 
> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
> 
> **Proposed Solution**
> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
> 
> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

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

  8284585: Added test case to verify fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8518/files
  - new: https://git.openjdk.java.net/jdk/pull/8518/files/24e702a8..64fa937f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8518&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8518&range=01-02

  Stats: 81 lines in 3 files changed: 58 ins; 9 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8518/head:pull/8518

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Thu May 12 11:54:56 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 12 May 2022 11:54:56 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v2]
In-Reply-To: <yGFjIK_DukudwIXrRx5HMWYleP7zAG76yCW9JU9J5J8=.a892bdf6-d961-4b30-b691-b9ad4c0c88ac@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <yGFjIK_DukudwIXrRx5HMWYleP7zAG76yCW9JU9J5J8=.a892bdf6-d961-4b30-b691-b9ad4c0c88ac@github.com>
Message-ID: <qiGsVtHTjC0BllwR8BJaixm_KPuyqlizs-j4bpWifkk=.c68c6895-5075-41e6-b442-60d240b8ccf0@github.com>

On Thu, 5 May 2022 13:37:08 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284585: New constructor & minor improvements

Seeking additonal review from any watchers if possible

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Thu May 12 12:05:56 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 12 May 2022 12:05:56 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
Message-ID: <cCVgKN-MGVRHFpzmdM5XhmGIylJxmP7puKfAYca1Eok=.c44e1990-625b-4b98-bc6e-d1f281efe2b3@github.com>

On Fri, 6 May 2022 13:46:41 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Removed unecessary control flow

Will await further review for a short while and then integrate if approved.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From michaelm at openjdk.java.net  Thu May 12 12:19:09 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 12 May 2022 12:19:09 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v6]
In-Reply-To: <Rk1vPqEeuI5X32tPzj1uuQKlCo4BAoeYfOv_a8Ifghs=.e4739943-4d2f-4e28-95e9-7d738b66409e@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <Rk1vPqEeuI5X32tPzj1uuQKlCo4BAoeYfOv_a8Ifghs=.e4739943-4d2f-4e28-95e9-7d738b66409e@github.com>
Message-ID: <cDOwDBzjXtBZq_KZLaco29yaRb-yUz6H1pnm1KB2-iM=.5238cde9-db1c-4a5b-aa00-24deb1ddf0ef@github.com>

On Thu, 12 May 2022 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lengthOfCode() returns int; Removed excessive comments

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From jpai at openjdk.java.net  Thu May 12 12:26:53 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 12 May 2022 12:26:53 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <cCVgKN-MGVRHFpzmdM5XhmGIylJxmP7puKfAYca1Eok=.c44e1990-625b-4b98-bc6e-d1f281efe2b3@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
 <cCVgKN-MGVRHFpzmdM5XhmGIylJxmP7puKfAYca1Eok=.c44e1990-625b-4b98-bc6e-d1f281efe2b3@github.com>
Message-ID: <L1Wif5rFeFNL9M4xKLaJ4sj7RIwf-XoWt1C7rHBDUFU=.c07b478f-2338-4e2e-aa85-a47055d7bead@github.com>

On Thu, 12 May 2022 12:01:23 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Will await further review for a short while and then integrate if approved.

Hello Conor, looking at the latest state of the PR, I think you might have missed Daniel's review comment https://github.com/openjdk/jdk/pull/8017#discussion_r866857608 which I think has caught an unintentional change in this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From dfuchs at openjdk.java.net  Thu May 12 14:19:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 14:19:36 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v7]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <GyvIyc1xIIN3RWSXOCpeJz18ZgEF_NSTvlxSk-fmEfc=.5bf1f611-989d-46ea-905f-bdb1f9589f43@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Pavel's feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/deb22998..25c24d67

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=05-06

  Stats: 8 lines in 2 files changed: 4 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8656/head:pull/8656

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 14:19:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 14:19:36 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v7]
In-Reply-To: <1calWONAo_1JKW4RUjTHVZx7wx82lX5DdlzP-Es3di0=.16e57f8e-4634-4ee8-8a70-feb2d8e38f0c@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
 <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
 <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>
 <QKHvsBX6GN6dwVWxHvN3dnniRpwrXKT8ET0rDQ1gqsI=.d3fd4ec3-7e1f-4199-9f8c-c06df26b6f01@github.com>
 <1calWONAo_1JKW4RUjTHVZx7wx82lX5DdlzP-Es3di0=.16e57f8e-4634-4ee8-8a70-feb2d8e38f0c@github.com>
Message-ID: <vrt8t-hLqay1CcJIlRCG-yfef9V1PxC5PPn9B-0oAVU=.7d3d0b9b-825f-4384-821f-7be578e2f526@github.com>

On Thu, 12 May 2022 11:41:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> OK -  I will change codeLengthOf as suggested. It was not immediately obvious to me that the values would fit in the first 31 bits.
>
>> OK - I will change codeLengthOf as suggested. It was not immediately obvious to me that the values would fit in the first 31 bits.
> 
> In fact, it would even fit into the first 30 bits. There's a top-level comment that explains the layout of `code` elements. Maybe you can improve it somehow or carry over that specific part about the length into `codeLengthOf`. Alternatively, you can always slap `assert` in `codeLengthOf`.

Did I understand correctly that the lower 32 bits is expected to contain a length coded on 5 bits - which is expected to be a value in (5..30)?

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 14:25:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 14:25:44 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v8]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <K3hG9FO3ol87i68Bu1kZv4GozyYCRDaBWkUTpwwuZZc=.8e919879-efda-4b89-b2c8-8283177213d0@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Move assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/25c24d67..1f0902ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=06-07

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From rriggs at openjdk.java.net  Thu May 12 14:40:00 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 14:40:00 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v8]
In-Reply-To: <K3hG9FO3ol87i68Bu1kZv4GozyYCRDaBWkUTpwwuZZc=.8e919879-efda-4b89-b2c8-8283177213d0@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <K3hG9FO3ol87i68Bu1kZv4GozyYCRDaBWkUTpwwuZZc=.8e919879-efda-4b89-b2c8-8283177213d0@github.com>
Message-ID: <36FKE7MYfMEOkFMiUH3Q7K61AYLjlQaz0L6qN75rGdg=.e311f7e5-dcd2-42b8-b4a9-f0c1cf9d2440@github.com>

On Thu, 12 May 2022 14:25:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 14:56:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 14:56:47 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v9]
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <RFAs-qorY2a0dYoh26jpqMuSHSbKBjJkTOaQOzwQdZ0=.74ddac30-d3bd-4296-8d7b-db6e6a6b328e@github.com>

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

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

  Typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8656/files
  - new: https://git.openjdk.java.net/jdk/pull/8656/files/1f0902ed..258a5897

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8656&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 16:23:42 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 16:23:42 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v3]
In-Reply-To: <rh8UUzemmjXYnjjXRM-UrHPU6lCEJTTMPjIqs1-YO6M=.9ca962c0-07bc-48b5-9253-f7a515500f69@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <rh8UUzemmjXYnjjXRM-UrHPU6lCEJTTMPjIqs1-YO6M=.9ca962c0-07bc-48b5-9253-f7a515500f69@github.com>
Message-ID: <uV-R0V8-vl0Ygo507iLiBwur62842eU-BvXmddJIH24=.4eb6a31f-1afc-4126-aaad-7981db9daef3@github.com>

On Thu, 12 May 2022 11:54:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284585: Added test case to verify fix

Please make sure the test is stable with these changes, and if it is then LGTM.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8518

From dfuchs at openjdk.java.net  Thu May 12 16:27:40 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 16:27:40 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
Message-ID: <T1t4_pwTEsjALHpyOdKKNTIZih8YmbxIWJujbqU3S8U=.79f76919-be1f-4463-8d97-ad5cb549ba8d@github.com>

On Fri, 6 May 2022 13:46:41 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Removed unecessary control flow

Yes - please fix as the current proposal is buggy.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From rriggs at openjdk.java.net  Thu May 12 16:54:48 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 16:54:48 GMT
Subject: Integrated: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <WHMEywerPxetkdgvJXfdFg-DBiIp-Asn2kKRAhorZoY=.f73e75a5-7eb8-4bb1-9d8a-486164f40f92@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

This pull request has now been integrated.

Changeset: 17c52789
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17c52789b79a4ccd65308f90c4e02c1732b206be
Stats:     71 lines in 32 files changed: 0 ins; 3 del; 68 mod

8286378: Address possibly lossy conversions in java.base

Reviewed-by: naoto, xuelei, bpb, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From prappo at openjdk.java.net  Thu May 12 18:14:59 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 18:14:59 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v9]
In-Reply-To: <vrt8t-hLqay1CcJIlRCG-yfef9V1PxC5PPn9B-0oAVU=.7d3d0b9b-825f-4384-821f-7be578e2f526@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <5-gO6NRJUyvpttVXStWEAFQoZWg9eYxWVQKjXVomuPE=.2914fe5e-6461-4e40-ab34-341f1ebed95c@github.com>
 <5kuDuCgpsLm9QuH8IWSZuNOJBpc6htd5BvA6K37vaj4=.671b6352-f368-434d-8903-54bef2fc6a87@github.com>
 <ftq3SWtMJy4-j6Pcx_wW6FeGFuHxIuSAV4LUaGvNFew=.62fe14cd-0438-4911-8954-8e06fe4c23f0@github.com>
 <-fkbXgEZCZj-lHmvJK9F9eH4zGW2f3N_1W9bnu9JKnw=.9905ad19-37f8-42d9-91c8-2d51b1756a1f@github.com>
 <zrqtRbBjyXul4bi4C9BV7Bnf_-SbXzFZj95GMec7Oac=.bc871fc9-d663-4c00-8cb8-c831e9bdf4b6@github.com>
 <YRWK9Yz2d7xg2-LMOiaW-VnkL9LhqGFogfoWRxV7hmA=.7ddc50a8-74f8-4d94-b132-4a0999bc99b7@github.com>
 <QKHvsBX6GN6dwVWxHvN3dnniRpwrXKT8ET0rDQ1gqsI=.d3fd4ec3-7e1f-4199-9f8c-c06df26b6f01@github.com>
 <1calWONAo_1JKW4RUjTHVZx7wx82lX5DdlzP-Es3di0=.16e57f8e-4634-4ee8-8a70-feb2d8e38f0c@github.com>
 <vrt8t-hLqay1CcJIlRCG-yfef9V1PxC5PPn9B-0oAVU=.7d3d0b9b-825f-4384-821f-7be578e2f526@github.com>
Message-ID: <YLNl32a-nHqzuL_3VkTAqeE3lFCRDcRoL2oYrzE1cTE=.afca201e-6f94-4e1e-bd27-d30092d0e91f@github.com>

On Thu, 12 May 2022 14:15:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> OK - I will change codeLengthOf as suggested. It was not immediately obvious to me that the values would fit in the first 31 bits.
>> 
>> In fact, it would even fit into the first 30 bits. There's a top-level comment that explains the layout of `code` elements. Maybe you can improve it somehow or carry over that specific part about the length into `codeLengthOf`. Alternatively, you can always slap `assert` in `codeLengthOf`.
>
> Did I understand correctly that the lower 32 bits is expected to contain a length coded on 5 bits - which is expected to be a value in (5..30)?

Yes, you did understand that correctly.

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From prappo at openjdk.java.net  Thu May 12 18:19:59 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 12 May 2022 18:19:59 GMT
Subject: RFR: 8286386: Address possibly lossy conversions in java.net.http
 [v9]
In-Reply-To: <RFAs-qorY2a0dYoh26jpqMuSHSbKBjJkTOaQOzwQdZ0=.74ddac30-d3bd-4296-8d7b-db6e6a6b328e@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
 <RFAs-qorY2a0dYoh26jpqMuSHSbKBjJkTOaQOzwQdZ0=.74ddac30-d3bd-4296-8d7b-db6e6a6b328e@github.com>
Message-ID: <QDBvp8cQvJmx2oRszrAmmr1bEu3QMp-os0eTaeEoF5c=.0dfefde6-d2e1-4a5e-afa7-d54dbdae593a@github.com>

On Thu, 12 May 2022 14:56:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From dfuchs at openjdk.java.net  Thu May 12 18:39:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 18:39:58 GMT
Subject: Integrated: 8286386: Address possibly lossy conversions in
 java.net.http
In-Reply-To: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
References: <Y-2GSAKJJgVP8HBH-YYwT1dmg10_RN6F8NoiBDcoT0U=.7177467c-a9ca-4377-bf33-9504efa73cb7@github.com>
Message-ID: <7BAXRekAqV4J2p5-nFNri84-JZumOtWjfAWsaXA1QtM=.1db9e20b-91eb-415b-8bb9-c85d17e2420b@github.com>

On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find here a patch that addresses possibly lossy conversions in java.net.http

This pull request has now been integrated.

Changeset: 5ff1d227
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ff1d227bb878efda6262b183dfc5a0be2ce00c3
Stats:     27 lines in 3 files changed: 14 ins; 0 del; 13 mod

8286386: Address possibly lossy conversions in java.net.http

Reviewed-by: rriggs, michaelm, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8656

From wetmore at openjdk.java.net  Thu May 12 21:20:50 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 12 May 2022 21:20:50 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <lmFEoQtVXIFLJSs_aDtdYVpsjsO5CguBG2HDts471fo=.83e6b958-cfa0-412e-a15a-9866badb3067@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
 <lmFEoQtVXIFLJSs_aDtdYVpsjsO5CguBG2HDts471fo=.83e6b958-cfa0-412e-a15a-9866badb3067@github.com>
Message-ID: <Cj9M8PjnPdjEL2OPOLdGUb8AVvBt_xS9KKkwsxRH79w=.2eebe412-80f4-418a-a574-17e3bc82ab4b@github.com>

On Wed, 11 May 2022 22:25:43 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1:
>> 
>>> 1: /*
>> 
>> Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher.
>
> I can move it.. I created it from another test which happen to be in that directory

Ah.  If you can, please do.  Thanks.

>> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157:
>> 
>>> 155:         // Do TLS handshake
>>> 156:         do {
>>> 157:             statusClient = doHandshake(client, out, in);
>> 
>> It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works.  No need to change.
>> 
>> Is this style something you copied from another test?  The  SSLEngineTemplate in the templates directory is what I often use.
>
> I got it from somewhere that I don't remember off hand.  I'm just trying to get through the handshake.

It was just an observation, no need to change.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From wetmore at openjdk.java.net  Thu May 12 22:18:11 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 12 May 2022 22:18:11 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <G8pEYv3opmQS6oiF7MBwoZrhSqpKlIO9CdkExbYNhSo=.f40918d2-8701-481b-b2bd-306acf60a95d@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
 <G8pEYv3opmQS6oiF7MBwoZrhSqpKlIO9CdkExbYNhSo=.f40918d2-8701-481b-b2bd-306acf60a95d@github.com>
Message-ID: <BdCsMwuosukGC8n1Do-ZCqSnHJ5zaOM86X1lifssidQ=.85449dea-abcc-49a7-8059-b96f663511ab@github.com>

On Wed, 11 May 2022 23:03:27 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172:
>> 
>>> 170:         out.clear();
>>> 171:         String testString = "ASDF";
>>> 172:         in.put(testString.getBytes()).flip();
>> 
>> If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here.
>
> setting the input to UTF8 isn't a concern.  The latter line to decode it changes it from using the ByteBuffer.toString() to the contents of the ByteBuffer in a String.

You could use the default charsets for encoding and decoding.  i.e. 

        in.clear();
        receive(server, out.asReadOnlyBuffer(), in);
        byte[] ba = new byte[in.remaining()];
        in.get(ba);
        String testResult = new String(ba);

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From wetmore at openjdk.java.net  Thu May 12 22:37:58 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 12 May 2022 22:37:58 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <GDlWyHWTAQJd3zp1ipR5CBBwoswIFkEp23BU1YHLqdI=.9974ccac-6dc9-4748-9d33-f980d6ff6f75@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <Grq2S_8Q7S0AITHVOF8yn8ETuxR63hyTNg2aAUzQmVg=.ff76ff7f-4b1e-40e3-ad37-14251ae3ff64@github.com>
 <GDlWyHWTAQJd3zp1ipR5CBBwoswIFkEp23BU1YHLqdI=.9974ccac-6dc9-4748-9d33-f980d6ff6f75@github.com>
Message-ID: <OFpMih6sUimaBtY4j9HKzUSt1ZuPiJ8ChT0aPfMv8c8=.086349c8-86e6-4e4d-ba33-ec2293cd30dc@github.com>

On Wed, 11 May 2022 22:38:04 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162:
>> 
>>> 160:             statusServer != HandshakeStatus.NOT_HANDSHAKING);
>>> 161: 
>>> 162:         // Read NST
>> 
>> What is NST?
>
> New Session Ticket

Duh, of course!  Yay, TLAs!!!  (Three Letter Acronyms...)

Feel free to expand if you're so inclined.  ;)

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From duke at openjdk.java.net  Fri May 13 04:44:38 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 04:44:38 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);

This?will?now always?assign a?negative?number to?`to`.

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

`=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From alanb at openjdk.java.net  Fri May 13 05:56:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 05:56:40 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
Message-ID: <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>

On Fri, 13 May 2022 04:41:03 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyrights
>>   Fixed cast style to add a space after cast, (where consistent with file style)
>>   Improved code per review comments in PollSelectors.
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
> 
>> 126:                     // timed poll interrupted so need to adjust timeout
>> 127:                     long adjust = System.nanoTime() - startTime;
>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
> 
> This?will?now always?assign a?negative?number to?`to`.
> 
> --------------------------------------------------------------------------------
> 
> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

Well spotted, I don't think that change was intentionally.

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From michaelm at openjdk.java.net  Fri May 13 11:11:56 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 13 May 2022 11:11:56 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3]
In-Reply-To: <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>
Message-ID: <ZXudF7c6IyKgQr1eVTZE30VKhdohFSa1HgNMQBJj--4=.ba6920ca-8a9a-454e-a946-f71b59318a19@github.com>

On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
>> 
>> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
>> 
>> The fix comprises several cleanup - in particular:
>> 
>> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
>> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
>> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
>> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
>> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into ExecutorShutdown-intermittent-8286194
>  - Added a comment to ReferenceTracker.java as suggested in the review
>  - 8286194: ExecutorShutdown test fails intermittently

Good to see the dead code removed from HttpClientImpl (cancel). Question about the code copied in from ThreadInfo. Is there any way we could request a change to that class to adjust the number of stack frames printed? Okay, I see the same issue has been raised already. I agree we should request that enhancement.

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From dfuchs at openjdk.java.net  Fri May 13 11:34:03 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 13 May 2022 11:34:03 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3]
In-Reply-To: <ZXudF7c6IyKgQr1eVTZE30VKhdohFSa1HgNMQBJj--4=.ba6920ca-8a9a-454e-a946-f71b59318a19@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>
 <ZXudF7c6IyKgQr1eVTZE30VKhdohFSa1HgNMQBJj--4=.ba6920ca-8a9a-454e-a946-f71b59318a19@github.com>
Message-ID: <BUB71h2U6uY5eDyN-XQkjZ2PPxKz0qU850EeLgUde2g=.af46ca21-9759-4af2-9942-2077abe04145@github.com>

On Fri, 13 May 2022 11:09:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Question about the code copied in from ThreadInfo. Is there any way we could request a change to that class to adjust the number of stack frames printed?

Thanks Michael. I have logged https://bugs.openjdk.java.net/browse/JDK-8286720

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From michaelm at openjdk.java.net  Fri May 13 11:41:11 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 13 May 2022 11:41:11 GMT
Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3]
In-Reply-To: <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
 <tJrYpJJWfEU8wLqDPI57aHteKwG8DsT69g3kT14GCOc=.c2e6d5b4-3ad9-4f70-a017-1faae163adb7@github.com>
Message-ID: <suKtYNtIJjnXjCgSUk7EyXciXLWaseNMRx1s88A4TtQ=.d3422472-4292-4b0d-ab65-d67bf49f6f0b@github.com>

On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
>> 
>> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
>> 
>> The fix comprises several cleanup - in particular:
>> 
>> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
>> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
>> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
>> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
>> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into ExecutorShutdown-intermittent-8286194
>  - Added a comment to ReferenceTracker.java as suggested in the review
>  - 8286194: ExecutorShutdown test fails intermittently

Change looks fine to me. We can revisit the ThreadInfo code later.

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

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8562

From dfuchs at openjdk.java.net  Fri May 13 11:56:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 13 May 2022 11:56:52 GMT
Subject: Integrated: 8286194: ExecutorShutdown test fails intermittently
In-Reply-To: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
References: <fqcFOvFmXjxit5lmg2CqII2yYEUJcHcqXZliLBBWXT4=.d67ad72d-b878-4cf1-97e5-31950937bf0e@github.com>
Message-ID: <_ntXnBTOB4AhEv9fAUIJrKq4Qo1Vp3YzKN00xzmSFfo=.3331d153-d17a-4d84-bdff-d1a4b70dc550@github.com>

On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java`
> 
> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit.
> 
> The fix comprises several cleanup - in particular:
> 
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`)

This pull request has now been integrated.

Changeset: 04df8b74
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04df8b74379c9de7b20931fea1642f82569d3a2d
Stats:     138 lines in 7 files changed: 110 ins; 3 del; 25 mod

8286194: ExecutorShutdown test fails intermittently

Reviewed-by: jpai, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/8562

From rriggs at openjdk.java.net  Fri May 13 14:22:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 14:22:01 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
 <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
Message-ID: <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>

On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
>> 
>>> 126:                     // timed poll interrupted so need to adjust timeout
>>> 127:                     long adjust = System.nanoTime() - startTime;
>>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
>> 
>> This?will?now always?assign a?negative?number to?`to`.
>> 
>> --------------------------------------------------------------------------------
>> 
>> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.
>
> Well spotted, I don't think that change was intentionally.

Ouch; Will fix:

I took Alan's earlier comment literally:

"This one can also be changed to:

to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Fri May 13 14:27:02 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 14:27:02 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
 <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
 <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>
Message-ID: <uHzo-PzwaY50_BXGNi9Uyfs0a3Y3jiqJ4vcmzEAK5uA=.8a0281d4-3836-43ab-978c-4e6bb5b5a0c3@github.com>

On Fri, 13 May 2022 14:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Well spotted, I don't think that change was intentionally.
>
> Ouch; Will fix:
> 
> I took Alan's earlier comment literally:
> 
> "This one can also be changed to:
> 
> to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

@RogerRiggs
This?already got?fixed by?@jaikiran in?[GH?8693].

[GH?8693]: https://github.com/openjdk/jdk/pull/8693

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From ihse at openjdk.java.net  Fri May 13 15:14:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:14:43 GMT
Subject: RFR: 8285366: Fix typos in serviceability [v2]
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <de2J9hbH6Geo9BTK6iIPUAZGlDY6rV_RKI5-3GAir1U=.95c6f093-6bc8-4335-935e-7f2965325a57@github.com>

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert "invocable"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8334/files
  - new: https://git.openjdk.java.net/jdk/pull/8334/files/4b26668d..ad36a59a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Fri May 13 15:18:26 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:18:26 GMT
Subject: RFR: 8285366: Fix typos in serviceability [v3]
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <spv7AmHQlRMq1ecLah808rHAow8zcvCViF_El1OX_ho=.8361392e-4647-44d9-8219-6724f232d2aa@github.com>

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8334/files
  - new: https://git.openjdk.java.net/jdk/pull/8334/files/ad36a59a..4490ef75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=01-02

  Stats: 117 lines in 117 files changed: 0 ins; 0 del; 117 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8334/head:pull/8334

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Fri May 13 15:20:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:20:38 GMT
Subject: Integrated: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <31om9CILXc-UyN6Rbq8TQ3rgRgKopMrAlzF0o2hp84c=.2c91e2cd-08e2-400f-b320-19444106d5ad@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

This pull request has now been integrated.

Changeset: 76caeed4
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/76caeed498d868c7923461fb481349c0a2cbd99d
Stats:     303 lines in 136 files changed: 0 ins; 0 del; 303 mod

8285366: Fix typos in serviceability

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.java.net/jdk/pull/8334

From ascarpino at openjdk.java.net  Sat May 14 03:29:14 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Sat, 14 May 2022 03:29:14 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2]
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - review update
 - update some nits
 - PR ready
 - Initial

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

Changes: https://git.openjdk.java.net/jdk/pull/8462/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8462&range=01
  Stats: 393 lines in 3 files changed: 291 ins; 20 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8462.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8462/head:pull/8462

PR: https://git.openjdk.java.net/jdk/pull/8462

From xuelei at openjdk.java.net  Sat May 14 07:01:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 14 May 2022 07:01:55 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2]
In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
Message-ID: <kq5GWWHAcLmi2QPiQV36yluCi8f-W3cC_GrKTGjgQsw=.8a2981b8-e821-426e-a738-3cc599c65966@github.com>

On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - review update
>  - update some nits
>  - PR ready
>  - Initial

As the specification has been indicate that the input buffer could be updated, what do you think if closing the bug as "Not an issue" (or clarify the spec but no implementation update)?  I was just wondering if it really worthy the effort to make the code more complicated.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From jpai at openjdk.java.net  Sun May 15 06:43:27 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 15 May 2022 06:43:27 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v20]
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

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

  Use the byte[] address form for testing the client address instead of relying on hostname which
  doesn't always return localhost for 127.0.0.1 on Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6690/files
  - new: https://git.openjdk.java.net/jdk/pull/6690/files/d9f7b077..1584ab9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=18-19

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6690.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690

PR: https://git.openjdk.java.net/jdk/pull/6690

From ccleary at openjdk.java.net  Mon May 16 08:02:01 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 16 May 2022 08:02:01 GMT
Subject: RFR: 8284585: PushPromiseContinuation test fails intermittently in
 timeout [v3]
In-Reply-To: <rh8UUzemmjXYnjjXRM-UrHPU6lCEJTTMPjIqs1-YO6M=.9ca962c0-07bc-48b5-9253-f7a515500f69@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
 <rh8UUzemmjXYnjjXRM-UrHPU6lCEJTTMPjIqs1-YO6M=.9ca962c0-07bc-48b5-9253-f7a515500f69@github.com>
Message-ID: <UtbTkpd3hTisqcZk57SHXOAQhcatU3RoNFEBfkDtFCw=.cb1b21f1-57d8-40fd-97e4-79cef1cff3d6@github.com>

On Thu, 12 May 2022 11:54:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
>> 
>> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
>> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
>> 
>> **Proposed Solution**
>> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
>> 
>> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284585: Added test case to verify fix

Test seems stable with latest changes after multiple runs, will integrate.

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From ccleary at openjdk.java.net  Mon May 16 08:16:50 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 16 May 2022 08:16:50 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <L1Wif5rFeFNL9M4xKLaJ4sj7RIwf-XoWt1C7rHBDUFU=.c07b478f-2338-4e2e-aa85-a47055d7bead@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
 <cCVgKN-MGVRHFpzmdM5XhmGIylJxmP7puKfAYca1Eok=.c44e1990-625b-4b98-bc6e-d1f281efe2b3@github.com>
 <L1Wif5rFeFNL9M4xKLaJ4sj7RIwf-XoWt1C7rHBDUFU=.c07b478f-2338-4e2e-aa85-a47055d7bead@github.com>
Message-ID: <79NB0kOF_Fn4Ub48VjEZnsmhcjm2G-csEtw-fCGnZYM=.219b8c62-2119-4aaf-a8c3-9c96c798abfc@github.com>

On Thu, 12 May 2022 12:23:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Will await further review for a short while and then integrate if approved.
>
>> Will await further review for a short while and then integrate if approved.
> 
> Hello Conor, looking at the latest state of the PR, I think you might have missed Daniel's review comment https://github.com/openjdk/jdk/pull/8017#discussion_r866857608 which I think has caught an unintentional change in this PR.

Fixing now, was an ommision on my part. Thank you for catching it @jaikiran

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From jpai at openjdk.java.net  Mon May 16 08:20:56 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 16 May 2022 08:20:56 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v20]
In-Reply-To: <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
Message-ID: <beI8GfgGFbUv5Zvvd39HrIs2_0OuXjSXb4990cs8AsQ=.324fac76-34bb-4076-b5f0-31a499edf6b0@github.com>

On Sun, 15 May 2022 06:43:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the byte[] address form for testing the client address instead of relying on hostname which
>   doesn't always return localhost for 127.0.0.1 on Windows

The CSR for this has been approved. If the current state of the PR looks good, then I plan to integrate this later today.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From ccleary at openjdk.java.net  Mon May 16 08:59:43 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 16 May 2022 08:59:43 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v8]
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <k0pRwBslqzXFNwLAQmMQ7yeFaSYEIFK6vEntpDTc7EM=.4184a6a3-f865-41f1-a308-4919e66d5feb@github.com>

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

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

  8283544: Added in missing case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8017/files
  - new: https://git.openjdk.java.net/jdk/pull/8017/files/f6efc915..28edba8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=06-07

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From michaelm at openjdk.java.net  Mon May 16 10:23:58 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 16 May 2022 10:23:58 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v20]
In-Reply-To: <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
Message-ID: <_ohwNEB2OnFlSNzbWAY-7UWqSlk8EowUb_qkFwsgYVg=.bebf211d-993e-44d2-b9d3-21b2833133d1@github.com>

On Sun, 15 May 2022 06:43:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the byte[] address form for testing the client address instead of relying on hostname which
>   doesn't always return localhost for 127.0.0.1 on Windows

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From ccleary at openjdk.java.net  Mon May 16 11:18:58 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 16 May 2022 11:18:58 GMT
Subject: Integrated: 8284585: PushPromiseContinuation test fails intermittently
 in timeout
In-Reply-To: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
References: <2eN2y8wgbaz5iCd5KtypUA8AnbtblufSCszd8YSL3iw=.3aa258fa-5a12-45cc-b0fb-041e913256b0@github.com>
Message-ID: <ePrgdbIK2DBseb0-GFkaF601Ta1Z-xYuWvvfH8-kxxg=.10e4a1a8-faa4-4297-a93b-119673ef7f0a@github.com>

On Tue, 3 May 2022 15:00:51 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> A recent fix for [JDK-8263031](https://bugs.openjdk.java.net/browse/JDK-8263031), which addressed the httpclient being unable to properly process Http/2 PushPromise frames followed by continuations caused intermittent failures of the test. This was cause by two seperate problems. 
> 
> - Firstly, on the client side, `Http2Connection.processFrame` did not a check for whether or not a Continuation was to be expected early on in the method resulting in frames other than the expected Continuation Frame being incorrectly processed. In Http/2, when a Continuation Frame is expected, no other type of frame should be processed without a connection error of type PROTOCOL_ERROR being thrown.
> - Secondly, `Http2TestConnection.handlePush` had no guards around response headers and data frames being sent before a continuation is sent which resulted in the intermittent nature of this timeout. 
> 
> **Proposed Solution**
> The test class `OutgoingPushPromise` was modified to contain a list of Continuation Frames as required rather than the Continuations being scheduled to send in the test itself. This prevents the situation of unexpected frames being sent before a Continuation Frame was meant to arrive. 
> 
> In addition to the above, Http2Connection was modified to ensure that a connection error of type PROTOCOL_ERROR is thrown if a frame other than a Continuation arrives at the client unexpectedly.

This pull request has now been integrated.

Changeset: 65da38d8
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65da38d844760f7d17a143f8b4d5e25ea0144e27
Stats:     100 lines in 4 files changed: 83 ins; 6 del; 11 mod

8284585: PushPromiseContinuation test fails intermittently in timeout

Reviewed-by: dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/8518

From dfuchs at openjdk.java.net  Mon May 16 11:19:14 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 16 May 2022 11:19:14 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v20]
In-Reply-To: <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
Message-ID: <hEZWYK3UnE9dIBK4do2vtJwUZsxvcbeTRbW01X_JaCQ=.52148802-e501-4b23-aa50-b1e5fea5346f@github.com>

On Sun, 15 May 2022 06:43:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the byte[] address form for testing the client address instead of relying on hostname which
>   doesn't always return localhost for 127.0.0.1 on Windows

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Mon May 16 11:44:58 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 16 May 2022 11:44:58 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v20]
In-Reply-To: <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <3WpaokoQuLxm1sUOYdDV-LCxodNXSFQ-xWzNMbe5TDE=.3177f808-d832-405d-9478-89d575e1edef@github.com>
Message-ID: <hPYb0LnRWnFkMTC_u51EuAXGMo5_nfqa78PYRRn1uTM=.b3c7dfe6-3015-4bb9-9773-c752a535ae68@github.com>

On Sun, 15 May 2022 06:43:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the byte[] address form for testing the client address instead of relying on hostname which
>   doesn't always return localhost for 127.0.0.1 on Windows

Thank you Daniel and Michael for the constant inputs and reviews on this one.

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From jpai at openjdk.java.net  Mon May 16 11:48:22 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 16 May 2022 11:48:22 GMT
Subject: Integrated: 8209137: Add ability to bind to specific local address to
 HTTP client
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <Xr44wLFajvAppMV5u3uiTcUQQEkLbXJuXevbwQZDGfA=.ae8755d0-e22a-49d1-b76d-95a4d1ba5cec@github.com>

On Fri, 3 Dec 2021 06:15:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

This pull request has now been integrated.

Changeset: f4258a50
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4258a50e0f65ab9c375b9ee79f31de98d872550
Stats:     598 lines in 11 files changed: 589 ins; 5 del; 4 mod

8209137: Add ability to bind to specific local address to HTTP client

Reviewed-by: dfuchs, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Mon May 16 13:04:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 16 May 2022 13:04:07 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v8]
In-Reply-To: <k0pRwBslqzXFNwLAQmMQ7yeFaSYEIFK6vEntpDTc7EM=.4184a6a3-f865-41f1-a308-4919e66d5feb@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <k0pRwBslqzXFNwLAQmMQ7yeFaSYEIFK6vEntpDTc7EM=.4184a6a3-f865-41f1-a308-4919e66d5feb@github.com>
Message-ID: <pQtyk0PvhsB18TYQaxvfprBiunYWTSAtJODygaUsVBY=.a5b28d39-8059-4825-8034-f27b5c002e13@github.com>

On Mon, 16 May 2022 08:59:43 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Added in missing case

LGTM. If the test is stable you can integrate.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8017

From jpai at openjdk.java.net  Mon May 16 13:14:16 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 16 May 2022 13:14:16 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v8]
In-Reply-To: <k0pRwBslqzXFNwLAQmMQ7yeFaSYEIFK6vEntpDTc7EM=.4184a6a3-f865-41f1-a308-4919e66d5feb@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <k0pRwBslqzXFNwLAQmMQ7yeFaSYEIFK6vEntpDTc7EM=.4184a6a3-f865-41f1-a308-4919e66d5feb@github.com>
Message-ID: <f1MBhwpToD1tghOpuOV8CAByOnOucpOo-8HRrkiWY78=.076c00b8-36b6-48a0-979a-3b6748681c71@github.com>

On Mon, 16 May 2022 08:59:43 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Added in missing case

Thank you for the changes, Conor. The latest state looks fine to me.

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

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8017

From ascarpino at openjdk.java.net  Mon May 16 21:11:37 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 16 May 2022 21:11:37 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2]
In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
Message-ID: <rEtnb_UxGjd8x94iqzebUHU9uCoY9ksBYAdrKES8eTg=.31ad40dc-b282-4fd9-adf5-bc50a275eebc@github.com>

On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - review update
>  - update some nits
>  - PR ready
>  - Initial

There is too much grey area.  It says the src buffer maybe modified, which one could interpret it cannot be a read-only, but that would still need clarification to explicitly say "no read only buffers".  And other than these internal 'in-place' crypto reason, there is no API reason to not allow read-only buffers as input.
I did think about closing the CSR as the text was already there about the src buffer, even thought it was using a different term.  But I felt strongly enough that I wanted to prevent that confusion in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From xuelei at openjdk.java.net  Mon May 16 22:49:39 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 16 May 2022 22:49:39 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2]
In-Reply-To: <rEtnb_UxGjd8x94iqzebUHU9uCoY9ksBYAdrKES8eTg=.31ad40dc-b282-4fd9-adf5-bc50a275eebc@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
 <rEtnb_UxGjd8x94iqzebUHU9uCoY9ksBYAdrKES8eTg=.31ad40dc-b282-4fd9-adf5-bc50a275eebc@github.com>
Message-ID: <8OHZl5E-vk4kdhFQuUylRxmFDIhcwTPGYJ_hVQXeyy0=.efd4d05b-22de-4220-849b-6a262efabcbe@github.com>

On Mon, 16 May 2022 21:08:48 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> There is too much grey area. It says the src buffer maybe modified, which one could interpret it cannot be a read-only, but that would still need clarification to explicitly say "no read only buffers". And other than these internal 'in-place' crypto reason, there is no API reason to not allow read-only buffers as input. I did think about closing the CSR as the text was already there about the src buffer, even thought it was using a different term. But I felt strongly enough that I wanted to prevent that confusion in the future.

I think it is good to make the clarification with a CSR.

As the spec says, "The inbound network buffer, {@code src}, may be modified", applications cannot assume that the inbound network buffer cannot be modified (read-only) any longer.  It does not grant that an application will work with read-only inbound buffers for another JSSE provider.  As a result, an application that want to support read-only buffers may also need to support non-read-only buffers.  As makes it more complicated in both application layers and the JSSE implementation layer.  It may be simple that applications and JSSE implementation codes only need to handle non-read-only buffers.

Just my $0.02.  I will let you and Brad for the final decision.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From ccleary at openjdk.java.net  Tue May 17 09:14:54 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 17 May 2022 09:14:54 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v7]
In-Reply-To: <L1Wif5rFeFNL9M4xKLaJ4sj7RIwf-XoWt1C7rHBDUFU=.c07b478f-2338-4e2e-aa85-a47055d7bead@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <7AzqEIuTYGH1nACzTnBwp7hzHQDuVoCYlw1ISnxNK6E=.f9cbc500-de1a-4d4a-919a-2da7f651d0f2@github.com>
 <cCVgKN-MGVRHFpzmdM5XhmGIylJxmP7puKfAYca1Eok=.c44e1990-625b-4b98-bc6e-d1f281efe2b3@github.com>
 <L1Wif5rFeFNL9M4xKLaJ4sj7RIwf-XoWt1C7rHBDUFU=.c07b478f-2338-4e2e-aa85-a47055d7bead@github.com>
Message-ID: <XOKe70KV1KjE7AOSpsuVG741naCHpxozkQZ_GhvA2HY=.21fde18a-efae-4355-a602-a38d74b6ed10@github.com>

On Thu, 12 May 2022 12:23:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Will await further review for a short while and then integrate if approved.
>
>> Will await further review for a short while and then integrate if approved.
> 
> Hello Conor, looking at the latest state of the PR, I think you might have missed Daniel's review comment https://github.com/openjdk/jdk/pull/8017#discussion_r866857608 which I think has caught an unintentional change in this PR.

Thanks @jaikiran, will integrate now!

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From ccleary at openjdk.java.net  Tue May 17 10:06:04 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 17 May 2022 10:06:04 GMT
Subject: Integrated: 8283544: HttpClient GET method adds Content-Length: 0
 header
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <4Bk3z3D5yFs4xEt9KPEBUrB_oKMrBsIVeZz4XwznjuQ=.75fdc899-97d2-4f57-8966-7c1950b8fc26@github.com>

On Tue, 29 Mar 2022 15:44:58 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

This pull request has now been integrated.

Changeset: 6a770932
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a7709320d28d8e1593b113fdf39ab583fca3687
Stats:     248 lines in 2 files changed: 234 ins; 6 del; 8 mod

8283544: HttpClient GET method adds Content-Length: 0 header

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From djelinski at openjdk.java.net  Tue May 17 12:53:21 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 May 2022 12:53:21 GMT
Subject: RFR: 8286873: Improve websocket test execution time
Message-ID: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>

This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.

Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.

This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).

The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

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

Commit messages:
 - Explain magic timeouts
 - Retry all operations
 - Increase initial wait for Windows machines
 - Fix test retry
 - Avoid one 5-second wait
 - Use shorter timeout on the first try

Changes: https://git.openjdk.java.net/jdk/pull/8746/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8746&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286873
  Stats: 139 lines in 10 files changed: 70 ins; 38 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8746.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8746/head:pull/8746

PR: https://git.openjdk.java.net/jdk/pull/8746

From dfuchs at openjdk.java.net  Tue May 17 14:58:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 17 May 2022 14:58:41 GMT
Subject: RFR: 8286873: Improve websocket test execution time
In-Reply-To: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
Message-ID: <mREU8eLf0e0WFOhT9eENm0IkgxrX702PVs3w0_ocld0=.dd4adca5-bf05-4b8b-8816-d75e0464c7ab@github.com>

On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
> 
> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
> 
> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
> 
> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

Looks ok-ish. The idea of starting with a small timeout is a good one. I am a bit less sure about moving the post-asserts inside the loop - or closing before asserting that the cf hangs, but if I understand the logic correctly it seems ok too. Maybe give some time for @pavelrappo to chime in before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8746

From ascarpino at openjdk.java.net  Tue May 17 21:42:04 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 17 May 2022 21:42:04 GMT
Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2]
In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
 <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com>
Message-ID: <8VOhl2ipKsUgpystX7M8sDiDHhNfDVYWA0x1npAWf4s=.0fb01b2b-cd78-4a59-8533-c912ffbeb078@github.com>

On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
>> 
>> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - review update
>  - update some nits
>  - PR ready
>  - Initial

I think read-only has been allowed by the spec from the start, we just never allowed it to work properly.  I don't think this opens up possible complications in the code.

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From ascarpino at openjdk.java.net  Tue May 17 21:42:07 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 17 May 2022 21:42:07 GMT
Subject: Integrated: 8283577: SSLEngine.unwrap on read-only input ByteBuffer
In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com>
Message-ID: <8gT7YpYQtrAe7iXCq6peNX13K1dSTDbznWmvPERWTCg=.74d3093e-b694-4f7e-9564-cbe936cffba0@github.com>

On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation
> 
> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision.
> 
> Tony

This pull request has now been integrated.

Changeset: f17c68ce
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f17c68ce4a0b4f5c3131f4e4626a5a55b7f2f61f
Stats:     393 lines in 3 files changed: 291 ins; 20 del; 82 mod

8283577: SSLEngine.unwrap on read-only input ByteBuffer

Reviewed-by: wetmore

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

PR: https://git.openjdk.java.net/jdk/pull/8462

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
Message-ID: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

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

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

Changes: https://git.openjdk.java.net/jdk/pull/8768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284191
  Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <DOokHH_SxPtXjdpCSV9F_RmnHaNC6WnO3ChzhQNGxF8=.3fbb1072-bae7-4dc9-a424-4e9dd0cecc33@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AIjhEfuQaJLjZPeDl94HgUet9eMCoEwolZpNvKGGHGs=.bb1c32b4-65d8-40f2-84c3-38dc7db54894@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <pRvaphDcC8dB1bZPh6x4OhyZ8BHSfCn9ZCdBzq9Dnco=.1ca1edd4-0004-43b9-815c-3b20ffb5368f@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <c0o1YvhNkDe026TrcGqKdFaH6G93AfyQCHvBLzGNf8s=.007721e9-d02c-4319-a562-c3296fed6bbf@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <gSIQ2U9H0PmGgCBlsc4SocQff7AauSX3jiC10z26SJQ=.af26181b-5c61-4ecc-b836-5e5cff2cc901@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <A3yxKJkrz3h716ciAsbQHtiWg_y5gMtqLrMoDSxFTWE=.6e31ca1c-505c-4794-b1f0-622dc811388c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From prappo at openjdk.java.net  Thu May 19 09:26:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 19 May 2022 09:26:39 GMT
Subject: RFR: 8286873: Improve websocket test execution time
In-Reply-To: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
Message-ID: <cQzMXSV2hIcC9QV8r4EqfVWaliKh2Cn_boVBQA8Et-w=.4a85ecae-d3df-45e9-b712-5e953d939e54@github.com>

On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
> 
> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
> 
> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
> 
> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

I have poor recollection of the mechanics of these tests.

The source of wait is timed get and `assertHang`. You are reducing the former. That looks good.

What looks questionable is rearrangement of asserts: when `assertHangs` moves down. assertNotDone(cfClose) can transitorry pass even if ping has not hung. 

Tiriviality: since you are here, please remove

  1. superfluous "are" on BlowupOutputQueue:60
  2. "the a" on BlowupOutputQueue:63

test/jdk/java/net/httpclient/websocket/PendingOperations.java line 44:

> 42:     static final Class<IOException> IOE = IOException.class;
> 43:     // Time after which we deem that the local send buffer and remote
> 44:     // receive buffer must be full. This has been heuristically determined.

"Heuristically" was a weird word to use here; should've been "empirically", I think. You deleted the whole sentence, which is okay too.

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

Changes requested by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8746

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From djelinski at openjdk.java.net  Thu May 19 09:34:56 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 09:34:56 GMT
Subject: RFR: 8286873: Improve websocket test execution time
In-Reply-To: <mREU8eLf0e0WFOhT9eENm0IkgxrX702PVs3w0_ocld0=.dd4adca5-bf05-4b8b-8816-d75e0464c7ab@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
 <mREU8eLf0e0WFOhT9eENm0IkgxrX702PVs3w0_ocld0=.dd4adca5-bf05-4b8b-8816-d75e0464c7ab@github.com>
Message-ID: <qbynS_tSnacOWT9adm52mz7A2rg-7-Qyd7E_s_bI2Os=.a9795369-be1e-413e-9e58-d528a5c83260@github.com>

On Tue, 17 May 2022 14:55:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I am a bit less sure about moving the post-asserts inside the loop

I moved them because they too can fail if the original blocked future suddenly completes.
Side effect of this change is that any failures that happen after websocket.abort will be retried (isDone will return true). I think this is acceptable.

> or closing before asserting that the cf hangs, but if I understand the logic correctly it seems ok too.

`assertHangs` essentially just waits for five seconds to see if the future finishes in the meantime. With the proposed change we are waiting for 2 futures at the same time.

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From djelinski at openjdk.java.net  Thu May 19 09:45:39 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 09:45:39 GMT
Subject: RFR: 8286873: Improve websocket test execution time
In-Reply-To: <cQzMXSV2hIcC9QV8r4EqfVWaliKh2Cn_boVBQA8Et-w=.4a85ecae-d3df-45e9-b712-5e953d939e54@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
 <cQzMXSV2hIcC9QV8r4EqfVWaliKh2Cn_boVBQA8Et-w=.4a85ecae-d3df-45e9-b712-5e953d939e54@github.com>
Message-ID: <AWsHQ5c10RNYkhMepPQR9uHWsqxymuTBfSq5zU9iDE4=.741b459a-7f7c-4f5f-ace3-a1e716f0834f@github.com>

On Thu, 19 May 2022 09:22:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> What looks questionable is rearrangement of asserts: when `assertHangs` moves down. assertNotDone(cfClose) can transitorry pass even if ping has not hung.

`assertHangs` either waits for 5 seconds or throws an exception, so `assertNotDone` after `assertHangs` is pretty much equivalent to `assertHangs`

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From djelinski at openjdk.java.net  Thu May 19 10:03:50 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 10:03:50 GMT
Subject: RFR: 8286873: Improve websocket test execution time [v2]
In-Reply-To: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
Message-ID: <2pTXYLT48TNhO53L6DL9vnzWGjaDLuvUIYT_891O_ww=.ad1fb691-ad3f-4e4a-b523-3c63c8739535@github.com>

> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
> 
> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
> 
> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
> 
> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Fix wording

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8746/files
  - new: https://git.openjdk.java.net/jdk/pull/8746/files/52b735bf..bd7d3298

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8746&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8746&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From prappo at openjdk.java.net  Thu May 19 10:49:43 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 19 May 2022 10:49:43 GMT
Subject: RFR: 8286873: Improve websocket test execution time [v2]
In-Reply-To: <AWsHQ5c10RNYkhMepPQR9uHWsqxymuTBfSq5zU9iDE4=.741b459a-7f7c-4f5f-ace3-a1e716f0834f@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
 <cQzMXSV2hIcC9QV8r4EqfVWaliKh2Cn_boVBQA8Et-w=.4a85ecae-d3df-45e9-b712-5e953d939e54@github.com>
 <AWsHQ5c10RNYkhMepPQR9uHWsqxymuTBfSq5zU9iDE4=.741b459a-7f7c-4f5f-ace3-a1e716f0834f@github.com>
Message-ID: <C6xEwQ3-A7mfdZyIKTmKHJVpmgAR1h3NUo5i-fBeD4I=.cc97ce0a-84c5-488d-89d4-ac4a0f93c28c@github.com>

On Thu, 19 May 2022 09:42:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> > What looks questionable is rearrangement of asserts: when `assertHangs` moves down. assertNotDone(cfClose) can transitorry pass even if ping has not hung.
> 
> `assertHangs` either waits for 5 seconds or throws an exception, so `assertNotDone` after `assertHangs` is pretty much equivalent to `assertHangs`

The order of these checks is important. On the other hand, I'm not sure how important that importance is for the tests. With the proposed change, the test might become more permissive than it should've been.

Separately, why does this PR change `assertHangs(cfClose)` to `assertNotDone(cfClose)`?

The fact that you say that the tests still pass gives me some confidence. I'm just trying to make sure that the tests still test what we think they test.

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From djelinski at openjdk.java.net  Thu May 19 12:05:45 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 12:05:45 GMT
Subject: RFR: 8286873: Improve websocket test execution time [v3]
In-Reply-To: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
Message-ID: <c_ioKFp4ES6ZqlyoVGRfrgwGhG9y5pO9_U-hnhKq_GI=.dbcab847-0234-4d2e-86ae-d6ff018d2d5e@github.com>

> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
> 
> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
> 
> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
> 
> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Make it clear that both actions hang

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8746/files
  - new: https://git.openjdk.java.net/jdk/pull/8746/files/bd7d3298..832d7f9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8746&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8746&range=01-02

  Stats: 24 lines in 9 files changed: 6 ins; 9 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8746.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8746/head:pull/8746

PR: https://git.openjdk.java.net/jdk/pull/8746

From djelinski at openjdk.java.net  Thu May 19 12:15:38 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 12:15:38 GMT
Subject: RFR: 8286873: Improve websocket test execution time [v3]
In-Reply-To: <C6xEwQ3-A7mfdZyIKTmKHJVpmgAR1h3NUo5i-fBeD4I=.cc97ce0a-84c5-488d-89d4-ac4a0f93c28c@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
 <cQzMXSV2hIcC9QV8r4EqfVWaliKh2Cn_boVBQA8Et-w=.4a85ecae-d3df-45e9-b712-5e953d939e54@github.com>
 <AWsHQ5c10RNYkhMepPQR9uHWsqxymuTBfSq5zU9iDE4=.741b459a-7f7c-4f5f-ace3-a1e716f0834f@github.com>
 <C6xEwQ3-A7mfdZyIKTmKHJVpmgAR1h3NUo5i-fBeD4I=.cc97ce0a-84c5-488d-89d4-ac4a0f93c28c@github.com>
Message-ID: <4-dNHqW8Iu7acsZpIPONkvf9oDn3CvwBBq4IMo9Opc8=.66f88d9f-ba70-4b21-9875-539292ebf2fa@github.com>

On Thu, 19 May 2022 10:46:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > > What looks questionable is rearrangement of asserts: when `assertHangs` moves down. assertNotDone(cfClose) can transitorry pass even if ping has not hung.
> > 
> > 
> > `assertHangs` either waits for 5 seconds or throws an exception, so `assertNotDone` after `assertHangs` is pretty much equivalent to `assertHangs`
> 
> The order of these checks is important. On the other hand, I'm not sure how important that importance is for the tests. With the proposed change, the test might become more permissive than it should've been.
> 
> Separately, why does this PR change `assertHangs(cfClose)` to `assertNotDone(cfClose)`?
> 
> The fact that you say that the tests still pass gives me some confidence. I'm just trying to make sure that the tests still test what we think they test.

Modified the tests to make it clear that we expect both CFs to hang. Let me know if that addresses your concerns.

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From duke at openjdk.java.net  Thu May 19 12:22:49 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 19 May 2022 12:22:49 GMT
Subject: RFR: 8285521: Minor improvements in java.net.URI
In-Reply-To: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
References: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
Message-ID: <qwDJY9cp2gVvitG7TALcckUuEniVMhpKJ7_2MPMtufE=.5719687c-9054-4b31-8133-560a8a22c333@github.com>

On Tue, 26 Apr 2022 07:02:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - use `String.equalsIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - drop branches that are never executed
> - drop unused argument from `URI.resolvePath()`
> - simplify String-related operations

The?`String.equalsIgnoreCase(?)` and?`String.compareToIgnoreCase(?)`?changes are?incorrect, as?the?`String.*IgnoreCase(?)`?methods compare?all **Unicode** code?points case?insensitively using?**Unicode**?rules for?the?current or?specified?locale, whereas the?**URI**?specification does?case?insensitive?comparison only?for?characters in?the?**US?ASCII**?range?[[RFC3986]].

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

https://github.com/openjdk/jdk/blob/408a3a8e29006798071cd6f185e415bc2bc62282/src/java.base/share/classes/java/net/URI.java#L1825-L1830 https://github.com/openjdk/jdk/blob/408a3a8e29006798071cd6f185e415bc2bc62282/src/java.base/share/classes/java/net/URI.java#L1832-L1844

[RFC3986]: https://datatracker.ietf.org/doc/html/rfc3986

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

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8397

From prappo at openjdk.java.net  Thu May 19 12:25:54 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 19 May 2022 12:25:54 GMT
Subject: RFR: 8286873: Improve websocket test execution time [v3]
In-Reply-To: <c_ioKFp4ES6ZqlyoVGRfrgwGhG9y5pO9_U-hnhKq_GI=.dbcab847-0234-4d2e-86ae-d6ff018d2d5e@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
 <c_ioKFp4ES6ZqlyoVGRfrgwGhG9y5pO9_U-hnhKq_GI=.dbcab847-0234-4d2e-86ae-d6ff018d2d5e@github.com>
Message-ID: <YRx_VGt_p8EeoUsquE-Wy94Jx8iMIhnJN23w_tF_rLs=.35b0d9ae-2cae-44d3-a15c-83b603665381@github.com>

On Thu, 19 May 2022 12:05:45 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
>> 
>> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
>> 
>> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
>> 
>> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make it clear that both actions hang

Marked as reviewed by prappo (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From djelinski at openjdk.java.net  Thu May 19 13:25:55 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 19 May 2022 13:25:55 GMT
Subject: Integrated: 8286873: Improve websocket test execution time
In-Reply-To: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
References: <L9jEC8AkHAXZ5ErpY8i_5wH24hcyR_j5nsnC-B4WOWA=.616e856c-51e9-4317-ab2e-ff75b1cb5f63@github.com>
Message-ID: <d4tFDoUYPI4PD9hsf3p73p52yD1jxU329hLNyOfL2tY=.b46d71ee-d48e-45fe-a2f2-863ea015fcbd@github.com>

On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the execution time of jdk_net tests (and, by extension, tier2) by about 3 minutes.
> 
> Tests located under `jdk/java/net/httpclient/websocket` are never run in parallel. Each of the 8 modified `Pending***` tests originally required 40 seconds to complete. After the proposed changes, they usually complete in 15 seconds.
> 
> This PR modifies the tests to initially run with 1 second timeout. If the test fails with 1 second timeout, it is retried with timeout increased to 10 seconds (the original value).
> 
> The modified tests were executed at least 10 times on each of: Windows, Linux (both x64 and aarch64), MacOS (both x64 and aarch64). No failures were observed.

This pull request has now been integrated.

Changeset: d24c84e7
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d24c84e7687890db88550b05ff9eebe9cae361b2
Stats:     140 lines in 10 files changed: 68 ins; 39 del; 33 mod

8286873: Improve websocket test execution time

Reviewed-by: dfuchs, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/8746

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AEcXIgzPrzjMIYqVKaZBv2j_3w8nrjL-kejrZ0nvBGE=.cb7c63c7-8f32-4cfa-b7d5-e2bb84750add@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: <lPlIgFLf96r_Xr7YJIr2w2uODPCG9bRPhAnl2tuAo50=.82a145da-9923-4c5b-a72d-14ba982bf303@github.com>

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From duke at openjdk.java.net  Thu May 19 16:31:42 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 19 May 2022 16:31:42 GMT
Subject: RFR: 8285521: Minor improvements in java.net.URI
In-Reply-To: <qwDJY9cp2gVvitG7TALcckUuEniVMhpKJ7_2MPMtufE=.5719687c-9054-4b31-8133-560a8a22c333@github.com>
References: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
 <qwDJY9cp2gVvitG7TALcckUuEniVMhpKJ7_2MPMtufE=.5719687c-9054-4b31-8133-560a8a22c333@github.com>
Message-ID: <7oafRSKy2oaIzceYkC5PVSym6VLsOkxz50d-OEfroLA=.299ae44c-48e8-4e60-b24a-877a9494d045@github.com>

On Thu, 19 May 2022 12:19:25 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> - use `String.equalsIgnoreCase()` instead of hand-written code relying on `String.charAt()`
>> - use `String.compareToIgnoreCase()` instead of hand-written code relying on `String.charAt()`
>> - drop branches that are never executed
>> - drop unused argument from `URI.resolvePath()`
>> - simplify String-related operations
>
> The?`String.equalsIgnoreCase(?)` and?`String.compareToIgnoreCase(?)`?changes are?incorrect, as?the?`String.*IgnoreCase(?)`?methods compare?all **Unicode** code?points case?insensitively using?**Unicode**?rules for?the?current or?specified?locale, whereas the?**URI**?specification does?case?insensitive?comparison only?for?characters in?the?**US?ASCII**?range?[[RFC3986]].
> 
> --------------------------------------------------------------------------------
> 
> https://github.com/openjdk/jdk/blob/408a3a8e29006798071cd6f185e415bc2bc62282/src/java.base/share/classes/java/net/URI.java#L1825-L1830 https://github.com/openjdk/jdk/blob/408a3a8e29006798071cd6f185e415bc2bc62282/src/java.base/share/classes/java/net/URI.java#L1832-L1844
> 
> [RFC3986]: https://datatracker.ietf.org/doc/html/rfc3986

@ExE-Boss 

> String.*IgnoreCase(?) methods compare all Unicode code points case?insensitively using Unicode rules for the current or specified locale, whereas the URI specification does case?insensitive comparison only for characters in the US?ASCII range

Aren't all the items of US-ASCII range belong to Unicode regardless of locale?

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

PR: https://git.openjdk.java.net/jdk/pull/8397

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <De1XJE92ZHSiL99Rs-yvnD30-uzxuj4sfIn432JAocM=.2d3d0f7a-8c35-4575-aa20-1ccc267021c4@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
Message-ID: <bBFati7RKtrl5FcrKP4_YCSO34DZrrIX7b_Daw9f91E=.dbbf28d9-92ef-4ae1-950c-f34036d483e4@github.com>

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
Message-ID: <Hm4DXlPz0QuS87RjrcFEwxyh-97burW3YzckN3z0aGM=.6c816cc2-3256-4b2c-87d7-c2206b9f9a39@github.com>

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From duke at openjdk.java.net  Thu May 19 21:56:46 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 19 May 2022 21:56:46 GMT
Subject: RFR: 8285521: Minor improvements in java.net.URI
In-Reply-To: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
References: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
Message-ID: <1eJc5LCZK1bfswTL2VMWAveINTkYma41ZA9FFfahGeQ=.2832cfcb-25dd-4241-898f-1ae3a377e1de@github.com>

On Tue, 26 Apr 2022 07:02:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - use `String.equalsIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - drop branches that are never executed
> - drop unused argument from `URI.resolvePath()`
> - simplify String-related operations

Note?that if?the?current?locale is?Turkish, then?`"I".equalsIgnoreCase("i")` (`"\u0049".equalsIgnoreCase("\u0069")`) returns?`false`.

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

PR: https://git.openjdk.java.net/jdk/pull/8397

From duke at openjdk.java.net  Fri May 20 08:20:04 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 20 May 2022 08:20:04 GMT
Subject: RFR: 8285521: Minor improvements in java.net.URI
In-Reply-To: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
References: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
Message-ID: <YKWzNh-nnPUySQ8A23DFMVZrKHx_1p1_2gQ0LD2IiEY=.7b9b4b86-c5e8-4123-9edc-088f3c603cc8@github.com>

On Tue, 26 Apr 2022 07:02:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - use `String.equalsIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - drop branches that are never executed
> - drop unused argument from `URI.resolvePath()`
> - simplify String-related operations

Ok, I'll revert these changes then.

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

PR: https://git.openjdk.java.net/jdk/pull/8397

From duke at openjdk.java.net  Fri May 20 08:25:02 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 20 May 2022 08:25:02 GMT
Subject: RFR: 8285521: Minor improvements in java.net.URI [v2]
In-Reply-To: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
References: <qCiqbgDNNJinosC9dexJ9_qsAXnXCmBbnQct65GnoIQ=.26afa8c7-4544-4882-928f-4c51d34fbc93@github.com>
Message-ID: <RNROAdYjdtKfWptgmWRfyoahYWBsbGgccy-lkNljR0s=.745767fe-ff03-4166-8dc4-d40d1818b180@github.com>

> - use `String.equalsIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - use `String.compareToIgnoreCase()` instead of hand-written code relying on `String.charAt()`
> - drop branches that are never executed
> - drop unused argument from `URI.resolvePath()`
> - simplify String-related operations

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

  8285521: Revert wrong changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8397/files
  - new: https://git.openjdk.java.net/jdk/pull/8397/files/408a3a8e..be41ccf9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8397&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8397&range=00-01

  Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8397.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8397/head:pull/8397

PR: https://git.openjdk.java.net/jdk/pull/8397

From jpai at openjdk.java.net  Sun May 22 08:27:18 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 22 May 2022 08:27:18 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can cause
 memory leak for webapp-servers
Message-ID: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>

Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?

The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.

Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.

Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.

No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

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

Commit messages:
 - 8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From aefimov at openjdk.java.net  Mon May 23 12:21:40 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 23 May 2022 12:21:40 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers
In-Reply-To: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
Message-ID: <_IuWKIYnfvPVauWbGKZx2fljNtkC3TSSXmfJCLyZh70=.16a6205c-ec42-43ae-a0d3-f26262f33f59@github.com>

On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
> 
> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
> 
> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
> 
> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
> 
> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

Hi @jaikiran,

Thanks for the fix. Chages look good to me with one suggestion:
Could we reflect in a thread name the fact that it is JNDI/DNS specific one? Right now it is not clear - one might think that it could be related to `InetAddress`/`NetworkInterface` or other networking classes.
Maybe something like `Jndi-Dns-address-change-listener`?

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

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8827

From aefimov at openjdk.java.net  Mon May 23 12:23:54 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 23 May 2022 12:23:54 GMT
Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on
 AIX [v7]
In-Reply-To: <5pdPpiW1RsG4nIcmju0FzeUR1oPXNYSjFYajQs6oQvY=.079889e3-1311-4a5c-9503-27f8999eea16@github.com>
References: <iOmvI5_usJaB2fnY8xa15alEAjMql6KucwNTrPHKEp8=.7ddd238e-38bf-44a5-9764-de968f3f0314@github.com>
 <fDvni4Y7A1vaXaba9Zmy-xjjha_W-jZicbxD6fBi8Lo=.5b3fd7f2-43e3-400f-a682-cdc8e7c93a83@github.com>
 <5pdPpiW1RsG4nIcmju0FzeUR1oPXNYSjFYajQs6oQvY=.079889e3-1311-4a5c-9503-27f8999eea16@github.com>
Message-ID: <w2xL1Bkt0YmRhY4qwFjCIZDEKAg5PxRQyvJnilenrXg=.829073f7-97f6-45de-ac72-cec0435be1a8@github.com>

On Fri, 6 May 2022 09:18:33 GMT, Michael Felt <duke at openjdk.java.net> wrote:

>> Michael Felt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes per review
>
> - Thx all for your assistance and patience.
> - (Hoping you will consider this for backport as well).

Hi @aixtools,
This is just a reminder that you can proceed with the integration of this PR :)

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

PR: https://git.openjdk.java.net/jdk/pull/7013

From jpai at openjdk.java.net  Mon May 23 12:31:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 23 May 2022 12:31:40 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v2]
In-Reply-To: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
Message-ID: <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
> 
> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
> 
> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
> 
> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
> 
> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

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

  Aleksei's review suggestion - use a better Thread name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8827/files
  - new: https://git.openjdk.java.net/jdk/pull/8827/files/e4b71f6b..f1f4a7a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From aefimov at openjdk.java.net  Mon May 23 12:31:40 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 23 May 2022 12:31:40 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v2]
In-Reply-To: <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>
Message-ID: <e7bE0UrqRzqi3pxJgo3iA31cqfMc5QcBeeTy8JY8q1c=.a3ac4f00-3c64-4163-b1dc-604f4c9b3dde@github.com>

On Mon, 23 May 2022 12:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
>> 
>> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
>> 
>> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
>> 
>> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
>> 
>> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksei's review suggestion - use a better Thread name

Marked as reviewed by aefimov (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From jpai at openjdk.java.net  Mon May 23 12:31:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 23 May 2022 12:31:40 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers
In-Reply-To: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
Message-ID: <96gt-F6x51AqUvblSpegG0g5XMT4QlAWTe2-EO2gNog=.776e2070-2c56-4f4a-a691-c4d8b28e82e7@github.com>

On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
> 
> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
> 
> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
> 
> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
> 
> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

Thank you for the review Aleksei. What you suggest about the thread name makes sense. I have now updated the PR to use that name.

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From rriggs at openjdk.java.net  Mon May 23 18:37:51 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 May 2022 18:37:51 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
 <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
Message-ID: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>

On Tue, 10 May 2022 19:24:24 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
>> 
>>> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>>> 776:             printStackWhenAccessFails = GetBooleanAction.
>>> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
>> 
>> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.
>
> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.

This change still needs to be reversed.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From duke at openjdk.java.net  Mon May 23 18:58:34 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Mon, 23 May 2022 18:58:34 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>

> JDK-6725221 Standardize obtaining boolean properties with defaults

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Alan and Jamil comments
 - Merge
 - reverse true.equals and false.equals changes
 - Merge
 - Merge
 - first iteration

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

Changes: https://git.openjdk.java.net/jdk/pull/8559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=01
  Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559

PR: https://git.openjdk.java.net/jdk/pull/8559

From duke at openjdk.java.net  Mon May 23 19:03:51 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Mon, 23 May 2022 19:03:51 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
 <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
 <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>
Message-ID: <Q225NlMNasd2tzak-lkkM5PQgU5fV8CS1zDtXo0xQb0=.ba339f01-ac2a-4821-9e35-4e1d8f26c6b5@github.com>

On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.
>
> This change still needs to be reversed.

The change has been reversed.

We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From rriggs at openjdk.java.net  Mon May 23 20:00:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 May 2022 20:00:01 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
Message-ID: <TqMVPufXkfsmPDZ7AkKu3XPWlayGrFqey8oUS82PBTI=.7c45b137-7ccd-4cb9-859e-f5ff37fcc1ff@github.com>

On Mon, 23 May 2022 18:58:34 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Alan and Jamil comments
>  - Merge
>  - reverse true.equals and false.equals changes
>  - Merge
>  - Merge
>  - first iteration

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8559

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v3]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

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

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02

  Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From dfuchs at openjdk.java.net  Tue May 24 09:45:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 24 May 2022 09:45:44 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v2]
In-Reply-To: <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>
Message-ID: <UI1gxc1QFUfZKcPxuuYWmvX3CwWRbc4j6FbqzrtZDBE=.fcc8b635-84d1-41be-b686-1c9f79fdf148@github.com>

On Mon, 23 May 2022 12:31:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
>> 
>> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
>> 
>> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
>> 
>> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
>> 
>> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksei's review suggestion - use a better Thread name

src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java line 49:

> 47:     // Addresses have changed. We default to true to make sure we
> 48:     // resolve the first time it is requested.
> 49:     private static volatile boolean changed = true;

The field `changed` is only accessed when `synchronized` on `lock` - except for this initialization line here. I wonder if the volatile is actually needed. A better fix might be to rename it to `nochanges` and revert its semantics, which would allow to leave it initialized to false.  Or maybe just revert changes to line 49.
Otherwise looks good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and
 java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ZIBUrN38HimpUwfEYc-LwYC3gXjfDXNaD55bHE9PU2M=.87e99c4b-c1a3-47d4-9323-421efb88ed06@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From duke at openjdk.java.net  Tue May 24 16:23:59 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 24 May 2022 16:23:59 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
Message-ID: <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>

On Mon, 23 May 2022 18:58:34 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Alan and Jamil comments
>  - Merge
>  - reverse true.equals and false.equals changes
>  - Merge
>  - Merge
>  - first iteration

Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot?

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From wetmore at openjdk.java.net  Tue May 24 18:14:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 24 May 2022 18:14:56 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
 <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>
Message-ID: <WJhempLMMPfk9itHCiG2ZNOiZ1u7hHtd2u4a7kRfNTg=.aac25009-2b01-4f0b-9142-f4d251f57aec@github.com>

On Tue, 24 May 2022 16:20:10 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot?

IIUC, these are due to Loom failures in some of the other platforms supported by OpenJDK but not by Oracle.  They are being resolved.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From duke at openjdk.java.net  Tue May 24 18:20:00 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 24 May 2022 18:20:00 GMT
Subject: Integrated: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <6NZWhFHhhJI3m2-DVm8Jzfla_Z7hPbnhGf4H8cBpM6c=.9e3988f9-cefd-4399-9e83-6ef6ae5ad29e@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

This pull request has now been integrated.

Changeset: 6cc4bb11
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6cc4bb1169f34bc091cad3e2deec37cd5585e8d5
Stats:     9 lines in 3 files changed: 1 ins; 1 del; 7 mod

6725221: Standardize obtaining boolean properties with defaults

Reviewed-by: prr, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From jpai at openjdk.java.net  Wed May 25 09:30:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 09:30:46 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v3]
In-Reply-To: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
Message-ID: <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
> 
> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
> 
> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
> 
> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
> 
> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

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

  No need for volatile as spotted by Daniel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8827/files
  - new: https://git.openjdk.java.net/jdk/pull/8827/files/f1f4a7a5..6d36b16c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8827&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From jpai at openjdk.java.net  Wed May 25 09:30:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 09:30:47 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v2]
In-Reply-To: <UI1gxc1QFUfZKcPxuuYWmvX3CwWRbc4j6FbqzrtZDBE=.fcc8b635-84d1-41be-b686-1c9f79fdf148@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <pWNPTRVzkU6O7A5g1SL0kp_iXgMB-1X1cyhI27rPFEc=.25c018e5-e269-46e3-8b54-f9523d1339fa@github.com>
 <UI1gxc1QFUfZKcPxuuYWmvX3CwWRbc4j6FbqzrtZDBE=.fcc8b635-84d1-41be-b686-1c9f79fdf148@github.com>
Message-ID: <880-9sgeELdYIyP0DMJ7pBcjt3lTZWFRD-96oFCAG7g=.7116ebaa-ade5-4f2f-aa4c-1617b9d935db@github.com>

On Tue, 24 May 2022 09:42:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksei's review suggestion - use a better Thread name
>
> src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java line 49:
> 
>> 47:     // Addresses have changed. We default to true to make sure we
>> 48:     // resolve the first time it is requested.
>> 49:     private static volatile boolean changed = true;
> 
> The field `changed` is only accessed when `synchronized` on `lock` - except for this initialization line here. I wonder if the volatile is actually needed. A better fix might be to rename it to `nochanges` and revert its semantics, which would allow to leave it initialized to false.  Or maybe just revert changes to line 49.
> Otherwise looks good to me.

Hello Daniel,

> The field changed is only accessed when synchronized on lock - except for this initialization line here. I wonder if the volatile is actually needed. 

You are right - I had missed the fact that the `loadConfig()` method gets called with the `lock` held, the same lock which is then used for updating `changed`. So making this `volatile` isn't necessary. I have undone just the `volatile` change and updated this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From aefimov at openjdk.java.net  Wed May 25 11:05:03 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 25 May 2022 11:05:03 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v3]
In-Reply-To: <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
Message-ID: <VEQ_zsX7C94d2zEjNo7Y90LX7O35L83h2HneBpcVjnE=.06b2fb1b-25bf-4099-b98a-546acbe45093@github.com>

On Wed, 25 May 2022 09:30:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
>> 
>> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
>> 
>> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
>> 
>> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
>> 
>> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need for volatile as spotted by Daniel

Marked as reviewed by aefimov (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From dfuchs at openjdk.java.net  Wed May 25 14:21:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 25 May 2022 14:21:56 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v3]
In-Reply-To: <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
Message-ID: <VMorsIglgvUPYtFK4cTKJLdj41qwR1dtkGKsTM8woY0=.70440efa-fc76-408e-8096-be4b1f850b7f@github.com>

On Wed, 25 May 2022 09:30:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
>> 
>> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
>> 
>> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
>> 
>> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
>> 
>> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need for volatile as spotted by Daniel

LGTM now!

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8827

From jpai at openjdk.java.net  Wed May 25 14:36:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 14:36:05 GMT
Subject: RFR: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers [v3]
In-Reply-To: <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
 <sexZBuFs51UwCkXcfPbF8cIHWu7c5Vm8uiI4xamVKaU=.2ffa2fcd-5ac1-4e64-b221-72c1117f43fc@github.com>
Message-ID: <FE0MMfFiGlYD_Wr_RMeh_UBwsa0nGKH_wKcj6Kga4RA=.505b1a0e-6a84-4d06-a8eb-4ee8ab8781c0@github.com>

On Wed, 25 May 2022 09:30:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
>> 
>> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
>> 
>> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
>> 
>> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
>> 
>> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need for volatile as spotted by Daniel

Thank you Aleksei and Daniel for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From jpai at openjdk.java.net  Wed May 25 14:36:07 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 14:36:07 GMT
Subject: Integrated: 8287104: AddressChangeListener thread inherits CCL and can
 cause memory leak for webapp-servers
In-Reply-To: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
References: <M9kPh-_l95K8L0JmO18A1rFKP5_zdRO-rc1lRHhOEME=.9cb7e15a-02de-45e6-b6fa-c5821d7cb957@github.com>
Message-ID: <Sn9Ob7mbl8S9GA4DW-CZeWxY2nCuzvGmnznUzEKtNJg=.589d0252-96e0-4ca3-aea6-aa7febdde3a4@github.com>

On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8287104?
> 
> The change in this commit now uses an `InnocuousThread` to create a thread with `null` context classloader. The `Runnable` task of this thread just invokes a native method through JNI to be notified of IP addresses change of the host. As such any specific thread context classloader isn't necessary in this thread.
> 
> Additionally, this commit does some minor changes like making the `lock` member variable `final` and also marking the `changed` member variable as `volatile`. These changes aren't necessary for this fix, but I think would be good to have while we are changing this part of the code.
> 
> Finally, the thread that we create here, now has a specific name `Net-address-change-listener` instead of the usual system wide auto-generated name.
> 
> No new tests have been added for this change. Existing tier1, tier2 and tier3 tests have been run and no related failures have been noticed.

This pull request has now been integrated.

Changeset: 81d7eafd
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81d7eafd913d28e0c83ddb29f9436b207da5f21c
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8287104: AddressChangeListener thread inherits CCL and can cause memory leak for webapp-servers

Reviewed-by: aefimov, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/8827

From jpai at openjdk.java.net  Thu May 26 07:24:10 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 26 May 2022 07:24:10 GMT
Subject: RFR: 8287318: ConcurrentModificationException in
 sun.net.httpserver.ServerImpl$Dispatcher
Message-ID: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.java.net/browse/JDK-8287318?

The `ServerImpl` has a `Dispatcher` thread which uses a `Selector` to select keys of interested. The selected keys is then iterated over and each key is removed through the iterator. This is fine as long as the selector isn't then used to invoke select operation(s) while the iterator is still in use. Doing so leads to the underlying Set being potentially modified with updates to the selected keys. As a result any subsequent use of the iterator will lead to `ConcurrentModificationException` as seen in the linked issue.

The commit here fixes that by creating a copy of the selected keys and iterating over it so that any subsequent select operation on the selector won't have impact on the Set that is being iterated upon. 

No new tests have been added given the intermittent nature of this issue. Existing tier1, tier2 and tier3 tests passed without any related failures, after this change.

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

Commit messages:
 - 8287318: ConcurrentModificationException in sun.net.httpserver.ServerImpl

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

PR: https://git.openjdk.java.net/jdk/pull/8898

From duke at openjdk.java.net  Thu May 26 09:25:50 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 26 May 2022 09:25:50 GMT
Subject: RFR: 8272707: Resolving URI relative path with no / may lead to
 incorrect toString
Message-ID: <EYaKnK9p_ptDTRgORv2Dj0a2wRrrSvGo4RmjTCsetuM=.5ee4d026-e0a5-4404-87e0-1c8b1a2febee@github.com>

Consider an authority component without trailing "/" as a base URI. When resolving a relative path against this base URI, the resulting URI is a concatenated URI without "/".
This behaviour should be fixed, which is rationalized by rfc3986#section-5.2.3.
Could you review this fix?

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

Commit messages:
 - 8272702: Resolving URI relative path with no / may lead to incorrect toString

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

PR: https://git.openjdk.java.net/jdk/pull/8899

From aivanov at openjdk.java.net  Thu May 26 12:03:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 May 2022 12:03:33 GMT
Subject: RFR: 8272707: Resolving URI relative path with no / may lead to
 incorrect toString
In-Reply-To: <EYaKnK9p_ptDTRgORv2Dj0a2wRrrSvGo4RmjTCsetuM=.5ee4d026-e0a5-4404-87e0-1c8b1a2febee@github.com>
References: <EYaKnK9p_ptDTRgORv2Dj0a2wRrrSvGo4RmjTCsetuM=.5ee4d026-e0a5-4404-87e0-1c8b1a2febee@github.com>
Message-ID: <YsvFzHAWfY16bgcCXf23WEeVqXAVFwuzPdWWkKo5-h8=.9afd6cb6-c05b-4121-91ba-bb81a8e1d071@github.com>

On Thu, 26 May 2022 09:18:56 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> Consider an authority component without trailing "/" as a base URI. When resolving a relative path against this base URI, the resulting URI is a concatenated URI without "/".
> This behaviour should be fixed, which is rationalized by rfc3986#section-5.2.3.
> Could you review this fix?

@tkiriyama You're using the wrong bugid. [JDK-8272707](https://bugs.openjdk.java.net/browse/JDK-8272707) has nothing to do with URI. Please use the correct bugid.

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

PR: https://git.openjdk.java.net/jdk/pull/8899

From aturbanov at openjdk.java.net  Thu May 26 20:41:10 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 26 May 2022 20:41:10 GMT
Subject: RFR: 8287390: Cleanup Map usage in
 AuthenticationInfo.requestAuthentication
Message-ID: <jvBdpCs0jy1cKOZ3mBAMKMIbUCNzfqqFc2H_7aFdCaw=.13cc10fc-215d-430e-9a06-e3004f33aa7f@github.com>

`AuthenticationInfo.requestAuthentication` uses separate `HashMap`'s `get` +`put` calls.

            Thread t, c;
            c = Thread.currentThread();
            if ((t = requests.get(key)) == null) {
                requests.put (key, c);
                assert cached == null;
                return cached;
            }
            if (t == c) {
                assert cached == null;
                return cached;
            }


Instead we can use the `HashMap.putIfAbsent` to make code a bit easier to follow. We know that `requests` can contain only non-null values.

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

Commit messages:
 - [PATCH] Cleanup Map usage in AuthenticationInfo.requestAuthentication

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

PR: https://git.openjdk.java.net/jdk/pull/8484

From bpb at openjdk.java.net  Thu May 26 23:11:12 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 26 May 2022 23:11:12 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux
Message-ID: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>

Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

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

Commit messages:
 - 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux

Changes: https://git.openjdk.java.net/jdk/pull/8909/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287237
  Stats: 51 lines in 2 files changed: 37 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8909.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Fri May 27 12:23:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 27 May 2022 12:23:46 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <VaRLG79hIvorZLY5jIssupcPFV--P3prJvVL9br7tao=.07e2a299-8ec4-4fe7-b332-1d80eea122c6@github.com>

On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

src/java.base/share/classes/sun/net/www/MimeTable.java line 196:

> 194: 
> 195:         String ext = "";
> 196:         if (i != -1 && fname.charAt(i) == '.')

Nit - the existing method currently uses a `{` even for single line conditionals. Should we do the same for the new `if` blocks introduced in this PR and enclose them within  `{` `}`?

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Fri May 27 12:17:16 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 27 May 2022 12:17:16 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <seF314ERM2AymXtlr5KqxGbeJsx77nMzcAD4PsWnjmo=.f61e36e8-e09a-4223-9322-56f05fa0956e@github.com>

On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

src/java.base/share/classes/sun/net/www/MimeTable.java line 164:

> 162:     public MimeEntry findByFileName(String fname) {
> 163:         // attempt to find the entry with the fragment component removed
> 164:         MimeEntry entry = findByFileName(fname, true);

I think we might need a check here first to see if the `fname` contains `#` and if it does, only then call the `findByFileName` with `true`. Without that check, with the change in this PR, it's now possible that the `findByFileName` will get called twice (once with `true` and once with `false`) for the case where the filename doesn't have a `#` and whose extension isn't in the MimeTable.

src/java.base/share/classes/sun/net/www/MimeTable.java line 183:

> 181:      * @return the MIME entry associated with the file name
> 182:      */
> 183:     public MimeEntry findByFileName(String fname, boolean removeFragment) {

Hello Brian,

Perhaps this new method can be made `private` (and maybe even `static`)?

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Fri May 27 12:27:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 27 May 2022 12:27:45 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <9XbooopnuEtUralKt5CI16Sx_UBWvtlWZQzQqO65oCk=.0599bc3c-81d8-405a-bdef-ea794f2885a1@github.com>

On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

test/jdk/java/nio/file/Files/probeContentType/Basic.java line 197:

> 195:         String contentType = Files.probeContentType(pathWithFragement);
> 196:         if (contentType == null || !contentType.equals("image/png")) {
> 197:             System.out.printf("For %s expected \"png\" but got %s%n",

Should this instead use `System.err`, since the rest of the test uses that for printing these failures when incrementing the failure count.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Fri May 27 19:09:05 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 27 May 2022 19:09:05 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v2]
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <YxHPNmvpqtPc-xzuaray7oBVz_qWSpNm4w8cjuJaBLM=.63e4eff8-4932-4b3c-a712-13f19c9da313@github.com>

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

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

  8287237: Refactor and clean up

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8909/files
  - new: https://git.openjdk.java.net/jdk/pull/8909/files/64801e1b..eab33e80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=00-01

  Stats: 53 lines in 2 files changed: 19 ins; 12 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8909.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Fri May 27 19:09:08 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 27 May 2022 19:09:08 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v2]
In-Reply-To: <seF314ERM2AymXtlr5KqxGbeJsx77nMzcAD4PsWnjmo=.f61e36e8-e09a-4223-9322-56f05fa0956e@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <seF314ERM2AymXtlr5KqxGbeJsx77nMzcAD4PsWnjmo=.f61e36e8-e09a-4223-9322-56f05fa0956e@github.com>
Message-ID: <3s_0L36MSYzmK3T4utQztJkaHWDN6jZ_-fpXjLPlDAk=.aaf1e716-9d06-4155-8e22-2761bc5bb579@github.com>

On Fri, 27 May 2022 12:15:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287237: Refactor and clean up
>
> src/java.base/share/classes/sun/net/www/MimeTable.java line 164:
> 
>> 162:     public MimeEntry findByFileName(String fname) {
>> 163:         // attempt to find the entry with the fragment component removed
>> 164:         MimeEntry entry = findByFileName(fname, true);
> 
> I think we might need a check here first to see if the `fname` contains `#` and if it does, only then call the `findByFileName` with `true`. Without that check, with the change in this PR, it's now possible that the `findByFileName` will get called twice (once with `true` and once with `false`) for the case where the filename doesn't have a `#` and whose extension isn't in the MimeTable.

Methods refactored in eab33e8000ea730c57c918dbf291af23bacbd059.

> src/java.base/share/classes/sun/net/www/MimeTable.java line 183:
> 
>> 181:      * @return the MIME entry associated with the file name
>> 182:      */
>> 183:     public MimeEntry findByFileName(String fname, boolean removeFragment) {
> 
> Hello Brian,
> 
> Perhaps this new method can be made `private` (and maybe even `static`)?

Private yes, static no. Refactored in eab33e8000ea730c57c918dbf291af23bacbd059.

> test/jdk/java/nio/file/Files/probeContentType/Basic.java line 197:
> 
>> 195:         String contentType = Files.probeContentType(pathWithFragement);
>> 196:         if (contentType == null || !contentType.equals("image/png")) {
>> 197:             System.out.printf("For %s expected \"png\" but got %s%n",
> 
> Should this instead use `System.err`, since the rest of the test uses that for printing these failures when incrementing the failure count.

Yes, it should have used `System.err`; fixed in eab33e8000ea730c57c918dbf291af23bacbd059.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Sat May 28 14:42:29 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 28 May 2022 14:42:29 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v2]
In-Reply-To: <YxHPNmvpqtPc-xzuaray7oBVz_qWSpNm4w8cjuJaBLM=.63e4eff8-4932-4b3c-a712-13f19c9da313@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <YxHPNmvpqtPc-xzuaray7oBVz_qWSpNm4w8cjuJaBLM=.63e4eff8-4932-4b3c-a712-13f19c9da313@github.com>
Message-ID: <ecPYGd_Dp-tXkInCz9LyNGTq1P5w6CrZtUbzjhcERW8=.fa8c6d0d-99f9-42cf-88d2-21b1511d1ed3@github.com>

On Fri, 27 May 2022 19:09:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287237: Refactor and clean up

src/java.base/share/classes/sun/net/www/MimeTable.java line 188:

> 186:         int hashIndex = fname.lastIndexOf(HASH_MARK);
> 187:         if (hashIndex > 0) {
> 188:             String ext = getFileExtension(fname.substring(0, hashIndex - 1));

Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From duke at openjdk.java.net  Mon May 30 06:09:39 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 30 May 2022 06:09:39 GMT
Subject: RFR: 8272702: Resolving URI relative path with no / may lead to
 incorrect toString
In-Reply-To: <YsvFzHAWfY16bgcCXf23WEeVqXAVFwuzPdWWkKo5-h8=.9afd6cb6-c05b-4121-91ba-bb81a8e1d071@github.com>
References: <EYaKnK9p_ptDTRgORv2Dj0a2wRrrSvGo4RmjTCsetuM=.5ee4d026-e0a5-4404-87e0-1c8b1a2febee@github.com>
 <YsvFzHAWfY16bgcCXf23WEeVqXAVFwuzPdWWkKo5-h8=.9afd6cb6-c05b-4121-91ba-bb81a8e1d071@github.com>
Message-ID: <xvZgNqvcy-51GFj_G5sJcXxBsI8FB4OajM1R2otEJDw=.148fec30-4d2c-4361-a872-dbc16d680176@github.com>

On Thu, 26 May 2022 12:00:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You're using the wrong bugid. [JDK-8272707](https://bugs.openjdk.java.net/browse/JDK-8272707) has nothing to do with URI. Please use the correct bugid.

I'm sorry, I made a mistake.
JDK-8272702 is correct. I fixed it.

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

PR: https://git.openjdk.java.net/jdk/pull/8899

From ogillesp at amazon.co.uk  Tue May 31 10:38:20 2022
From: ogillesp at amazon.co.uk (Gillespie, Oli)
Date: Tue, 31 May 2022 11:38:20 +0100
Subject: CancelledKeyException during channel registration
Message-ID: <1fd841e5-54ab-366e-5d60-d373ee825c1b@amazon.co.uk>

Hi,

I noticed this surprising (to me) behaviour, and wonder whether it's 
expected or could be considered a bug. I'm not an expert in this area so 
apologies if this is trivial.

When registering a SocketChannel with a Selector for the first time, 
it's possible to get a CancelledKeyException even though this is the 
first register call.

Exception in thread "main" java.nio.channels.CancelledKeyException
     at 
java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:75)
     at 
java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:104)
     at java.base/sun.nio.ch.SelectorImpl.register(SelectorImpl.java:222)
     at 
java.base/java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:236)
     at 
java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260)
     at KeyCancelled.main(KeyCancelled.java:20)

The javadoc states:

@throws  CancelledKeyException
     If this channel is currently registered with the given selector
       but the corresponding key has already been cancelled

However in this case the channel is _not_ registered, as shown by 
SocketChannel.isRegistered() returning false.

This following sequence triggers this issue:

1. Thread 1 starts SelectableChannel.register
2. A new SelectionKey becomes visible via Selector.keys()
3. Thread 2 iterates Selector.keys() and calls SelectorKey.cancel()
4. Thread 1 (still in the register() invocation) finds that the key is 
cancelled and throws CancelledKeyException

Below is a small reproducer which usually exhibits this issue:

import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.SocketChannel;

public class KeyCancelled {
     public static void main(String[] args) throws Exception {
         Selector s = Selector.open();

         new Thread(() -> {
             for (int i = 0; i < 100_000; i++) {
                 s.keys().forEach(SelectionKey::cancel);
             }
         }).start();

         for (int i = 0; i < 10_000; i++) {
             SocketChannel c = s.provider().openSocketChannel();
             c.configureBlocking(false);
             // Sometimes this throws CancelledKeyException, because the 
key is cancelled by
             // the other thread part-way through the register call.
             c.register(s, SelectionKey.OP_READ);
             // c.isRegistered() is false here after the exceptional case
         }
     }
}

So, is this expected, a bug, or a gap in documentation?

Many thanks,

Oli



Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From dfuchs at openjdk.java.net  Tue May 31 14:58:24 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 31 May 2022 14:58:24 GMT
Subject: RFR: 8287318: ConcurrentModificationException in
 sun.net.httpserver.ServerImpl$Dispatcher
In-Reply-To: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
References: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
Message-ID: <vzE0K18ZyEJe-uCnEkIUgj1n_4k3HWUGJL576PRnxLo=.355f0f76-b372-45d9-890f-5d3d9fcd7547@github.com>

On Thu, 26 May 2022 07:17:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.java.net/browse/JDK-8287318?
> 
> The `ServerImpl` has a `Dispatcher` thread which uses a `Selector` to select keys of interested. The selected keys is then iterated over and each key is removed through the iterator. This is fine as long as the selector isn't then used to invoke select operation(s) while the iterator is still in use. Doing so leads to the underlying Set being potentially modified with updates to the selected keys. As a result any subsequent use of the iterator will lead to `ConcurrentModificationException` as seen in the linked issue.
> 
> The commit here fixes that by creating a copy of the selected keys and iterating over it so that any subsequent select operation on the selector won't have impact on the Set that is being iterated upon. 
> 
> No new tests have been added given the intermittent nature of this issue. Existing tier1, tier2 and tier3 tests passed without any related failures, after this change.

Marked as reviewed by dfuchs (Reviewer).

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 384:

> 382:                     final Set<SelectionKey> copy = new HashSet<>(selected);
> 383:                     // iterate over the copy
> 384:                     for (final SelectionKey key : copy) {

Another possibility would be to call toArray() - since we're simply going to iterate we don't need a full copy of the hashset - e.g.: `for (var key : selected.toArray(SelectionKey[]::new)) {`

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

PR: https://git.openjdk.java.net/jdk/pull/8898

From Alan.Bateman at oracle.com  Tue May 31 15:00:21 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 May 2022 16:00:21 +0100
Subject: CancelledKeyException during channel registration
In-Reply-To: <1fd841e5-54ab-366e-5d60-d373ee825c1b@amazon.co.uk>
References: <1fd841e5-54ab-366e-5d60-d373ee825c1b@amazon.co.uk>
Message-ID: <c3ce67d1-2aa5-2a56-6aae-f68f097dfdba@oracle.com>


Moving to the nio-dev list.

Registration is not an atomic operation. The channel is registered (this 
creates the selection key) and then the key's interest set is changed. 
If I read your test case correctly, it is cancelling the key before the 
key's interest set is changed and this leads to the CancelledKeyException.

Yes, I agree this may be surprising. Can you submit a bug for this?

-Alan

On 31/05/2022 11:38, Gillespie, Oli wrote:
> Hi,
>
> I noticed this surprising (to me) behaviour, and wonder whether it's 
> expected or could be considered a bug. I'm not an expert in this area 
> so apologies if this is trivial.
>
> When registering a SocketChannel with a Selector for the first time, 
> it's possible to get a CancelledKeyException even though this is the 
> first register call.
>
> Exception in thread "main" java.nio.channels.CancelledKeyException
> ??? at 
> java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:75)
> ??? at 
> java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:104)
> ??? at java.base/sun.nio.ch.SelectorImpl.register(SelectorImpl.java:222)
> ??? at 
> java.base/java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:236)
> ??? at 
> java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260)
> ??? at KeyCancelled.main(KeyCancelled.java:20)
>
> The javadoc states:
>
> @throws? CancelledKeyException
> ??? If this channel is currently registered with the given selector
> ????? but the corresponding key has already been cancelled
>
> However in this case the channel is _not_ registered, as shown by 
> SocketChannel.isRegistered() returning false.
>
> This following sequence triggers this issue:
>
> 1. Thread 1 starts SelectableChannel.register
> 2. A new SelectionKey becomes visible via Selector.keys()
> 3. Thread 2 iterates Selector.keys() and calls SelectorKey.cancel()
> 4. Thread 1 (still in the register() invocation) finds that the key is 
> cancelled and throws CancelledKeyException
>
> Below is a small reproducer which usually exhibits this issue:
>
> import java.nio.channels.SelectionKey;
> import java.nio.channels.Selector;
> import java.nio.channels.SocketChannel;
>
> public class KeyCancelled {
> ??? public static void main(String[] args) throws Exception {
> ??????? Selector s = Selector.open();
>
> ??????? new Thread(() -> {
> ??????????? for (int i = 0; i < 100_000; i++) {
> ??????????????? s.keys().forEach(SelectionKey::cancel);
> ??????????? }
> ??????? }).start();
>
> ??????? for (int i = 0; i < 10_000; i++) {
> ??????????? SocketChannel c = s.provider().openSocketChannel();
> ??????????? c.configureBlocking(false);
> ??????????? // Sometimes this throws CancelledKeyException, because 
> the key is cancelled by
> ??????????? // the other thread part-way through the register call.
> ??????????? c.register(s, SelectionKey.OP_READ);
> ??????????? // c.isRegistered() is false here after the exceptional case
> ??????? }
> ??? }
> }
>
> So, is this expected, a bug, or a gap in documentation?
>
> Many thanks,
>
> Oli
>
>
>
> Amazon Development Centre (London) Ltd. Registered in England and 
> Wales with registration number 04543232 with its registered office at 
> 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
>
>


From jpai at openjdk.java.net  Tue May 31 15:14:22 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 31 May 2022 15:14:22 GMT
Subject: RFR: 8287318: ConcurrentModificationException in
 sun.net.httpserver.ServerImpl$Dispatcher [v2]
In-Reply-To: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
References: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
Message-ID: <tj-sx0BjGfcqM0aXJ6kp9bJSw83UmQNzuUjVWKhtsAw=.b2d00936-b63c-42a0-9a10-6aa92177ef67@github.com>

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.java.net/browse/JDK-8287318?
> 
> The `ServerImpl` has a `Dispatcher` thread which uses a `Selector` to select keys of interested. The selected keys is then iterated over and each key is removed through the iterator. This is fine as long as the selector isn't then used to invoke select operation(s) while the iterator is still in use. Doing so leads to the underlying Set being potentially modified with updates to the selected keys. As a result any subsequent use of the iterator will lead to `ConcurrentModificationException` as seen in the linked issue.
> 
> The commit here fixes that by creating a copy of the selected keys and iterating over it so that any subsequent select operation on the selector won't have impact on the Set that is being iterated upon. 
> 
> No new tests have been added given the intermittent nature of this issue. Existing tier1, tier2 and tier3 tests passed without any related failures, after this change.

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

  Use Collection.toArray(...) instead of creating a copy of the collection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8898/files
  - new: https://git.openjdk.java.net/jdk/pull/8898/files/ee963c3a..2287844e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8898&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8898&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8898

From dfuchs at openjdk.java.net  Tue May 31 15:14:22 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 31 May 2022 15:14:22 GMT
Subject: RFR: 8287318: ConcurrentModificationException in
 sun.net.httpserver.ServerImpl$Dispatcher [v2]
In-Reply-To: <tj-sx0BjGfcqM0aXJ6kp9bJSw83UmQNzuUjVWKhtsAw=.b2d00936-b63c-42a0-9a10-6aa92177ef67@github.com>
References: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
 <tj-sx0BjGfcqM0aXJ6kp9bJSw83UmQNzuUjVWKhtsAw=.b2d00936-b63c-42a0-9a10-6aa92177ef67@github.com>
Message-ID: <4EunV6Bmg_8wWzxPpE8SY7hegQwbv3t1zmFSvozTSxg=.035f0cb8-2e65-4d22-9daf-792703af4479@github.com>

On Tue, 31 May 2022 15:11:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.java.net/browse/JDK-8287318?
>> 
>> The `ServerImpl` has a `Dispatcher` thread which uses a `Selector` to select keys of interested. The selected keys is then iterated over and each key is removed through the iterator. This is fine as long as the selector isn't then used to invoke select operation(s) while the iterator is still in use. Doing so leads to the underlying Set being potentially modified with updates to the selected keys. As a result any subsequent use of the iterator will lead to `ConcurrentModificationException` as seen in the linked issue.
>> 
>> The commit here fixes that by creating a copy of the selected keys and iterating over it so that any subsequent select operation on the selector won't have impact on the Set that is being iterated upon. 
>> 
>> No new tests have been added given the intermittent nature of this issue. Existing tier1, tier2 and tier3 tests passed without any related failures, after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Collection.toArray(...) instead of creating a copy of the collection

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8898

From jpai at openjdk.java.net  Tue May 31 15:14:23 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 31 May 2022 15:14:23 GMT
Subject: RFR: 8287318: ConcurrentModificationException in
 sun.net.httpserver.ServerImpl$Dispatcher [v2]
In-Reply-To: <vzE0K18ZyEJe-uCnEkIUgj1n_4k3HWUGJL576PRnxLo=.355f0f76-b372-45d9-890f-5d3d9fcd7547@github.com>
References: <ElHAczMVn8EWXIwIpLAtzuwyL6IwFtbvMDIx00vmqsk=.00d6925d-2d89-4047-9ea9-841b850687e2@github.com>
 <vzE0K18ZyEJe-uCnEkIUgj1n_4k3HWUGJL576PRnxLo=.355f0f76-b372-45d9-890f-5d3d9fcd7547@github.com>
Message-ID: <xOTkzyta8joQPd-ziJHPIuacwvYevfhHqaLqHi6rVB4=.e0cc712f-5d4b-4758-b177-a95da75ee4d8@github.com>

On Tue, 31 May 2022 14:51:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Collection.toArray(...) instead of creating a copy of the collection
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 384:
> 
>> 382:                     final Set<SelectionKey> copy = new HashSet<>(selected);
>> 383:                     // iterate over the copy
>> 384:                     for (final SelectionKey key : copy) {
> 
> Another possibility would be to call toArray() - since we're simply going to iterate we don't need a full copy of the hashset - e.g.: `for (var key : selected.toArray(SelectionKey[]::new)) {`

That's a good idea. I've now updated the PR to use this suggestion.

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

PR: https://git.openjdk.java.net/jdk/pull/8898

From bpb at openjdk.java.net  Tue May 31 16:45:32 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 16:45:32 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v2]
In-Reply-To: <ecPYGd_Dp-tXkInCz9LyNGTq1P5w6CrZtUbzjhcERW8=.fa8c6d0d-99f9-42cf-88d2-21b1511d1ed3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <YxHPNmvpqtPc-xzuaray7oBVz_qWSpNm4w8cjuJaBLM=.63e4eff8-4932-4b3c-a712-13f19c9da313@github.com>
 <ecPYGd_Dp-tXkInCz9LyNGTq1P5w6CrZtUbzjhcERW8=.fa8c6d0d-99f9-42cf-88d2-21b1511d1ed3@github.com>
Message-ID: <Ww9D_ix1wITjur07pwtWAySB_u2Nx8Axe-zAGj6mCzE=.097e827d-7742-4bab-bcdd-05f7477a1d98@github.com>

On Sat, 28 May 2022 14:39:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287237: Refactor and clean up
>
> src/java.base/share/classes/sun/net/www/MimeTable.java line 188:
> 
>> 186:         int hashIndex = fname.lastIndexOf(HASH_MARK);
>> 187:         if (hashIndex > 0) {
>> 188:             String ext = getFileExtension(fname.substring(0, hashIndex - 1));
> 
> Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case.

I agree. I saw that myself. As nothing seems broken I did not want to touch it but I will investigate.

> src/java.base/share/classes/sun/net/www/MimeTable.java line 196:
> 
>> 194: 
>> 195:         String ext = "";
>> 196:         if (i != -1 && fname.charAt(i) == '.')
> 
> Nit - the existing method currently uses a `{` even for single line conditionals. Should we do the same for the new `if` blocks introduced in this PR and enclose them within  `{` `}`?

Fixed in eab33e8000ea730c57c918dbf291af23bacbd059.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Tue May 31 18:13:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 18:13:35 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v3]
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <KLwadEbvvwjjbnfHgqZ0RnxeGB2HWkvzdw3-L0taH5g=.4eb9d4c4-2cc2-413f-8541-ccb5de8faa51@github.com>

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

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

  8287237: Correct off-by-one endIndex passed to String.substring()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8909/files
  - new: https://git.openjdk.java.net/jdk/pull/8909/files/eab33e80..7c877f9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Tue May 31 18:13:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 18:13:36 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v2]
In-Reply-To: <Ww9D_ix1wITjur07pwtWAySB_u2Nx8Axe-zAGj6mCzE=.097e827d-7742-4bab-bcdd-05f7477a1d98@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <YxHPNmvpqtPc-xzuaray7oBVz_qWSpNm4w8cjuJaBLM=.63e4eff8-4932-4b3c-a712-13f19c9da313@github.com>
 <ecPYGd_Dp-tXkInCz9LyNGTq1P5w6CrZtUbzjhcERW8=.fa8c6d0d-99f9-42cf-88d2-21b1511d1ed3@github.com>
 <Ww9D_ix1wITjur07pwtWAySB_u2Nx8Axe-zAGj6mCzE=.097e827d-7742-4bab-bcdd-05f7477a1d98@github.com>
Message-ID: <R5iwLCFHaBUUC6Pu0VT1pCtVIn0O8GozPN2L6mNE-RU=.899e9bed-0871-4c11-88a4-e8f978b1b5ea@github.com>

On Tue, 31 May 2022 16:41:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/MimeTable.java line 188:
>> 
>>> 186:         int hashIndex = fname.lastIndexOf(HASH_MARK);
>>> 187:         if (hashIndex > 0) {
>>> 188:             String ext = getFileExtension(fname.substring(0, hashIndex - 1));
>> 
>> Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case.
>
> I agree. I saw that myself. As nothing seems broken I did not want to touch it but I will investigate.

This was probably never caught because all our Linux machines seem to have `/etc/mime.types`.

Fixed by 7c877f9ee2a0788849bac4d64a4ab4c89cbc9e0c.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Tue May 31 18:29:30 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 18:29:30 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v4]
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

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

  8287237: Simplify code a bit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8909/files
  - new: https://git.openjdk.java.net/jdk/pull/8909/files/7c877f9e..b9eb7bbb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=02-03

  Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8909.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909

PR: https://git.openjdk.java.net/jdk/pull/8909

From rriggs at openjdk.java.net  Tue May 31 19:31:42 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 19:31:42 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v4]
In-Reply-To: <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
Message-ID: <WtznhbiCdPCLtBtCvUJQ70FS1RT64-fDOU2_e837Ero=.4ee30f55-87be-47a4-a2cb-53609452294d@github.com>

On Tue, 31 May 2022 18:29:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287237: Simplify code a bit

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8909