From duke at openjdk.org  Tue Nov  1 04:13:30 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 1 Nov 2022 04:13:30 GMT
Subject: RFR: 8051627: Invariants about java.net.URI resolve and relativize
 are wrong [v2]
In-Reply-To: <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
References: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
 <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
Message-ID: <PaEAzKLOy3Vr1MyfWMk40e0ax4dZEe7O2PnK-bmlSFI=.204c80fa-17cf-46c4-94dd-cd00a50d83cf@github.com>

On Fri, 16 Sep 2022 07:20:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> The current documentation of URI class describes relationship between resolve and relativize methods as follows.
>> 
>> 
>> For any two normalized URIs u and v,
>>     u.relativize(u.resolve(v)).equals(v) and
>>     u.resolve(u.relativize(v)).equals(v) .
>> 
>> 
>> However, there are some cases where this relationship is not true. For example, when u and v are "http://a/b" and "c/d", respectively, both u.relativize(u.resolve(v)) and u.resolve(u.relativize(v)) equal to "http://a/c/d" not "c/d". The documentation should be updated to avoid confusion by describing the relationship between resolve nd relativize methods under certain conditions of the URI. Note that these conditions are sufficient but not necessary for the statement.
>
> KIRIYAMA Takuya 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:
> 
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - Merge branch 'master' into 8051627
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong

This pull request is waiting for the CSR.

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

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

From alanb at openjdk.org  Tue Nov  1 06:52:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 06:52:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ?
> 
> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ?

Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think.

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

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

From peter.firmstone at zeus.net.au  Tue Nov  1 08:07:11 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 1 Nov 2022 19:07:11 +1100
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
 <WcaCqHpq45F2qY76oFo0vLzQ7I6dEY0pi13gFttR6Qs=.5d8e2bfd-f1be-4042-bb87-cfab195c06fd@github.com>
Message-ID: <bdecb2f9-b1a9-332f-58a2-4ff0ce75706c@zeus.net.au>

On 1/11/2022 5:52 pm, Alan Bateman wrote:
> On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:
>
>> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ?
>>
>> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ?
> Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think.

We found there were some common cases, we made static convenience 
methods to address them:

Fix MS Windows file URI strings, by converting back slashes to forward 
slashes and inserting a forward slash before the drive letter if missing.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L289

Convert java.io.File to Uri, ensure compatibility with URLClassLoader, 
when trailing directory character is dropped by java.io.File.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L341

Escape illegal characters when string doesn't contain any existing 
escape sequences.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L926

Parse and fix a string that contains escaped sequences, any illegal 
characters are escaped and any that should't be escaped are un-escaped.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L939

Convert java.net.URL to Uri, automatically fixing MS Windows URI syntax.

https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L324

Cheers,

Peter.


>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Tue Nov  1 11:46:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 11:46:46 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently
Message-ID: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>

The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.

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

Commit messages:
 - 8295991

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

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

From dfuchs at openjdk.org  Tue Nov  1 13:53:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>
Message-ID: <YyjbpXQ4Nu8hejOV6lg2bwd-Hfk3-9MEAIUuyCKS3cM=.9e689d36-46fd-4f84-8da0-85dd682196bf@github.com>

On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race <prr at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use java.net.URI to parse or construct any URL. ... To construct a URL, using URI::toURL should be preferred.
> 
> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ?
> 
> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ?

Possibly yes. Using URI where it was not used before might cause some behavioral changes, that would need to be examined and possibly documented through separate CSRs. This is better handled on a case-by-case basis
for each area affected. The changes as currently proposed will not lead to any behavioral difference.

> 
> And what about Peter Firmstone's comment "We stopped using java.net.URI some years ago as it's obsolete.?"
> 
> I can't reconcile that with the recommendation to use it ..

URI implements RFC 2396 with some deviations, noted in its API documentation, which make it a crossbreed between RFC 2396 and RFC 3986. As Alan noted earlier, changing URI to strictly implement RFC 3986 is not a compatible move: it was attempted in JDK 6 but had to backed out quickly as it caused widespread breakage. But even if it doesn't implement the latest RFC strictly, it's still a much more modern API and implementation than java.net.URL.

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

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

From dfuchs at openjdk.org  Tue Nov  1 13:53:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 13:53:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <GCXHo9bR0jQRKe-qvdgEDkPzvc0zgS6sIlTQ-PiWzmA=.fd82872c-c1c5-4ffa-b602-a4bc60bedc19@github.com>

On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman <alanb 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 four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 885:
> 
>> 883: 
>> 884:             @SuppressWarnings("deprecation")
>> 885:             var result = new URL("jrt", host, port, file, null);
> 
> The URL scheme for jrt does not have a port so we should look at that some time.

Noted.

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:00:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:00:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <nB3e9AXOx2rm5qSOhYjm7XRQn4wvLkt2y4VckMIziCY=.95686450-68bc-4d3d-9956-ab722063f00d@github.com>

On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman <alanb 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 four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 157:
> 
>> 155:  * The URL constructors are specified to throw
>> 156:  * {@link MalformedURLException} but the actual parsing/validation
>> 157:  * that are performed is implementation dependent. Some parsing/validation
> 
> "the ... are performed" -> "the ... is performed".

done

> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)
> 
> The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

done

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:08:17 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:08:17 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <qCuvc99MQHsNXJh946nVOGlDNWoK-k-iahtS18-I8v4=.ee61f634-b6d1-46c2-9084-2df739c76d9f@github.com>

On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman <alanb 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 four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 166:
> 
>> 164:  * The {@code java.net.URL} constructors are deprecated.
>> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
>> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 
> "any URL" -> "a URL" or "all URLs".

done

> src/java.base/share/classes/java/net/URL.java line 168:
> 
>> 166:  * or construct any {@code URL}. In cases where an instance of {@code
>> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
>> 168:  * to construct or parse the URL string, possibly calling {@link
> 
> I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

I don't believe it would be syntactically correct to put it in all lower case since URL is an acronym.  I could replace it with "URI string" instead but I'm not sure it would be better. What do you think?

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:12:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:12:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
Message-ID: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>

On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman <alanb 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 four additional commits since the last revision:
>> 
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 133:
> 
>> 131:  * specified. The optional fragment is not inherited.
>> 132:  *
>> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>
> 
> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:26:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:26:09 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
Message-ID: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>

On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 133:
>> 
>>> 131:  * specified. The optional fragment is not inherited.
>>> 132:  *
>>> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>
>> 
>> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?
>
> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.

Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

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

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

From alanb at openjdk.org  Tue Nov  1 14:51:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 14:51:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
Message-ID: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>

On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`.
>
> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?

Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

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

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

From dfuchs at openjdk.org  Tue Nov  1 16:14:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:20 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

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 six additional commits since the last revision:

 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/fd4ca287..f6b8a9f9

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

  Stats: 3893 lines in 203 files changed: 2469 ins; 611 del; 813 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

From prr at openjdk.org  Tue Nov  1 16:14:21 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 1 Nov 2022 16:14:21 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <aRKJABG81VEtvU3_sEh-c0yfIQ8SDYp0PFm_TSTRV_M=.2f254387-cd5a-4309-81c0-8a240ef8ecc4@github.com>

On Tue, 1 Nov 2022 16:10:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Marked as reviewed by prr (Reviewer).

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

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

From dfuchs at openjdk.org  Tue Nov  1 16:14:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:14:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
 <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>
 <xTEFJ-2HYch3R_ZjyR1oo4yUu24fxhnrAM_D3-KlhDA=.26ddea24-e79d-4c46-af81-56ae148f8dbf@github.com>
 <Y55oC1sMHny5zsZZYC7wvZeI_9Wmw4a8BZ2QfzEDqnI=.98a9a873-6868-4545-b71a-2058cd4d8103@github.com>
 <EK7M5e8eQsmbH8O19cOo_qeRJlIZZ5UaCklfSj9f_u8=.2998cf4d-67de-440f-8e2a-e2440a399560@github.com>
Message-ID: <2jUuJ4BHyWYygw4wAlZbgMBsxCyVgAOfhNFPl31yKLY=.5c5e0a58-e270-4e95-8cb6-d0c5f7a3bc23@github.com>

On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the &lt;h2&gt; title? Would that be better?
>
> Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message.

Done.

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

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

From jpai at openjdk.org  Wed Nov  2 05:08:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Nov 2022 05:08:16 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently
In-Reply-To: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
Message-ID: <ePV8QDaLaRl9Nb6ZlZMCY5MUXu4iy7hT5_IfDhgza60=.11fc6693-20fb-465a-b8f8-bf423a57b840@github.com>

On Tue, 1 Nov 2022 11:39:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
> Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.

test/jdk/java/net/httpclient/CancelRequestTest.java line 382:

> 380:             assertEquals(latch.getCount(), 0);
> 381: 
> 382:             var error = TRACKER.check(100,

Hello Daniel, looking at the implementation in the `check` method of `ReferenceTracker`, it has this:


public AssertionError check(long graceDelayMs,
                            Predicate<Tracker> hasOutstanding,
                            String description,
                            boolean printThreads) {
    AssertionError fail = null;
    graceDelayMs = Math.max(graceDelayMs, 100);
...

So, even when we were passing it `1` milli seconds as a grace delay, it was changing it to `100` milli seconds. So I suspect the change in this PR won't have the intended effect since it would still wait the same amount of time and would potentially continue to have intermittent failures.

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

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

From duke at openjdk.org  Wed Nov  2 08:18:31 2022
From: duke at openjdk.org (duke)
Date: Wed, 2 Nov 2022 08:18:31 GMT
Subject: Withdrawn: 8281236: (D)TLS key exchange named groups
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <fF4XbSOh53FKyydsN_eEP17MSLqC79LkNTAhAn2cWMQ=.c92d1676-636e-4f78-8e13-021dc1546986@github.com>

On Fri, 5 Aug 2022 14:57:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

This pull request has been closed without being integrated.

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

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

From dfuchs at openjdk.org  Wed Nov  2 11:47:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 11:47:20 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently
In-Reply-To: <ePV8QDaLaRl9Nb6ZlZMCY5MUXu4iy7hT5_IfDhgza60=.11fc6693-20fb-465a-b8f8-bf423a57b840@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
 <ePV8QDaLaRl9Nb6ZlZMCY5MUXu4iy7hT5_IfDhgza60=.11fc6693-20fb-465a-b8f8-bf423a57b840@github.com>
Message-ID: <YUitg6QlAYL1_gK0NuqK_llrTkzWQp58_svoc4ntq98=.5140aac4-e2a2-41ad-b594-d97aaa047ba1@github.com>

On Wed, 2 Nov 2022 05:04:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
>> Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.
>
> test/jdk/java/net/httpclient/CancelRequestTest.java line 382:
> 
>> 380:             assertEquals(latch.getCount(), 0);
>> 381: 
>> 382:             var error = TRACKER.check(100,
> 
> Hello Daniel, looking at the implementation in the `check` method of `ReferenceTracker`, it has this:
> 
> 
> public AssertionError check(long graceDelayMs,
>                             Predicate<Tracker> hasOutstanding,
>                             String description,
>                             boolean printThreads) {
>     AssertionError fail = null;
>     graceDelayMs = Math.max(graceDelayMs, 100);
> ...
> 
> So, even when we were passing it `1` milli seconds as a grace delay, it was changing it to `100` milli seconds. So I suspect the change in this PR won't have the intended effect since it would still wait the same amount of time and would potentially continue to have intermittent failures.

Ah! Good catch.

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

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

From alanb at openjdk.org  Wed Nov  2 12:22:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Nov 2022 12:22:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <Qnv25No1OKTGQ8SRg0TCExRCbZB5h0Izs5vhqAWDTAQ=.66d04bd1-9cb0-4b92-b2ae-a27ee3d8c24d@github.com>

On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.org  Wed Nov  2 12:34:58 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 12:34:58 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently [v2]
In-Reply-To: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
Message-ID: <0iRuBSS1DLkP1Io16eXqCR-YukyWLncmGagInWgy2bc=.fca1c3f3-ed42-4c04-ab67-51c8122e95af@github.com>

> The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
> Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.

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 cancel-request-test-8295991
 - Narrow down tracking to the client used by the test. Increase timeout.
 - 8295991

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10931/files
  - new: https://git.openjdk.org/jdk/pull/10931/files/9631fbe2..a7d400b0

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

  Stats: 3859 lines in 203 files changed: 2456 ins; 592 del; 811 mod
  Patch: https://git.openjdk.org/jdk/pull/10931.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10931/head:pull/10931

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

From dfuchs at openjdk.org  Wed Nov  2 13:51:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 13:51:43 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently [v2]
In-Reply-To: <YUitg6QlAYL1_gK0NuqK_llrTkzWQp58_svoc4ntq98=.5140aac4-e2a2-41ad-b594-d97aaa047ba1@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
 <ePV8QDaLaRl9Nb6ZlZMCY5MUXu4iy7hT5_IfDhgza60=.11fc6693-20fb-465a-b8f8-bf423a57b840@github.com>
 <YUitg6QlAYL1_gK0NuqK_llrTkzWQp58_svoc4ntq98=.5140aac4-e2a2-41ad-b594-d97aaa047ba1@github.com>
Message-ID: <jNlJpxRmJ92BPK3I7wB60OduPAd7HLAlo33nqbGfKg0=.3bdd3e6b-6e78-4765-a99f-aeb19cbea80b@github.com>

On Wed, 2 Nov 2022 11:43:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/CancelRequestTest.java line 382:
>> 
>>> 380:             assertEquals(latch.getCount(), 0);
>>> 381: 
>>> 382:             var error = TRACKER.check(100,
>> 
>> Hello Daniel, looking at the implementation in the `check` method of `ReferenceTracker`, it has this:
>> 
>> 
>> public AssertionError check(long graceDelayMs,
>>                             Predicate<Tracker> hasOutstanding,
>>                             String description,
>>                             boolean printThreads) {
>>     AssertionError fail = null;
>>     graceDelayMs = Math.max(graceDelayMs, 100);
>> ...
>> 
>> So, even when we were passing it `1` milli seconds as a grace delay, it was changing it to `100` milli seconds. So I suspect the change in this PR won't have the intended effect since it would still wait the same amount of time and would potentially continue to have intermittent failures.
>
> Ah! Good catch.

I have uploaded a new version - using 200ms instead on 100ms, and simply looking at the specific client that has been used for the operation (instead of looking at *all* of them).

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

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

From jpai at openjdk.org  Wed Nov  2 14:42:28 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Nov 2022 14:42:28 GMT
Subject: RFR: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently [v2]
In-Reply-To: <0iRuBSS1DLkP1Io16eXqCR-YukyWLncmGagInWgy2bc=.fca1c3f3-ed42-4c04-ab67-51c8122e95af@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
 <0iRuBSS1DLkP1Io16eXqCR-YukyWLncmGagInWgy2bc=.fca1c3f3-ed42-4c04-ab67-51c8122e95af@github.com>
Message-ID: <q-bV-tPMcXFno_YedZZht1Dn1QlULc4YlDa2IizGFnw=.6f22129a-9c84-41a6-9306-29f7630cc282@github.com>

On Wed, 2 Nov 2022 12:34:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
>> Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.
>
> 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 cancel-request-test-8295991
>  - Narrow down tracking to the client used by the test. Increase timeout.
>  - 8295991

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

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

From dfuchs at openjdk.org  Wed Nov  2 15:34:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 15:34:31 GMT
Subject: Integrated: 8295991: java/net/httpclient/CancelRequestTest.java fails
 intermittently
In-Reply-To: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
References: <OsIzdPzT3awpkZPm4h0mJuE_V5LJcJJm5pPphF0uIB8=.be845946-b6d0-4be8-b070-32d36f5a51c5@github.com>
Message-ID: <burFZjzUQZevQHB8iBr4VUY9mbbCS9Mn_fpH8OyU63I=.cc66815a-edf9-46d1-bac9-ae447d1ee873@github.com>

On Tue, 1 Nov 2022 11:39:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The CancelRequestTest test has been observed failing (once). It was recently updated to verify that subscribers would be correctly unregistered after the request was cancelled. However, the timeout used to wait for that to happen was optimistically too short: the test code that cancels the request is by design racy, so it's not guaranteed that the subscriber will be unregistered before the completable future is cancelled, it might get unregistered asynchronously shortly after.
> Increasing the timeout to wait for that to happen from 1ms to 100ms fixes the test issue.

This pull request has now been integrated.

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

8295991: java/net/httpclient/CancelRequestTest.java fails intermittently

Reviewed-by: jpai

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

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

From duke at openjdk.org  Thu Nov  3 07:49:28 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Nov 2022 07:49:28 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
Message-ID: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>

On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> 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 six additional commits since the last revision:
> 
>  - Integrated review feedback
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Since?these are?in?the?same compilation?unit as?the?deprecated `URL`?constructors, `@SuppressWarnings("deprecation")` isn?t?needed:

src/java.base/share/classes/java/net/URL.java line 885:

> 883:             @SuppressWarnings("deprecation")
> 884:             var result = new URL("jrt", host, port, file, null);
> 885:             return result;

Suggestion:

            return new URL("jrt", host, port, file, null);

src/java.base/share/classes/java/net/URL.java line 909:

> 907:         @SuppressWarnings("deprecation")
> 908:         var result = new URL((URL)null, uri.toString(), handler);
> 909:         return result;

Suggestion:

        return new URL((URL)null, uri.toString(), handler);

src/java.base/share/classes/java/net/URL.java line 1833:

> 1831:         try {
> 1832:             @SuppressWarnings("deprecation")
> 1833:             var _unused = replacementURL = new URL(urlString);

Suggestion:

            replacementURL = new URL(urlString);

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:03 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:03 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

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

 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/f6b8a9f9..fc899005

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

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

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

From michaelm at openjdk.org  Thu Nov  3 11:20:04 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 11:20:04 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>

On Thu, 3 Nov 2022 10:56:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/java/net/URL.java line 152:

> 150:  * provide any guarantee about its conformance to the URL
> 151:  * syntax specification.
> 152:  * <p>

I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?

Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:05 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:05 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
 <tY6LYFbtKEWF9F45Jdscn4HNYUOdnmwJXy6z1GV7HSU=.0a43565a-bee7-42e2-82d9-11d60fb750af@github.com>
Message-ID: <f6KQGfu1BOAUMUam_LwZTp88-8NX2-I6d4Ku2d4LJ3U=.e9a5ef53-afa7-4163-bd4b-1260e7ebc2ef@github.com>

On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/URL.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/URL.java line 152:
> 
>> 150:  * provide any guarantee about its conformance to the URL
>> 151:  * syntax specification.
>> 152:  * <p>
> 
> I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)?
> 
> Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical.

That would better go in URL::toURI I think - but AFAICS would only apply if you constructed the URL from one of the deprecated constructors. It's not a bad idea - but given that the CSR has been approved I'd rather track that in a follow up PR.

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

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

From dfuchs at openjdk.org  Thu Nov  3 11:20:08 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 11:20:08 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v3]
In-Reply-To: <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com>
 <tI2-JzeuxPBx0ZVLvOQnAb7HUJp743B4cOSYSfdH30A=.2d4bbcb1-a04d-42b2-9d2a-167593ce3739@github.com>
Message-ID: <JPqOXDD-OIUnBfjasVY1YXwf6cN-Vknvd4XhDEXJDvI=.7c24b554-eff1-47de-8db2-898439de2338@github.com>

On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss <duke 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 six additional commits since the last revision:
>> 
>>  - Integrated review feedback
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>>  - Merge branch 'master' into deprecate-url-ctor-8294241
>>  - Fix whitespace issues
>>  - 8294241
>
> src/java.base/share/classes/java/net/URL.java line 885:
> 
>> 883:             @SuppressWarnings("deprecation")
>> 884:             var result = new URL("jrt", host, port, file, null);
>> 885:             return result;
> 
> Suggestion:
> 
>             return new URL("jrt", host, port, file, null);

Ah ! Good point thanks! I have accepted your suggestions.

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

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

From aefimov at openjdk.org  Thu Nov  3 13:05:33 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 3 Nov 2022 13:05:33 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <k_5J1gI_C0W-b_WcMMG6Rf71Bxu-rLiTzonaEiDtXTU=.5a547097-d335-42bc-bb3b-dd970135a666@github.com>

On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

`java.naming` changes looks reasonable to me. Thanks!

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

Marked as reviewed by aefimov (Committer).

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

From michaelm at openjdk.org  Thu Nov  3 15:10:37 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 3 Nov 2022 15:10:37 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v4]
In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com>
Message-ID: <VIPkTGY5ZJNqBRiHcqesQQOdR3wuw_MR6KIKUm6TGeg=.802cdd63-df58-4c2e-bf83-049e4018021d@github.com>

On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/URL.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by michaelm (Reviewer).

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

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

From dfuchs at openjdk.org  Thu Nov  3 15:52:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 15:52:53 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v5]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <BkNpz5wPrxpFJDaE0AzRWyRnG2r8B5qdEgm32zDE3Dw=.32ed243e-d406-4296-86bc-847aaa9d9a06@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

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 10 additional commits since the last revision:

 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/URL.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Integrated review feedback
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/fc899005..b4a73f40

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

  Stats: 42853 lines in 291 files changed: 10793 ins; 30812 del; 1248 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

From ccleary at openjdk.org  Thu Nov  3 16:28:08 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 3 Nov 2022 16:28:08 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
Message-ID: <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>

> **Issue**
> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
> 
> **Proposed Solution**
> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.

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

  8288717: IdleConnectionTimeout can use Keep Alive or Custom Value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10183/files
  - new: https://git.openjdk.org/jdk/pull/10183/files/5394f815..24c57157

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

  Stats: 61 lines in 4 files changed: 36 ins; 10 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10183.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10183/head:pull/10183

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

From ccleary at openjdk.org  Thu Nov  3 16:41:36 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 3 Nov 2022 16:41:36 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
Message-ID: <3CkXDu2gZzPjCCjNGnR5Tm0_sMa3WKFEqkDm5vFryeE=.025c4d92-dd08-4e0d-9942-c611335fb029@github.com>

On Thu, 3 Nov 2022 16:28:08 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: IdleConnectionTimeout can use Keep Alive or Custom Value

A summary of the most recent changes to this PR.

1. shutdown() in Http2Connection is returned to its original form. The existing code there is sufficient to log the idleConnectionTimeoutEvent once it fires.
2. ConnectionPool now gets it's Keep-Alive Timeout Value from HttpClientImpl using the `jdk.httpclient.keepalive.timeout` property. As well as this, the idleConnectionTimeoutEvent also gets its value from the same KeepAlive property. However, if the developer wishes to use different timeout values for HTTP/1 vs HTTP/2, they can use the new `jdk.httpclient.keepalive.timeout.h2` property to specify this.
3. getTimeoutProp() was added to HttpClientImpl to account for erroneous input possibly given to either the Keep-Alive or Idle Conection Timout Values.
4. The test has been changed to reflect the above two changes and to test for erroneous input. When input is erroneous, default values are used.

One thing I would like to discuss here is the naming of the property used to override the value passed to the IdleConnectionTimeoutEvent as mentioned in the second point above. Perhaps something more meaningful to http2 and the idleConnectionTimeoutEvent could be used instead of `jdk.httpclient.keepalive.timeout.h2`?

Thanks all for the feedback so far, hopefully this can get closed off soon!

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

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

From dfuchs at openjdk.org  Thu Nov  3 17:22:28 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 17:22:28 GMT
Subject: Integrated: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <4AGCrDQ4XC3UDTwYPRw8OPCbIFPueKKAGAJVb7ulbmM=.d7bc126d-3230-4d27-8519-ff06233dd8d9@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

This pull request has now been integrated.

Changeset: 4338f527
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4338f527aa81350e3636dcfbcd2eb17ddaad3914
Stats:     853 lines in 82 files changed: 707 ins; 5 del; 141 mod

8294241: Deprecate URL public constructors

Reviewed-by: joehw, prr, alanb, aefimov, michaelm

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

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

From dfuchs at openjdk.org  Thu Nov  3 18:20:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 18:20:24 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
Message-ID: <uq2iPmk_Dn3gTNNQ-i8ak7Co_46-5CW0ew48jSgVlUU=.b3d00487-7e4f-4594-a1f2-a23ba17078f4@github.com>

On Thu, 3 Nov 2022 16:28:08 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: IdleConnectionTimeout can use Keep Alive or Custom Value

New changes look good - some comments follow...

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

> 1706:             if (s != null) {
> 1707:                 long timeoutVal = Long.parseLong(s);
> 1708:                 System.err.println(timeoutVal);

Stray println? You could use `Log.logTrace` here to print the value.

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

> 1709:                 if (timeoutVal >= 0) return timeoutVal;
> 1710:             }
> 1711:         } catch (NumberFormatException ignored) {}

Similarly - you could use `Log.logTrace` to print the error. It could be useful for diagnostic.

test/jdk/java/net/httpclient/http2/IdleConnectionTimeoutTest.java line 41:

> 39:  * @run testng/othervm -Djdk.httpclient.HttpClient.log=errors -Djdk.httpclient.keepalive.timeout.h2=-1 IdleConnectionTimeoutTest
> 40:  * @run testng/othervm -Djdk.httpclient.HttpClient.log=errors -Djdk.httpclient.keepalive.timeout.h2=1 -Djdk.httpclient.keepalive.timeout=2 IdleConnectionTimeoutTest
> 41:  */

Maybe add a test that only sets `-Djdk.httpclient.keepalive.timeout=1` too?

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

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

From dfuchs at openjdk.org  Thu Nov  3 18:37:10 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 18:37:10 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <3CkXDu2gZzPjCCjNGnR5Tm0_sMa3WKFEqkDm5vFryeE=.025c4d92-dd08-4e0d-9942-c611335fb029@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
 <3CkXDu2gZzPjCCjNGnR5Tm0_sMa3WKFEqkDm5vFryeE=.025c4d92-dd08-4e0d-9942-c611335fb029@github.com>
Message-ID: <wVkJPf9QGnPDed5SnlvavryTh0pgBlWwPisHEF1PcWs=.e985a18d-3839-4015-ad45-06c7d8aaab2e@github.com>

On Thu, 3 Nov 2022 16:37:45 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> * shutdown() in Http2Connection is returned to its original form. The existing code there is sufficient to log the idleConnectionTimeoutEvent once it fires.

I agree with this. If I read the code correctly the exception stack trace will be logged only if there are active stream, and in our case, the timeout should fire only when the connection is idle - so it should have no active stream. If it's being closed when there is an active stream then this is an error and we want to see it as such. The current code, as proposed here, does that.

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

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

From michaelm at openjdk.org  Fri Nov  4 09:44:37 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 4 Nov 2022 09:44:37 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
Message-ID: <jKbRwQsNKuyIFKe1bgALJAfrIDwgIILE_sNo2oAkSyY=.1c5dfd17-a6a6-4858-bb11-c4b114d4d471@github.com>

On Thu, 3 Nov 2022 16:28:08 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: IdleConnectionTimeout can use Keep Alive or Custom Value

src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 55:

> 53: final class ConnectionPool {
> 54: 
> 55:     static final long KEEP_ALIVE = KEEP_ALIVE_TIMEOUT; // seconds

I'd suggest removing line 55 and change the references below to KEEP_ALIVE_TIMEOUT

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

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

From ccleary at openjdk.org  Mon Nov  7 12:39:37 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 7 Nov 2022 12:39:37 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <jKbRwQsNKuyIFKe1bgALJAfrIDwgIILE_sNo2oAkSyY=.1c5dfd17-a6a6-4858-bb11-c4b114d4d471@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
 <jKbRwQsNKuyIFKe1bgALJAfrIDwgIILE_sNo2oAkSyY=.1c5dfd17-a6a6-4858-bb11-c4b114d4d471@github.com>
Message-ID: <wT7EGVuZUNusHE7uJygzNrRMEF3zGJ9v7N5dHqdEP8Q=.b836ee2d-ffb7-43b7-94f3-9ed8e15aa616@github.com>

On Fri, 4 Nov 2022 09:42:05 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288717: IdleConnectionTimeout can use Keep Alive or Custom Value
>
> src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 55:
> 
>> 53: final class ConnectionPool {
>> 54: 
>> 55:     static final long KEEP_ALIVE = KEEP_ALIVE_TIMEOUT; // seconds
> 
> I'd suggest removing line 55 and change the references below to KEEP_ALIVE_TIMEOUT

Yeah fair enough actually, I neglected to notice the slight duplication of code here (in terms of readability). I'll change this and see how it looks

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

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

From ccleary at openjdk.org  Mon Nov  7 12:39:38 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 7 Nov 2022 12:39:38 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v5]
In-Reply-To: <uq2iPmk_Dn3gTNNQ-i8ak7Co_46-5CW0ew48jSgVlUU=.b3d00487-7e4f-4594-a1f2-a23ba17078f4@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <eeHKAXyiMyHr87SJ4q_ScEQ7hCs5ctbAm_3qgQLB6P8=.c0dbdada-0119-425b-8b07-8ee11dcb1d6c@github.com>
 <uq2iPmk_Dn3gTNNQ-i8ak7Co_46-5CW0ew48jSgVlUU=.b3d00487-7e4f-4594-a1f2-a23ba17078f4@github.com>
Message-ID: <mxGJsokMx95x9Dzlg89JL2AAMV_bVy3heohgEAwGA4c=.43e0f622-e005-400e-b189-bf7cbc6887eb@github.com>

On Thu, 3 Nov 2022 18:13:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288717: IdleConnectionTimeout can use Keep Alive or Custom Value
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1708:
> 
>> 1706:             if (s != null) {
>> 1707:                 long timeoutVal = Long.parseLong(s);
>> 1708:                 System.err.println(timeoutVal);
> 
> Stray println? You could use `Log.logTrace` here to print the value.

Gah, thought I zapped all of these! Thanks for spotting. I think there is no need to log anything here, so I will just remove the println.

> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1711:
> 
>> 1709:                 if (timeoutVal >= 0) return timeoutVal;
>> 1710:             }
>> 1711:         } catch (NumberFormatException ignored) {}
> 
> Similarly - you could use `Log.logTrace` to print the error. It could be useful for diagnostic.

Good spot, would be useful. Should result in better logging with the test too. I'll include this.

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

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

From ccleary at openjdk.org  Mon Nov  7 15:12:56 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 7 Nov 2022 15:12:56 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v6]
In-Reply-To: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
Message-ID: <QsAu4FO3q958JfylIJd1zHFI2PdqISpvixonYxm5xaU=.b04edb4f-c214-4c66-9c38-47842d11330c@github.com>

> **Issue**
> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
> 
> **Proposed Solution**
> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.

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

  8288717: Added NumberFormatException log, refactored ConnectionPool

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10183/files
  - new: https://git.openjdk.org/jdk/pull/10183/files/24c57157..494a9a7e

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

  Stats: 27 lines in 3 files changed: 16 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10183.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10183/head:pull/10183

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

From xuelei at openjdk.org  Mon Nov  7 18:25:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 18:25:36 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v2]
In-Reply-To: <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <CpFplI9BTIvRwyqb8hNxy3OF0zVbPU0H23w5AsulOhQ=.f37ca9fb-4747-42ff-bad3-e185ffde932e@github.com>
Message-ID: <Ly58sLiOmijwvXATkLsJRifZmzeiZvO9XTbVxmZi89E=.e1588b11-af15-4766-98f1-f7c96c741304@github.com>

On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan 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
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Anyone has cycle for the review?

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

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

From xuelei at openjdk.org  Mon Nov  7 18:48:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 7 Nov 2022 18:48:27 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
Message-ID: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>

> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
> CSR: https://bugs.openjdk.org/browse/JDK-8291950
> RFE: https://bugs.openjdk.org/browse/JDK-8281236
> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
> 
> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - Merge
 - add test cases
 - 8281236: (D)TLS key exchange algorithms

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

Changes: https://git.openjdk.org/jdk/pull/9776/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=02
  Stats: 893 lines in 16 files changed: 657 ins; 195 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9776.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9776/head:pull/9776

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

From dfuchs at openjdk.org  Mon Nov  7 20:49:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Nov 2022 20:49:31 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v6]
In-Reply-To: <QsAu4FO3q958JfylIJd1zHFI2PdqISpvixonYxm5xaU=.b04edb4f-c214-4c66-9c38-47842d11330c@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <QsAu4FO3q958JfylIJd1zHFI2PdqISpvixonYxm5xaU=.b04edb4f-c214-4c66-9c38-47842d11330c@github.com>
Message-ID: <LJHUrrk7WhfEnQ4wosxev4M5AeYx87IPUtYGVrS0v8k=.251ae3b9-3765-46d0-9078-ce82ce9c798a@github.com>

On Mon, 7 Nov 2022 15:12:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: Added NumberFormatException log, refactored ConnectionPool

Changes LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From mpowers at openjdk.org  Mon Nov  7 23:28:31 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 7 Nov 2022 23:28:31 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Well crafted. LGTM.

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

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

From xuelei at openjdk.org  Tue Nov  8 07:00:38 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 07:00:38 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <vhe8NOZgq6P3gA_-9q8fPIFnOPtWjQ16fYV-MH8vHvM=.761e4394-b1c5-4f77-bae7-e099a71e693d@github.com>
Message-ID: <URMh4ioZFWSLWo4Ove9vCiRtvU9GCnAfCrqcE7j3dj0=.d9682c64-928e-423e-b3ec-3d8dba879e06@github.com>

On Mon, 7 Nov 2022 23:24:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge
>>  - Merge
>>  - add test cases
>>  - 8281236: (D)TLS key exchange algorithms
>
> Well crafted. LGTM.

Thank you very much, @mcpowers!

May I have the CSR reviewed? https://bugs.openjdk.org/browse/JDK-8291950. The new feature deadline is approaching.  I appreciate if the CSR could be reviewed in 2 weeks.

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

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

From duke at openjdk.org  Tue Nov  8 09:47:01 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Tue, 8 Nov 2022 09:47:01 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr locale
Message-ID: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>

Hi all,

Please review this fix for  Invalid characters in hostname exception. 
This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.

Thanks,
Ryan.

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

Commit messages:
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - Merge branch 'master' into 8294378
 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - Merge branch 'master' into 8294378
 - ... and 6 more: https://git.openjdk.org/jdk/compare/dd5d4df5...07aa9643

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

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

From jpai at openjdk.org  Tue Nov  8 09:47:03 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Nov 2022 09:47:03 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale
In-Reply-To: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
Message-ID: <EPSnfE4mK8QLqdPbGte6HOUFMH-SCWdcOXHiWPatrKc=.e5fc90da-ae86-45a7-95d6-4f8f57919be6@github.com>

On Fri, 28 Oct 2022 13:48:04 GMT, Ryan Wallace <duke at openjdk.org> wrote:

> Hi all,
> 
> Please review this fix for  Invalid characters in hostname exception. 
> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
> 
> Thanks,
> Ryan.

I suspect it might be better to introduce that new test `@run` with Turkish locale in the existing `URLPermissionTest` itself - passing it that specific URL to test. That way you won't have to refactor that existing test to extend from a new utility class.

test/jdk/java/net/URLPermission/URLPermissionNonASCIITest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022 Oracle and/or its affiliates. All rights reserved.

Hello Ryan, there's a comma missing here after `2022`.

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

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

From mpowers at openjdk.org  Tue Nov  8 16:55:29 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 8 Nov 2022 16:55:29 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

I'll look at your CSR this morning. Make sure your SSLParameters additions look correct with JavaDoc. I always forget that step.

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

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

From xuelei at openjdk.org  Tue Nov  8 20:55:24 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 20:55:24 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <TZw1t6bHlJGLfovQqmcDPbObz97g85QifROYuO_wwlA=.637592e9-c99c-4bb9-8daa-a9a5e99934cc@github.com>
Message-ID: <lLF73OpYGmtilgUW2vxRmI1ZlcZlBivM0yLjwI7BRt8=.da96f190-d0b8-44ef-aa71-ae4621eb5e88@github.com>

On Tue, 8 Nov 2022 16:51:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> I'll look at your CSR this morning. Make sure your SSLParameters additions look correct with JavaDoc. I always forget that step.

Thank you for the suggestion.  I double checked the JavaDoc.  It looks good to me.

Please feel free to add your name as reviewer in the CSR and approve this PR when you are ready.

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

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

From mpowers at openjdk.org  Tue Nov  8 21:22:33 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 8 Nov 2022 21:22:33 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
Message-ID: <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>

On Mon, 7 Nov 2022 18:48:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bugs.openjdk.org/browse/JDK-8281236
>> Release-note: https://bugs.openjdk.org/browse/JDK-8291975
>> 
>> This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Merge
>  - add test cases
>  - 8281236: (D)TLS key exchange algorithms

Unfortunately, I only have author status and can only comment.

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

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

From xuelei at openjdk.org  Tue Nov  8 21:57:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 21:57:30 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
Message-ID: <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>

On Tue, 8 Nov 2022 21:18:20 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Unfortunately, I only have author status and can only comment.

I think OpenJDK Author can approve as well.  I just need to get another Reviewer approval before integration.

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

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

From mullan at openjdk.org  Tue Nov  8 22:11:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Nov 2022 22:11:39 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
Message-ID: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>

On Tue, 8 Nov 2022 21:52:51 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Unfortunately, I only have author status and can only comment.
> 
> I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.

For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.

I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

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

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

From xuelei at openjdk.org  Tue Nov  8 22:35:32 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 22:35:32 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
 <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
Message-ID: <cTRH5KEFZzZ-ju6W_ELx5k5gHzBq9Ujv8AcAQVTJQGY=.88b6000a-a931-40fa-b888-4186a604773f@github.com>

On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Unfortunately, I only have author status and can only comment.
> > 
> > 
> > I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.
> 
> For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.
> 

+1.

> I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

I changed the CSR to Proposed.  Thanks for the suggestion.

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

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

From xuelei at openjdk.org  Tue Nov  8 22:47:55 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 8 Nov 2022 22:47:55 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
Message-ID: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>

Hi,

May I have this update in jdk.net reviewed?

While build on MacOX, I run into the following issues:

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

Commit messages:
 - 8296615: use of undeclared identifier 'IPV6_DONTFRAG'

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

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

From alanb at openjdk.org  Wed Nov  9 07:16:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Nov 2022 07:16:12 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
Message-ID: <R1yyqssA2XmvB-YP58vGJGXjjwhkbKjiVbjQFlD0XO8=.b81b291e-17fd-493f-8987-7129c67cc80a@github.com>

On Tue, 8 Nov 2022 22:28:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update in jdk.net reviewed?
> 
> While build on MacOX, I run into the following issues:

Which macOS release and Xcode version is this, just wondering why it hasn't been seen before now.

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

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

From xuelei at openjdk.org  Wed Nov  9 07:48:33 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 07:48:33 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <R1yyqssA2XmvB-YP58vGJGXjjwhkbKjiVbjQFlD0XO8=.b81b291e-17fd-493f-8987-7129c67cc80a@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
 <R1yyqssA2XmvB-YP58vGJGXjjwhkbKjiVbjQFlD0XO8=.b81b291e-17fd-493f-8987-7129c67cc80a@github.com>
Message-ID: <f1YKIOzanFD27zErryEuHhy4ZTp_pIKBJpyjCSQlVSg=.75b22f5e-6110-4bda-be4b-8162a21ca283@github.com>

On Wed, 9 Nov 2022 07:12:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Which macOS release and Xcode version is this, just wondering why it hasn't been seen before now.

I just noticed the issue yesterday while I run the building.   I could build without any problem a few days before.  The system is macOS Monterey version 12.6.   Here is the related OpenJDK building configure summary:

* Toolchain:      clang (clang/LLVM from Xcode 14.1)
* Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk
* C Compiler:     Version 14.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 14.0.0 (at /usr/bin/clang++)

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

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

From michaelm at openjdk.org  Wed Nov  9 11:17:24 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Nov 2022 11:17:24 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
Message-ID: <0CKoNJcKIH3DfaYm86vYuYTV02Qq-o9NMHpPxEh2xSk=.1350f108-3887-4af9-b164-b04085ae7ba6@github.com>

On Tue, 8 Nov 2022 22:28:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update in jdk.net reviewed?
> 
> While build on MacOX, I run into the following issues:

Seems strange that the definition has been removed in a newer Xcode version. Have you checked if it has been moved to a different header file?

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

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

From xuelei at openjdk.org  Wed Nov  9 16:10:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 16:10:15 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <0CKoNJcKIH3DfaYm86vYuYTV02Qq-o9NMHpPxEh2xSk=.1350f108-3887-4af9-b164-b04085ae7ba6@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
 <0CKoNJcKIH3DfaYm86vYuYTV02Qq-o9NMHpPxEh2xSk=.1350f108-3887-4af9-b164-b04085ae7ba6@github.com>
Message-ID: <CfT2N5gQE-HpJyBeG4U2rJyKo326fcIfgLldsAk1P2c=.e6dadde7-4ab1-4911-a794-38fe9168576b@github.com>

On Wed, 9 Nov 2022 11:15:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Seems strange that the definition has been removed in a newer Xcode version. Have you checked if it has been moved to a different header file?

It is still in the in6.h.  But it is not included because of the macro definitions.

#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
    ...
#ifdef __APPLE_USE_RFC_3542
    ...
#define	IPV6_DONTFRAG		62 /* bool; disable IPv6 fragmentation */
    ...
#endif /* __APPLE_USE_RFC_3542 */
    ...
#endif /* (_POSIX_C_SOURCE && !_DARWIN_C_SOURCE) */


If I updated the MacOSXSocketOptions.c code to:

#define __APPLE_USE_RFC_3542
#include <netinet/in.h>

#ifndef IP_DONTFRAG
#define IP_DONTFRAG             28
#endif

#if defined(_POSIX_C_SOURCE)
#undef IP_DONTFRAG
#endif

#if !defined(_DARWIN_C_SOURCE)
#undef IP_DONTFRAG
#endif

/*
#ifndef IPV6_DONTFRAG
#define IPV6_DONTFRAG           62
#endif
*/


I can see neither IP_DONTFRAG nor IPV6_DONTFRAG is defined.   I think the _POSIX_C_SOURCE is defined, and _DARWIN_C_SOURCE not in the building environment.  And the definitions of _POSIX_C_SOURCE and _DARWIN_C_SOURCE get the IPV6_DONTFRAG definition in in6.h out.

Alternatively, we may be able to define _DARWIN_C_SOURCE as we did for __APPLE_USE_RFC_3542.  But the impact may be more wider.

  #define __APPLE_USE_RFC_3542
+ #define _DARWIN_C_SOURCE
  #include <netinet/in.h>

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

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

From michaelm at openjdk.org  Wed Nov  9 16:46:35 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Nov 2022 16:46:35 GMT
Subject: RFR: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
Message-ID: <xF0_4M1ode6pFsO6hRSGaOcxgzyTzVDaMfuR4HlMVRE=.d55184df-b4e1-4792-be44-91bd1333dd33@github.com>

On Tue, 8 Nov 2022 22:28:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update in jdk.net reviewed?
> 
> While build on MacOX, I run into the following issues:

Marked as reviewed by michaelm (Reviewer).

Thanks. I think your suggested change in the webrev is best.

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

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

From xuelei at openjdk.org  Wed Nov  9 17:40:35 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 9 Nov 2022 17:40:35 GMT
Subject: Integrated: 8296615: use of undeclared identifier 'IPV6_DONTFRAG'
In-Reply-To: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
References: <vQaymFG24MY3Gsscd9u3nfJiXxWHwZVWuQwvdVWcD5U=.0cf3acbe-684d-4024-9659-d0837c4d9c30@github.com>
Message-ID: <v4xqJpHXI6bJRAH2xdvJAIcVF8NVsfiZ_v18UOxPbg8=.969b6437-a9d2-4894-a7b2-d9de475a1dc3@github.com>

On Tue, 8 Nov 2022 22:28:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update in jdk.net reviewed?
> 
> While build on MacOX, I run into the following issues:

This pull request has now been integrated.

Changeset: 17e34123
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17e3412363bf5263c26d9bf1dfbef1fecc3d11a9
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8296615: use of undeclared identifier 'IPV6_DONTFRAG'

Reviewed-by: michaelm

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

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

From jjg at openjdk.org  Thu Nov 10 01:21:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 01:21:09 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>

Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.

"Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.

"Normalized" means...
* Use `https:` where possible (includes pretty much all cases)
* Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
* Point to the root page of a multi-page spec
* Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)

In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.

The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.

That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.

Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.

To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/

In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

Commit messages:
 - JDK-8296547: Add @spec tags to API

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

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

From dfuchs at openjdk.org  Thu Nov 10 11:34:25 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Nov 2022 11:34:25 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html

External Specifications
    [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)

You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing.
Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

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

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

From alanb at openjdk.org  Thu Nov 10 11:49:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 11:49:21 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

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

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

From alanb at openjdk.org  Thu Nov 10 12:04:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 12:04:51 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g.
http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY
so the `@see` ref can be dropped.

In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?

There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

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

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

From duke at openjdk.org  Thu Nov 10 15:06:57 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Thu, 10 Nov 2022 15:06:57 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v2]
In-Reply-To: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
Message-ID: <qRUZ9TeT_ty16uDavjiF7OYvp3YB2prW2PcKn6n4dsM=.a04a6349-d922-4c81-a616-71ed71cc2d90@github.com>

> Hi all,
> 
> Please review this fix for  Invalid characters in hostname exception. 
> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
> 
> Thanks,
> Ryan.

Ryan Wallace 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 19 additional commits since the last revision:

 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - ... and 9 more: https://git.openjdk.org/jdk/compare/66d8f3c8...207f3131

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10903/files
  - new: https://git.openjdk.org/jdk/pull/10903/files/07aa9643..207f3131

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

  Stats: 5685 lines in 299 files changed: 1292 ins; 3165 del; 1228 mod
  Patch: https://git.openjdk.org/jdk/pull/10903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10903/head:pull/10903

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

From weijun at openjdk.org  Thu Nov 10 16:24:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 16:24:26 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <YsQZKL7FoweoqYLwGrMarDb92lTrfeAWksgmD2tTktc=.424afc93-1eb4-42ef-8f1a-81a9db5e000e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html

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

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

From duke at openjdk.org  Thu Nov 10 16:35:32 2022
From: duke at openjdk.org (AJ1062910)
Date: Thu, 10 Nov 2022 16:35:32 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

did you changed 420 files ?

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

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

From mullan at openjdk.org  Thu Nov 10 21:34:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:34:30 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link.

+1.

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

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

From jjg at openjdk.org  Thu Nov 10 21:58:28 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 21:58:28 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Jon,
> 
> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
> 
> External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)
> 
> You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want.

On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

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

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

From jjg at openjdk.org  Thu Nov 10 22:03:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:03:32 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <jribbsj15UipAgtqxLmb156zaVOdJJU4zaukxrE-8Bg=.7b4f4219-ceb9-4173-a341-6d6fe2229ddd@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

I can change the doclet to use a bulleted list when any spec titles contain a comma.

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

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

From jjg at openjdk.org  Thu Nov 10 22:11:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:11:30 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
Message-ID: <K4Z5QVATg9JlpZKp2HyIaHcMz_u24yhBOmw7RFkVmMo=.58dbad2c-e6cb-4fa5-857b-8c5bfb5007f0@github.com>

On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped.
> 
> In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?
> 
> There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag.  Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed.

When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence.

_History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page.  Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._

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

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

From jjg at openjdk.org  Thu Nov 10 22:19:26 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:19:26 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
Message-ID: <Dt2pqnepgR8UMT5ypzYkvgJRKKxNg8K8m-vu3OdEFg4=.2c04027c-f939-4972-8eca-345fc6f923bc@github.com>

On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 <duke at openjdk.org> wrote:

> did you changed 420 files ?

I ran a custom utility that edited these files, yes.

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

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

From naoto at openjdk.org  Thu Nov 10 23:55:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Nov 2022 23:55:34 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/java.base/share/classes/java/lang/Character.java line 172:

> 170:  * occur. For example, in a future release, synchronization may fail.
> 171:  *
> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0

This should probably be removed, as the original link (explaining `U+n` notation) is broken.

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

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

From jpai at openjdk.org  Fri Nov 11 03:47:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 11 Nov 2022 03:47:43 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v2]
In-Reply-To: <qRUZ9TeT_ty16uDavjiF7OYvp3YB2prW2PcKn6n4dsM=.a04a6349-d922-4c81-a616-71ed71cc2d90@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <qRUZ9TeT_ty16uDavjiF7OYvp3YB2prW2PcKn6n4dsM=.a04a6349-d922-4c81-a616-71ed71cc2d90@github.com>
Message-ID: <FgyHU3lSi_UKzTUXS-6GUrEM1p5Fv_2KRiNqZsBtM6I=.5ca5ca67-9a25-4354-a185-54677eae95c0@github.com>

On Thu, 10 Nov 2022 15:06:57 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for  Invalid characters in hostname exception. 
>> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
>> 
>> Thanks,
>> Ryan.
>
> Ryan Wallace 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 19 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2725fee7...207f3131

test/jdk/java/net/URLPermission/URLPermissionTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2013, 2016, 2022, Oracle and/or its affiliates. All rights reserved.

Hello Ryan, this should be `2013, 2022,` - we only maintain 2 years the year this file was first introduced and the latest update year.

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

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

From cjplummer at openjdk.org  Fri Nov 11 04:18:30 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Nov 2022 04:18:30 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105:

> 103:      *          If the length of the packet (as indictaed by the first
> 104:      *          4 bytes) is less than 11 bytes, or an I/O error occurs.
> 105:      * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket()

Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79:

> 77:  * target VM.
> 78:  *
> 79:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

See above comment for Connection.java.

src/jdk.jdi/share/classes/module-info.java line 107:

> 105:  *
> 106:  *
> 107:  * @spec jpda/jpda.html Java Platform Debugger Architecture

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html

`@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool.

src/jdk.jdwp.agent/share/classes/module-info.java line 30:

> 28:  *
> 29:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 30:  * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport)

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html

The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed.

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

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

From dfuchs at openjdk.org  Fri Nov 11 10:12:08 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:12:08 GMT
Subject: RFR: 8296747:
 com/sun/net/httpserver/simpleserver/StressDirListings.java timed out
Message-ID: <InI7QM3c3Fs_DIHq82d8PegdlpGJ53HIBlEe_a7h77A=.915ed570-8376-4972-b21e-65be4254cceb@github.com>

The StressDirListings has been observed failing in timeout in the CI once. The test actually passed but the timeout occurred in the test harness - presumably at around the same time. It was suggested that maybe the test timeout could be extended beyond the usual default 120s. This change proposes to extend the timeout to 180s. It also adds some more timestamps based on System.nanoTime() so that we can better figure out where the time was being consumed if the test fails again in the future.

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

Commit messages:
 - 8296747

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

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

From jpai at openjdk.org  Fri Nov 11 10:17:34 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 11 Nov 2022 10:17:34 GMT
Subject: RFR: 8296747:
 com/sun/net/httpserver/simpleserver/StressDirListings.java timed out
In-Reply-To: <InI7QM3c3Fs_DIHq82d8PegdlpGJ53HIBlEe_a7h77A=.915ed570-8376-4972-b21e-65be4254cceb@github.com>
References: <InI7QM3c3Fs_DIHq82d8PegdlpGJ53HIBlEe_a7h77A=.915ed570-8376-4972-b21e-65be4254cceb@github.com>
Message-ID: <HEzgFD8FmCp_Nw1nXmnz_ONvXdmE0LzjctDbo0JZXd8=.3b9708f1-deba-471d-9444-e9ec672b8dd6@github.com>

On Fri, 11 Nov 2022 10:03:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The StressDirListings has been observed failing in timeout in the CI once. The test actually passed but the timeout occurred in the test harness - presumably at around the same time. It was suggested that maybe the test timeout could be extended beyond the usual default 120s. This change proposes to extend the timeout to 180s. It also adds some more timestamps based on System.nanoTime() so that we can better figure out where the time was being consumed if the test fails again in the future.

Marked as reviewed by jpai (Reviewer).

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

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

From dfuchs at openjdk.org  Fri Nov 11 10:29:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:29:33 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
Message-ID: <WspQupF8fnStNO87pH42-2xTdbEwWYmiAcWuG2m3PSQ=.2d639a08-534c-4e41-aef9-287e4ab11a54@github.com>

On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself?

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

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

From dfuchs at openjdk.org  Fri Nov 11 10:32:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:32:31 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v2]
In-Reply-To: <FgyHU3lSi_UKzTUXS-6GUrEM1p5Fv_2KRiNqZsBtM6I=.5ca5ca67-9a25-4354-a185-54677eae95c0@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <qRUZ9TeT_ty16uDavjiF7OYvp3YB2prW2PcKn6n4dsM=.a04a6349-d922-4c81-a616-71ed71cc2d90@github.com>
 <FgyHU3lSi_UKzTUXS-6GUrEM1p5Fv_2KRiNqZsBtM6I=.5ca5ca67-9a25-4354-a185-54677eae95c0@github.com>
Message-ID: <O98eiaDLvTlc7Ch9zTpqEK-O9tnGKjCTG7txoShGGO8=.65eb5f4c-6c1a-4b57-abc3-c1860ebd8854@github.com>

On Fri, 11 Nov 2022 03:45:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ryan Wallace 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 19 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/277a6313...207f3131
>
> test/jdk/java/net/URLPermission/URLPermissionTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013, 2016, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Ryan, this should be `2013, 2022,` - we only maintain 2 years the year this file was first introduced and the latest update year.

Good catch!

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

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

From dfuchs at openjdk.org  Fri Nov 11 11:26:36 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 11:26:36 GMT
Subject: Integrated: 8296747:
 com/sun/net/httpserver/simpleserver/StressDirListings.java timed out
In-Reply-To: <InI7QM3c3Fs_DIHq82d8PegdlpGJ53HIBlEe_a7h77A=.915ed570-8376-4972-b21e-65be4254cceb@github.com>
References: <InI7QM3c3Fs_DIHq82d8PegdlpGJ53HIBlEe_a7h77A=.915ed570-8376-4972-b21e-65be4254cceb@github.com>
Message-ID: <JgCphTZwOU7KzeKwoR48tYWIjuU5kbKkdS-OKbeperM=.2e1d377f-de5c-4541-b1e9-aa7f348c57bf@github.com>

On Fri, 11 Nov 2022 10:03:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The StressDirListings has been observed failing in timeout in the CI once. The test actually passed but the timeout occurred in the test harness - presumably at around the same time. It was suggested that maybe the test timeout could be extended beyond the usual default 120s. This change proposes to extend the timeout to 180s. It also adds some more timestamps based on System.nanoTime() so that we can better figure out where the time was being consumed if the test fails again in the future.

This pull request has now been integrated.

Changeset: 4a300818
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a300818fe7a47932c5b762ccd3b948815a31974
Stats:     19 lines in 1 file changed: 17 ins; 0 del; 2 mod

8296747: com/sun/net/httpserver/simpleserver/StressDirListings.java timed out

Reviewed-by: jpai

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

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

From duke at openjdk.org  Fri Nov 11 11:48:51 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Fri, 11 Nov 2022 11:48:51 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
Message-ID: <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>

> Hi all,
> 
> Please review this fix for  Invalid characters in hostname exception. 
> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
> 
> Thanks,
> Ryan.

Ryan Wallace 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 21 additional commits since the last revision:

 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - Merge branch 'master' into 8294378
 - ... and 11 more: https://git.openjdk.org/jdk/compare/cce07639...e992f1f3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10903/files
  - new: https://git.openjdk.org/jdk/pull/10903/files/207f3131..e992f1f3

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

  Stats: 1496 lines in 90 files changed: 836 ins; 498 del; 162 mod
  Patch: https://git.openjdk.org/jdk/pull/10903.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10903/head:pull/10903

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

From lancea at openjdk.org  Fri Nov 11 11:49:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Nov 2022 11:49:32 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

I only looked at the jar specific updates but there is some duplication leftovers.

It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

src/java.base/share/classes/java/util/jar/Attributes.java line 58:

> 56:  * order that keys were inserted into the map, as with {@link LinkedHashMap}.
> 57:  *
> 58:  * @spec jar/jar.html JAR File Specification

Line 52 should be removed

src/java.base/share/classes/java/util/jar/Attributes.java line 450:

> 448:      * <a href="{@docRoot}/../specs/jar/jar.html">JAR File Specification</a>
> 449:      * for more information about valid attribute names and values.
> 450:      * @spec jar/jar.html JAR File Specification

Line 448 should be removed

src/java.base/share/classes/java/util/jar/Manifest.java line 47:

> 45:  * Manifest format specification</a>.
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 44 should be removed

src/java.base/share/classes/java/util/jar/package-info.java line 47:

> 45:  * </ul>
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 43 should be removed

src/java.base/share/classes/java/util/zip/package-info.java line 75:

> 73:  * </ul>
> 74:  *
> 75:  * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3

The above references should be removed as they duplicate the` @spec` tags

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

Changes requested by lancea (Reviewer).

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

From dfuchs at openjdk.org  Fri Nov 11 12:01:12 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 12:01:12 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
Message-ID: <BqRC-wDts_gSNQXnMftSAfzCS61LDBshkZt8pY8e_6s=.34d97531-9be6-4553-b67f-a18a1befedc7@github.com>

On Fri, 11 Nov 2022 11:48:51 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for  Invalid characters in hostname exception. 
>> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
>> 
>> Thanks,
>> Ryan.
>
> Ryan Wallace 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 21 additional commits since the last revision:
> 
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/79c90992...e992f1f3

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From duke at openjdk.org  Fri Nov 11 12:01:15 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Fri, 11 Nov 2022 12:01:15 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <EPSnfE4mK8QLqdPbGte6HOUFMH-SCWdcOXHiWPatrKc=.e5fc90da-ae86-45a7-95d6-4f8f57919be6@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <EPSnfE4mK8QLqdPbGte6HOUFMH-SCWdcOXHiWPatrKc=.e5fc90da-ae86-45a7-95d6-4f8f57919be6@github.com>
Message-ID: <2_xNJUR8X0-KYzbsNd3hTyIiXHRhF5t2fVQA7APTmVY=.71ecbb8e-2a48-4abe-a1b0-0a6a635e4e11@github.com>

On Sat, 29 Oct 2022 11:22:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ryan Wallace 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 21 additional commits since the last revision:
>> 
>>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - Merge branch 'master' into 8294378
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/79c90992...e992f1f3
>
> test/jdk/java/net/URLPermission/URLPermissionNonASCIITest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022 Oracle and/or its affiliates. All rights reserved.
> 
> Hello Ryan, there's a comma missing here after `2022`.

File has been deleted and test has been added to URLPermissionTest class

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

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

From duke at openjdk.org  Fri Nov 11 12:01:16 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Fri, 11 Nov 2022 12:01:16 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v2]
In-Reply-To: <O98eiaDLvTlc7Ch9zTpqEK-O9tnGKjCTG7txoShGGO8=.65eb5f4c-6c1a-4b57-abc3-c1860ebd8854@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <qRUZ9TeT_ty16uDavjiF7OYvp3YB2prW2PcKn6n4dsM=.a04a6349-d922-4c81-a616-71ed71cc2d90@github.com>
 <FgyHU3lSi_UKzTUXS-6GUrEM1p5Fv_2KRiNqZsBtM6I=.5ca5ca67-9a25-4354-a185-54677eae95c0@github.com>
 <O98eiaDLvTlc7Ch9zTpqEK-O9tnGKjCTG7txoShGGO8=.65eb5f4c-6c1a-4b57-abc3-c1860ebd8854@github.com>
Message-ID: <l_HlW31xPmE-wn9S7NshPdpXK3-M7LYy42mSMHjdtaw=.dd2aab11-35de-4a01-b23a-897fa7415be6@github.com>

On Fri, 11 Nov 2022 10:30:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/URLPermission/URLPermissionTest.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2013, 2016, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Hello Ryan, this should be `2013, 2022,` - we only maintain 2 years the year this file was first introduced and the latest update year.
>
> Good catch!

updated, thanks Jaikiran

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

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

From dfuchs at openjdk.org  Fri Nov 11 12:01:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 12:01:42 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
Message-ID: <siwyjzUschdL9bJ_M4fdQDfY59oCJ0aAZGwncWho3cM=.8fd36fb3-4f95-4f55-a353-d15df9e4078f@github.com>

On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

Leaving out the non-public and non-exported classes would also reduce the PR size.

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

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

From jpai at openjdk.org  Fri Nov 11 12:24:36 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 11 Nov 2022 12:24:36 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
Message-ID: <QAnFL3VZ-qaQ-UmUK4xMnzXRGs5dEflhqPQ2KeYfL64=.4b5bd6ff-c3cd-4ab5-b876-9fccd4da304a@github.com>

On Fri, 11 Nov 2022 11:48:51 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for  Invalid characters in hostname exception. 
>> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
>> 
>> Thanks,
>> Ryan.
>
> Ryan Wallace 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 21 additional commits since the last revision:
> 
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/c3fa7583...e992f1f3

Thank you Ryan for these changes. The latest state in `e992f1f3` looks good to me.

Please run the `tier2` tests once (if not done already) before integrating.

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

Marked as reviewed by jpai (Reviewer).

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

From aefimov at openjdk.org  Fri Nov 11 12:56:34 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 11 Nov 2022 12:56:34 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
Message-ID: <tW4s_FauXWlDeTrB2_ryDDQe0__S110lSwi-D4DvY2o=.b1676d37-db98-44d7-a004-82be621658c3@github.com>

On Fri, 11 Nov 2022 11:48:51 GMT, Ryan Wallace <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for  Invalid characters in hostname exception. 
>> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
>> 
>> Thanks,
>> Ryan.
>
> Ryan Wallace 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 21 additional commits since the last revision:
> 
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - 8294378: Remove toLowerCase for auth url string to mitigate non ascii characters generated in URLPermission and change url to lowercase in HostPortrange
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - Merge branch 'master' into 8294378
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/9f99edb5...e992f1f3

The latest changes look good to me. Thanks for fixing it

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

Marked as reviewed by aefimov (Committer).

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

From duke at openjdk.org  Fri Nov 11 14:27:30 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Fri, 11 Nov 2022 14:27:30 GMT
Subject: RFR: 8294378: URLPermission constructor exception when using tr
 locale [v3]
In-Reply-To: <QAnFL3VZ-qaQ-UmUK4xMnzXRGs5dEflhqPQ2KeYfL64=.4b5bd6ff-c3cd-4ab5-b876-9fccd4da304a@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
 <TiFPSJiE0eLHoWnjJ3awfualA9e_VK2oUZ9fHRA9jc8=.fad8aee1-4347-499e-ac00-2a56db0d56fc@github.com>
 <QAnFL3VZ-qaQ-UmUK4xMnzXRGs5dEflhqPQ2KeYfL64=.4b5bd6ff-c3cd-4ab5-b876-9fccd4da304a@github.com>
Message-ID: <WnD8qJRomp626BBRy08FtrwwqYDcmZqFXbOOqybBvVA=.ad8766f8-6526-4ee9-9a54-5292302923a7@github.com>

On Fri, 11 Nov 2022 12:22:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Thank you Ryan for these changes. The latest state in `e992f1f3` looks good to me.
> 
> Please run the `tier2` tests once (if not done already) before integrating.

Thanks Jaikiran the tests are passing

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

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

From dfuchs at openjdk.org  Fri Nov 11 15:25:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 15:25:40 GMT
Subject: RFR: 8296889: Race condition when cancelling a request
Message-ID: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>

The CancelRequest test was observed failing again after [JDK-8294916](https://bugs.openjdk.org/browse/JDK-8294916) was integrated: there is a small race condition window in the code that unregisters the request BodySubscriber when a request is cancelled: if the request cancellation happens after the body subscriber is registered but before it is subscribed it may not be unregistered. 

The solution is to register it only after it has been successfully subscribed.

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

Commit messages:
 - 8296889

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

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

From duke at openjdk.org  Sat Nov 12 01:40:41 2022
From: duke at openjdk.org (Ryan Wallace)
Date: Sat, 12 Nov 2022 01:40:41 GMT
Subject: Integrated: 8294378: URLPermission constructor exception when using tr
 locale
In-Reply-To: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
References: <b3PNdtnSi3P5bpQtLv2KsDNoiPa5EERQILAbmcxmn1Q=.3ba1329b-17e5-4d8c-a6e8-17591003e798@github.com>
Message-ID: <WPM7DD79M8E9xb9yeWUA6OotjsqHUPz2nkIapgXS0Kc=.fb5689d3-16b2-4bc7-9c8e-142860492d0b@github.com>

On Fri, 28 Oct 2022 13:48:04 GMT, Ryan Wallace <duke at openjdk.org> wrote:

> Hi all,
> 
> Please review this fix for  Invalid characters in hostname exception. 
> This was due to the URLPermission.parseURI() method calling String.toLowerCase() and returning a non ASCII characters in the case of the tr Locale.  The fix was to use the HostPortrange.toLowerCase() method further down the stack which is Locale safe.
> 
> Thanks,
> Ryan.

This pull request has now been integrated.

Changeset: ff2c9876
Author:    Ryan Wallace <ryan.w.wallace at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff2c987669523613f3e5dc19493a41f849f882f6
Stats:     13 lines in 3 files changed: 8 ins; 0 del; 5 mod

8294378: URLPermission constructor exception when using tr locale

Reviewed-by: dfuchs, jpai, aefimov

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

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

From dfuchs at openjdk.org  Mon Nov 14 19:27:45 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Nov 2022 19:27:45 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v6]
In-Reply-To: <QsAu4FO3q958JfylIJd1zHFI2PdqISpvixonYxm5xaU=.b04edb4f-c214-4c66-9c38-47842d11330c@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <QsAu4FO3q958JfylIJd1zHFI2PdqISpvixonYxm5xaU=.b04edb4f-c214-4c66-9c38-47842d11330c@github.com>
Message-ID: <djmCHx0z0Uk4mAZOCfs2Jm_7MT-OxJ6om5W9bDPYLs8=.c3dc4d7f-6225-4832-b5b0-1097d096f266@github.com>

On Mon, 7 Nov 2022 15:12:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: Added NumberFormatException log, refactored ConnectionPool

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

> 112:     static final AtomicLong CLIENT_IDS = new AtomicLong();
> 113:     private final AtomicLong CONNECTION_IDS = new AtomicLong();
> 114:     static final int DEFAULT_KEEP_ALIVE_TIMEOUT = 600;

Hi Conor, I believe we had agreed to keep the default value unchanged (1200) for now and log a followup issue to revisit this and provide a more suitable value. Could you do that before integrating?

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

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

From jpai at openjdk.org  Tue Nov 15 09:01:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Nov 2022 09:01:17 GMT
Subject: RFR: 8296889: Race condition when cancelling a request
In-Reply-To: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
References: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
Message-ID: <WaOv_sjm9v-4DM3GFVBn1d5ukymZr5Ot2135PQkPhO4=.323621d6-19f2-4a37-a688-16aa0284939a@github.com>

On Fri, 11 Nov 2022 15:18:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The CancelRequest test was observed failing again after [JDK-8294916](https://bugs.openjdk.org/browse/JDK-8294916) was integrated: there is a small race condition window in the code that unregisters the request BodySubscriber when a request is cancelled: if the request cancellation happens after the body subscriber is registered but before it is subscribed it may not be unregistered. 
> 
> The solution is to register it only after it has been successfully subscribed.

Hello Daniel, from what I understand, before the change in this PR, we used to add the subscriber to an internal collection in the HttpClient even before the subscription was done. That would then mean the callbacks that are related to a subscription wouldn't be invoked, in certain cases (for example the request cancellation). Since we do the unregistration in these callbacks, the registered subscriber would not be removed from the HttpClient's collection. Did I understand this right? If so, your change looks good to me.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 213:

> 211:         @Override
> 212:         public void onSubscribed() {
> 213:             exchange.registerResponseSubscriber(this);

The `registerResponseSubscriber` in addition to registering it with the client will also set a local `responseSubscriber` member. Do you think we should `null` it out in the callbacks where we call the `unregisterResponseSubscriber`?

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

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

From ccleary at openjdk.org  Tue Nov 15 12:10:00 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 15 Nov 2022 12:10:00 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v7]
In-Reply-To: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
Message-ID: <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>

> **Issue**
> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
> 
> **Proposed Solution**
> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.

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

  8288717: Changed default keep alive value to original

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10183/files
  - new: https://git.openjdk.org/jdk/pull/10183/files/494a9a7e..0fd176ac

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

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

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

From ccleary at openjdk.org  Tue Nov 15 12:17:07 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 15 Nov 2022 12:17:07 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v7]
In-Reply-To: <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
Message-ID: <FUxooH-9NNUsml8AoE8C2wezU-xck1_9hsZ6PrrzfDg=.539ccc9f-a6aa-4ac6-9897-70bc727ed799@github.com>

On Tue, 15 Nov 2022 12:10:00 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: Changed default keep alive value to original

The default Keep Alive time has been kept at its original 1200 seconds. A seperate issue has been created to reduce this default value here: [JDK-8297030](https://bugs.openjdk.org/browse/JDK-8297030)

Seeking additonal reviewers now to move this PR forward

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

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

From dfuchs at openjdk.org  Tue Nov 15 14:21:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Nov 2022 14:21:01 GMT
Subject: RFR: 8296889: Race condition when cancelling a request
In-Reply-To: <WaOv_sjm9v-4DM3GFVBn1d5ukymZr5Ot2135PQkPhO4=.323621d6-19f2-4a37-a688-16aa0284939a@github.com>
References: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
 <WaOv_sjm9v-4DM3GFVBn1d5ukymZr5Ot2135PQkPhO4=.323621d6-19f2-4a37-a688-16aa0284939a@github.com>
Message-ID: <4rop5kHJLmQOs8WNZnEkZ-bosF9_QvIbKE1Qviw9Ki4=.fd726879-8ecc-4bc8-b513-16d8547089ff@github.com>

On Tue, 15 Nov 2022 08:56:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The CancelRequest test was observed failing again after [JDK-8294916](https://bugs.openjdk.org/browse/JDK-8294916) was integrated: there is a small race condition window in the code that unregisters the request BodySubscriber when a request is cancelled: if the request cancellation happens after the body subscriber is registered but before it is subscribed it may not be unregistered. 
>> 
>> The solution is to register it only after it has been successfully subscribed.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 213:
> 
>> 211:         @Override
>> 212:         public void onSubscribed() {
>> 213:             exchange.registerResponseSubscriber(this);
> 
> The `registerResponseSubscriber` in addition to registering it with the client will also set a local `responseSubscriber` member. Do you think we should `null` it out in the callbacks where we call the `unregisterResponseSubscriber`?

Good question. But I believe not:  it wasn't needed before this change. The only place where we look at the subscriber is cancelImpl. Depending on the propagation of error conditions we might introduce a race if we did that - especially since we are unregistering the subscriber before propagating errors (if any).

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

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

From dfuchs at openjdk.org  Tue Nov 15 14:28:02 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Nov 2022 14:28:02 GMT
Subject: RFR: 8296889: Race condition when cancelling a request
In-Reply-To: <WaOv_sjm9v-4DM3GFVBn1d5ukymZr5Ot2135PQkPhO4=.323621d6-19f2-4a37-a688-16aa0284939a@github.com>
References: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
 <WaOv_sjm9v-4DM3GFVBn1d5ukymZr5Ot2135PQkPhO4=.323621d6-19f2-4a37-a688-16aa0284939a@github.com>
Message-ID: <f5Pr9zSwY2raxdF6wsf3ciIEIaI7GaD9OzsuhWKEXBc=.a0a41806-e81e-4f86-9b8c-75ce94882943@github.com>

On Tue, 15 Nov 2022 08:54:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Daniel, from what I understand, before the change in this PR, we used to add the subscriber to an internal collection in the HttpClient even before the subscription was done. That would then mean the callbacks that are related to a subscription wouldn't be invoked, in certain cases (for example the request cancellation). Since we do the unregistration in these callbacks, the registered subscriber would not be removed from the HttpClient's collection. Did I understand this right? If so, your change looks good to me.

Yes - if the cancellation happens after the subscriber is registered in the collection, but before the subscriber is subscribed, then the subscriber may never subscribe, and therefore might never be canceled. If it doesn't get cancelled (or completed) then it won't be removed from the collection. Therefore, adding it to the collection at the time it is subscribed should ensure that it gets removed from the collection, because the expectation is that once subscribed it MUST either be completed successfully, completed exceptionally, or cancelled, and any of these three actions will take it out of the collection (which was the object of my previous fix in this area).

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

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

From jpai at openjdk.org  Tue Nov 15 14:40:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Nov 2022 14:40:20 GMT
Subject: RFR: 8296889: Race condition when cancelling a request
In-Reply-To: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
References: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
Message-ID: <CL0VDmSxhdzZtZS1PaYH9yIsrgZiYlHoTJXWfrzz1cg=.a7a3dbd8-0c5a-4dd9-9f99-d75f0697e40e@github.com>

On Fri, 11 Nov 2022 15:18:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The CancelRequest test was observed failing again after [JDK-8294916](https://bugs.openjdk.org/browse/JDK-8294916) was integrated: there is a small race condition window in the code that unregisters the request BodySubscriber when a request is cancelled: if the request cancellation happens after the body subscriber is registered but before it is subscribed it may not be unregistered. 
> 
> The solution is to register it only after it has been successfully subscribed.

Marked as reviewed by jpai (Reviewer).

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

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

From dfuchs at openjdk.org  Tue Nov 15 14:55:14 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Nov 2022 14:55:14 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v7]
In-Reply-To: <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
Message-ID: <93sM0LmKsch9JYdTtIgdxJlHlNRGEIoTbra1-bji9eY=.f277463d-d063-4e8e-918a-96e7eac2fd00@github.com>

On Tue, 15 Nov 2022 12:10:00 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: Changed default keep alive value to original

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From ccleary at openjdk.org  Tue Nov 15 16:53:09 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 15 Nov 2022 16:53:09 GMT
Subject: Withdrawn: 8288717: Add a means to close idle connections in HTTP/2
 connection pool
In-Reply-To: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
Message-ID: <yzi2N8aykXjAZd5yF0lIkroG48aidU_1Uva37A9NQuM=.24b42ee7-e92c-4d2e-a744-f6da6dd3d5f3@github.com>

On Tue, 6 Sep 2022 13:56:15 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
> 
> **Proposed Solution**
> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.org  Tue Nov 15 17:53:35 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 17:53:35 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance noting
 subsequent behavior if protocol is disabled
Message-ID: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>

Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

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

Commit messages:
 - Update wording for SunJSSE provider.
 - Initial revision.

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

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

From darcy at openjdk.org  Tue Nov 15 17:53:36 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Nov 2022 17:53:36 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <QL270-p64Gwgmm_nGnQMmmFN3Wxkp4ymQnZaFF6OeAo=.728937f2-c68f-4b5e-a271-b8e15abed62c@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

Marked as reviewed by darcy (Reviewer).

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

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

From xuelei at openjdk.org  Tue Nov 15 18:30:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 18:30:16 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking.  Here are some cases I'm aware of:
1. the protocol is disabled with Security property
2. the protocol is not set while setting the SSLParameters
3. the protocol is not set while set the enabled protocol
4. the protocol is not supported by the peer
5. the protocol is not supported by any cipher suites enabled.

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

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

From mullan at openjdk.org  Tue Nov 15 18:40:04 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 18:40:04 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
Message-ID: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>

On Tue, 15 Nov 2022 18:27:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> 
> 1. the protocol is disabled with Security property
> 2. the protocol is not set while setting the SSLParameters
> 3. the protocol is not set while set the enabled protocol
> 4. the protocol is not supported by the peer
> 5. the protocol is not supported by any cipher suites enabled.

Good point, but I feel that should be handled in a separate issue, if necessary. Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.

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

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

From dfuchs at openjdk.org  Tue Nov 15 18:40:58 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Nov 2022 18:40:58 GMT
Subject: Integrated: 8296889: Race condition when cancelling a request
In-Reply-To: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
References: <TjoSb1SE1D5jUcgkokdWYHoTcTLwnlsMQ2_9j7Yggxs=.04cb65d6-a8a8-49e7-9d3e-21a0c51397a6@github.com>
Message-ID: <FEps58hl3_KsTuMWlW07zziLhumNKejybO0ZCuccaic=.ea057422-185c-4dfe-bcc6-d9843d2b7fde@github.com>

On Fri, 11 Nov 2022 15:18:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The CancelRequest test was observed failing again after [JDK-8294916](https://bugs.openjdk.org/browse/JDK-8294916) was integrated: there is a small race condition window in the code that unregisters the request BodySubscriber when a request is cancelled: if the request cancellation happens after the body subscriber is registered but before it is subscribed it may not be unregistered. 
> 
> The solution is to register it only after it has been successfully subscribed.

This pull request has now been integrated.

Changeset: 7357a1a3
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7357a1a379ed79c6754a8093eb108cd82062880a
Stats:     27 lines in 4 files changed: 21 ins; 2 del; 4 mod

8296889: Race condition when cancelling a request

Reviewed-by: jpai

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

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

From xuelei at openjdk.org  Tue Nov 15 19:10:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 19:10:58 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
Message-ID: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>

On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> > 
> > 1. the protocol is disabled with Security property
> > 2. the protocol is not set while setting the SSLParameters
> > 3. the protocol is not set while set the enabled protocol
> > 4. the protocol is not supported by the peer
> > 5. the protocol is not supported by any cipher suites enabled.
> 
> Good point, but I feel that should be handled in a separate issue, if necessary.

If it will be addressed in the future issue, the current specification may need to weight the impact in.  Otherwise, the specification added here might need to re-work to cover more cases.

> Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.

I understand the concerns.  There are many cases in security components that an instance could return, but will not work in the following process if not set or configured properly.   The impact of disabled properties is just one case of many.  Maybe, a simple description is sufficient, "the instance may not work if not configured or set properly, for example ... ".

It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as  an application still can have the protocol back by overriding the default security properties.

BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol.  It is more of a context-algorithm.  For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3.  It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2.  In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.

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

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

From xuelei at openjdk.org  Tue Nov 15 19:16:07 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 15 Nov 2022 19:16:07 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
Message-ID: <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>

On Tue, 15 Nov 2022 19:07:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.

I may be wrong.  The security property may be just loaded one time, and the follow-on update will not take effect.  If it is the case, is it an option to stop at  SSLContext.getInstance()?

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

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

From mullan at openjdk.org  Tue Nov 15 22:14:06 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 22:14:06 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <uwtKczbW2Hf3qN9uaMpE58reGbYfK5xuw9SWXpAJNUM=.7ad26adb-3a34-4eb5-9358-bbe58ec2c625@github.com>
Message-ID: <ie3peEkx2TL9hjiU8rSK-E39PdhjZwyjJDxk6z-bAN8=.b756abe4-f842-4d04-92f3-6e09a5b2a2c6@github.com>

On Tue, 15 Nov 2022 19:12:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.
> 
> I may be wrong. The security property may be just loaded one time, and the follow-on update will not take effect. If it is the case, is it an option to stop at SSLContext.getInstance()?

It is not specified if the property is read only once or multiple times. However, the JDK implementation reads it once and also when it creates an SSLContext, so there is no chance to modify it later.

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

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

From mullan at openjdk.org  Tue Nov 15 22:56:09 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Nov 2022 22:56:09 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
Message-ID: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>

On Tue, 15 Nov 2022 19:07:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> If it will be addressed in the future issue, the current specification may need to weight the impact in. Otherwise, the specification added here might need to re-work to cover more cases.

Which is fine. But we can still cover the behavior of `jdk.tls.disabledAlgorithms` in this one.

> > Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. The JCK team requested this clarification.
> 
> I understand the concerns. There are many cases in security components that an instance could return, but will not work in the following process if not set or configured properly. The impact of disabled properties is just one case of many. Maybe, a simple description is sufficient, "the instance may not work if not configured or set properly, for example ... ".

But I don't think there is general confusion over those other scenarios, so I am wary about going down that path where we feel obligated to document all possible scenarios. People using TLS should already know that a connection may not succeed for various reasons and the SSLException should provide a good reason for that. However, this one is not very visible and could be somewhat surprising.  An application may want to query the `jdk.tls.disabledAlgorithms` property and make sure the protocol is not disabled before creating the `SSLContext`. Although, in practice, we recommend calling `SSLContext.getDefault`.

> It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as an application still can have the protocol back by overriding the default security properties.

It won't work - see my other reply.

> 
> BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol. It is more of a context-algorithm. For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3. It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2. In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.

Yes, it might be useful to add something like "The returned SSLContext implements the specified protocol version, and may also implement other protocol versions." But I think it could be covered in a separate issue.

The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported.

I would like to hear from others if they feel this note is useful, or if it is opening up more questions that not.

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

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

From xuelei at openjdk.org  Wed Nov 16 03:06:57 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 03:06:57 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
Message-ID: <mA-_UuDQMPa1lG0YRfGSrYHS5omjxwydQi6qcW4Vfwk=.8d4e6597-bf3f-4af9-8f93-63ed5faee83a@github.com>

On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > As you are already there, it may be nice to cover more options that the protocol may not be used for the handshaking. Here are some cases I'm aware of:
> > 
> > 1. the protocol is disabled with Security property
> > 2. the protocol is not set while setting the SSLParameters
> > 3. the protocol is not set while set the enabled protocol
> > 4. the protocol is not supported by the peer
> > 5. the protocol is not supported by any cipher suites enabled.
> 
> Good point, but I feel that should be handled in a separate issue, if necessary. Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. 

I think it twice.  It may be not necessary to invoke additional methods subsequently by the application.  The impact could be configurations (security properties, key store, etc) other than `jdk.tls.disabledAlgorithms`.

> For this one, it may be a bit surprising for the SSLContext to be returned when the protocol is disabled (although it is still compliant with the API as specified), and then later it doesn't work, so the implementation note is useful. 

If the purpose is to make sure an SSLContext instance work later, more options may be considered.  IMO, I did not see the value if we cannot make the description in a general  and accuracy way.  The "jdk.tls.disabledAlgorithms" is just one of many impacts.   All jdk.xxx.disabledAlgorithms properties could play a role to break the connection.  It may be not enough to check the  "jdk.tls.disabledAlgorithms" and than can make sure an SSLContext instance will work for sure.

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

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

From xuelei at openjdk.org  Wed Nov 16 03:26:56 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 03:26:56 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
Message-ID: <8QrsCBwCGMyThrsz89sQybEo0C4kZSPgmo7YB_OWjlE=.35a376a4-b625-4241-9c82-a646935af0d8@github.com>

On Tue, 15 Nov 2022 22:53:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol. It is more of a context-algorithm. For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3. It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2. In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.
> 
> Yes, it might be useful to add something like "The returned SSLContext implements the specified protocol version, and may also implement other protocol versions." But I think it could be covered in a separate issue.
> 

I was not meant to add this kind of description.  I meant that the "specified protocol" in the description is not a TLS protocol version, and hence it could not be referred as TLS protocol version.

> The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported.

I may be wrong.  But let me check.  For example, the code looks like:
`    SSLContext context = SSLContext.getInstance("TLSv1.3");
`
 
Per "The wording in this PR specifically refers to the protocol version that was specified", I guess "the protocol version that was specified" is "TLSv1.3".  And for code like `SSLContext context = SSLContext.getInstance("TLSv1.2");` I guess the "the protocol version that was specified" is "TLSv1.2".


If the property looks like `jdk.tls.disabledAlgorithms=TLSv1.3`, the `"TLSv1.3"` specified in the security property is not the one specified in `SSLContext.getInstance("TLSv1.3");`. They are two different concepts.  The one in `SSLContext.getInstance("TLSv1.3");` refers to SSLContext protocol, while the one  in `jdk.tls.disabledAlgorithms=TLSv1.3` refers to TLS versions.

However, in the following description:

     * ... However, if the specified provider is "SunJSSE",
     * subsequent operations that attempt to use the specified protocol will
     * fail with an {@code SSLHandshakeException}."

if "the specified protocol" is referring to TLS version, it is not correct. 

If I get it right, the context in the example above can be used to establish connections for TLS 1.0/1.1/1.2.  The description in the PR , "will fail with ...", may be not true.

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

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

From michaelm at openjdk.org  Wed Nov 16 08:16:04 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 16 Nov 2022 08:16:04 GMT
Subject: RFR: 8288717: Add a means to close idle connections in HTTP/2
 connection pool [v7]
In-Reply-To: <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
 <vZjnaYcjSmjwFbejCuRdEkrisbAadXtuJAH8CDdnolY=.4112097f-2324-46e6-9ad3-e6ce9b7796a9@github.com>
Message-ID: <9tyMjMFSpBI9t_VyY3tOWsxWGSnZJjfdAwhuYbnWmM4=.327fbfa9-18ca-41d0-a5ad-bfd22d675067@github.com>

On Tue, 15 Nov 2022 12:10:00 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
>> 
>> **Proposed Solution**
>> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288717: Changed default keep alive value to original

This looks good now. Thanks!

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

Marked as reviewed by michaelm (Reviewer).

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

From dfuchs at openjdk.org  Wed Nov 16 12:24:10 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Nov 2022 12:24:10 GMT
Subject: RFR: 8297132: BACKOUT JDK-8296889: Race condition when cancelling a
 request
Message-ID: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>

This fix for [JDK-8296889](https://bugs.openjdk.org/browse/JDK-8296889) is causing trouble with the CancelStreamedBodyTest. Let's back it out until a better solution is found.

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

Commit messages:
 - 8297132

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

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

From dfuchs at openjdk.org  Wed Nov 16 12:32:56 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Nov 2022 12:32:56 GMT
Subject: RFR: 8297132: BACKOUT JDK-8296889: Race condition when cancelling
 a request
In-Reply-To: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
References: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
Message-ID: <6EWvli5GPvDjbOBRNyYMq4mNlyGjCd81LuIQarB63cc=.6f3b0d03-e918-4f02-ab3b-4a3d5f8823b9@github.com>

On Wed, 16 Nov 2022 12:16:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This fix for [JDK-8296889](https://bugs.openjdk.org/browse/JDK-8296889) is causing trouble with the CancelStreamedBodyTest. Let's back it out until a better solution is found.

The commit was produced with `git revert --no-commit 7357a1a379ed79c6754a8093eb108cd82062880a`

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

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

From djelinski at openjdk.org  Wed Nov 16 12:37:33 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 16 Nov 2022 12:37:33 GMT
Subject: RFR: 8297132: BACKOUT JDK-8296889: Race condition when cancelling
 a request
In-Reply-To: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
References: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
Message-ID: <gQbRBfEH7YgpBH4TErG1uZIUMKexLkyiSfFokydcn90=.5e7fd073-7fc1-42da-81c3-d4f419ae6951@github.com>

On Wed, 16 Nov 2022 12:16:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This fix for [JDK-8296889](https://bugs.openjdk.org/browse/JDK-8296889) is causing trouble with the CancelStreamedBodyTest. Let's back it out until a better solution is found.

Marked as reviewed by djelinski (Committer).

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

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

From pminborg at openjdk.org  Wed Nov 16 13:12:11 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Nov 2022 13:12:11 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
Message-ID: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>

This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.

Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

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

Commit messages:
 - Add a @sealedGraph tag to InetAddress

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

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

From alanb at openjdk.org  Wed Nov 16 13:14:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 13:14:31 GMT
Subject: RFR: 8297132: BACKOUT JDK-8296889: Race condition when cancelling
 a request
In-Reply-To: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
References: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
Message-ID: <vFk1bEsh0mZggIqcw1koP2NZ0zSZGGuUJrhVVXS9zZ4=.cca04717-8aeb-47bd-8518-f47c63f9098f@github.com>

On Wed, 16 Nov 2022 12:16:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This fix for [JDK-8296889](https://bugs.openjdk.org/browse/JDK-8296889) is causing trouble with the CancelStreamedBodyTest. Let's back it out until a better solution is found.

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.org  Wed Nov 16 13:19:30 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Nov 2022 13:19:30 GMT
Subject: Integrated: 8297132: BACKOUT JDK-8296889: Race condition when
 cancelling a request
In-Reply-To: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
References: <vAUSt8FOXNNzZDFe7aGsoZM7t7Qqcpxx7ASY_n8qaD8=.dcecf293-4519-407c-a7fa-b3e06068b41b@github.com>
Message-ID: <Y-rMmtbA-q-pocn_IWApR1CpBFVrpPyMlLntd0TM7cs=.043f6af2-2ac3-49fd-b26b-d633be8cb186@github.com>

On Wed, 16 Nov 2022 12:16:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This fix for [JDK-8296889](https://bugs.openjdk.org/browse/JDK-8296889) is causing trouble with the CancelStreamedBodyTest. Let's back it out until a better solution is found.

This pull request has now been integrated.

Changeset: 8b1ff9e3
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b1ff9e37efc42aeb05170463ec330c221ce1e4c
Stats:     27 lines in 4 files changed: 2 ins; 21 del; 4 mod

8297132: BACKOUT JDK-8296889: Race condition when cancelling a request

Reviewed-by: djelinski, alanb

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

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

From pminborg at openjdk.org  Wed Nov 16 14:51:06 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Nov 2022 14:51:06 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
Message-ID: <1AWNqynfGU52y8FW3f_VRlG-IcgfPp3EPRqSFjo85tk=.65db0777-d995-4aea-b299-2fdd0e50ca13@github.com>

On Wed, 16 Nov 2022 13:03:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

Here is how it looks like:

<img width="403" alt="InetAddress_SH" src="https://user-images.githubusercontent.com/7457876/202212665-b8d34ebc-1c41-4aeb-8bc7-6892c2745429.png">

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

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

From jpai at openjdk.org  Wed Nov 16 15:08:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Nov 2022 15:08:16 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <1uAPktBWLTKno6kIOdASz7oiaU5ZgjKDhe755DgUmro=.2fdee4ab-b314-4ad2-a206-f34a7185642d@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
 <1uAPktBWLTKno6kIOdASz7oiaU5ZgjKDhe755DgUmro=.2fdee4ab-b314-4ad2-a206-f34a7185642d@github.com>
Message-ID: <w1oFeyYSsV7_IRa5N9iUvqqK_UOey-okbczf1fHaO-8=.484b6f01-e6c6-4f69-aba0-fe7789188701@github.com>

On Wed, 16 Nov 2022 15:02:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>  A general question - should we be doing a similar thing for other classes in this module?

I just noticed you have another PR which does a similar thing for another class in this module. So that answers my question. Approving this current PR.

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

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

From jpai at openjdk.org  Wed Nov 16 15:08:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Nov 2022 15:08:16 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
Message-ID: <1uAPktBWLTKno6kIOdASz7oiaU5ZgjKDhe755DgUmro=.2fdee4ab-b314-4ad2-a206-f34a7185642d@github.com>

On Wed, 16 Nov 2022 13:03:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

Marked as reviewed by jpai (Reviewer).

Hello Per, this looks fine to me. A general question - should we be doing a similar thing for other classes in this module?

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

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

From pminborg at openjdk.org  Wed Nov 16 15:35:06 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Nov 2022 15:35:06 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <w1oFeyYSsV7_IRa5N9iUvqqK_UOey-okbczf1fHaO-8=.484b6f01-e6c6-4f69-aba0-fe7789188701@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
 <1uAPktBWLTKno6kIOdASz7oiaU5ZgjKDhe755DgUmro=.2fdee4ab-b314-4ad2-a206-f34a7185642d@github.com>
 <w1oFeyYSsV7_IRa5N9iUvqqK_UOey-okbczf1fHaO-8=.484b6f01-e6c6-4f69-aba0-fe7789188701@github.com>
Message-ID: <x4xUEo2dKzuQbcSBJfZUc7wA4sUHkGcLQ-Efh2kLD0I=.0a3dfa07-8460-4590-a5e1-c20a8a25e2cf@github.com>

On Wed, 16 Nov 2022 15:03:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Per, this looks fine to me. A general question - should we be doing a similar thing for other classes in this module?
>
>>  A general question - should we be doing a similar thing for other classes in this module?
> 
> I just noticed you have another PR which does a similar thing for another class in this module. So that answers my question. Approving this current PR.

Thanks @jaikiran. I opted to issue one PR per class as there might be different opinions if we should expose the graph or not.

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

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

From aefimov at openjdk.org  Wed Nov 16 16:24:03 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 16 Nov 2022 16:24:03 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
Message-ID: <I5pvAA3mBe_zzNvBiMYphaR2uQc0dUHlaDQxWQxEld0=.326fce4a-8a25-47ac-9fa3-97109db20cfd@github.com>

On Wed, 16 Nov 2022 13:03:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

Hi Per,
The change looks good to me. And the new `InetAddress` hierarchy graph looks great too ?

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

Marked as reviewed by aefimov (Committer).

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

From pminborg at openjdk.org  Wed Nov 16 16:30:05 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Nov 2022 16:30:05 GMT
Subject: RFR: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
Message-ID: <1mwpHZebuWs4nh260DfiQUN5fG_IRmHxWovbMGeT8NY=.b3e2a97f-0fb1-46e7-b9d2-262670cac400@github.com>

On Wed, 16 Nov 2022 13:03:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

Thanks for the encouraging comments. Please /sponsor this PR.

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

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

From mullan at openjdk.org  Wed Nov 16 16:34:08 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Nov 2022 16:34:08 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> > The wording in this PR specifically refers to the protocol version that
> 
> was specified. It isn't covering other optional protocols that may be supported.
> 
> Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version. 

Where in the javadoc APIs does it say that? I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.

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

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

From pminborg at openjdk.org  Wed Nov 16 16:44:29 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Nov 2022 16:44:29 GMT
Subject: Integrated: 8297134: Add a @sealedGraph tag to InetAddress
In-Reply-To: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
References: <KfZEHkRfDPnAurVqzoy75IRRHmNzp39dzS3qietvF4A=.86b3f489-bfdc-489f-8346-8dcc9c1ed052@github.com>
Message-ID: <w2VRAA-yJGHguMxEqI4pCGuNkN9ROyDE4TreOxKYDZg=.79b317bb-5c4c-4a7a-bcde-a5984244cc3c@github.com>

On Wed, 16 Nov 2022 13:03:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `InetAddress` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

This pull request has now been integrated.

Changeset: 51f690de
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51f690decbfa9d2d9aa082d145f716b3596f8cf7
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8297134: Add a @sealedGraph tag to InetAddress

Reviewed-by: jpai, aefimov

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

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

From xuelei at openjdk.org  Wed Nov 16 17:42:05 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 16 Nov 2022 17:42:05 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
Message-ID: <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>

On Wed, 16 Nov 2022 16:31:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> > > The wording in this PR specifically refers to the protocol version that
> > 
> > 
> > was specified. It isn't covering other optional protocols that may be supported.
> > Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version.
> 
> Where in the javadoc APIs does it say that?

The Javadoc APIs specification does not say it is referring to TLS protocol version.  In the standard algorithm documentation, the word "SSLContext Algorithms" is used and here is an example:


Algorithm Name | Description
-- | --
TLSv1.2 | Supports?RFC 5246: TLS version 1.2; may support other SSL/TLS versions


> I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.

Yes.  So we cannot assume that the literal SSLContext algorithm is the only supported TLS version for an JSSE provider, including the SunJSSE provider.

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

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

From dfuchs at openjdk.org  Wed Nov 16 19:01:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Nov 2022 19:01:09 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request
Message-ID: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>

Please find here a re-do fix for the race condition while cancelling request.
The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
This is fixed in this new iteration.

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

Commit messages:
 - Fix issue list
 - 8297149

Changes: https://git.openjdk.org/jdk/pull/11193/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297149
  Stats: 44 lines in 5 files changed: 31 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11193/head:pull/11193

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

From xuelei.f at gmail.com  Wed Nov 16 01:20:43 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Tue, 15 Nov 2022 17:20:43 -0800
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <RKULkdxBW6KplhLCPN_6UbHUYM-1CyLgS6K2C81Hohg=.b239d289-5ad9-4995-ab44-68c8cfd71598@github.com>
 <fBDYSrZ2Mhed53dkWZqyeN4h_ym-l2KLUnGkyf-B1KQ=.fe7a542b-5fd0-43d3-bcc8-2d3b23cebb4f@github.com>
 <7znFxoiBQn2vpnsM_CoZJHY32q57HVK2LE0ml3OMja0=.8cdf7390-3c8a-4475-990a-65969474cded@github.com>
 <_aKb9BZYx0AZqg1lmKxNcPGtILzKlIuFTkrphhrL8sE=.0a689b03-fd9b-4fd8-9c1e-141bab7936e6@github.com>
Message-ID: <CAPJ=zzjJ4R-awP7RFJhXEJnY0NHM1sjk6bSr_gEW-Tgzyz6o2Q@mail.gmail.com>

> The wording in this PR specifically refers to the protocol version that
was specified. It isn't covering other optional protocols that may be
supported.

Sorry, I may not make it clear.  The protocol specified in
SSLContext.getInstance is not TLS protocol version.  I think the protocol
disabled in security properties refers to protocol version.  The new added
specification in this PR would better avoid the confusing.  If you want the
specified protocol referring to TLS version, the handshake may still
success even the TLS version is disabled. If you means the specified
protocol as SSLContext algorithm, I am not sure if the current security
properties supporting disabling of SSLContext algorithm.

Hope it helps!

Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20221115/6698b475/attachment.htm>

From jpai at openjdk.org  Thu Nov 17 01:26:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Nov 2022 01:26:20 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request
In-Reply-To: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
Message-ID: <jU-3oPQThLunClx24PQRt0qfiBqBIYn4f93OTOueSMw=.a4d8e02c-85d7-496d-9e09-9dae4cd741e8@github.com>

On Wed, 16 Nov 2022 18:52:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a re-do fix for the race condition while cancelling request.
> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
> This is fixed in this new iteration.

src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 138:

> 136: 
> 137:     /**
> 138:      * Called right after the userSubscriber::onSubscribe is called.

Hello Daniel, I suspect this comment will need a change now, since the implementation in this PR now calls `onSubscribed` before the `userSubscriber::onSubscribe`.

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

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

From jpai at openjdk.org  Thu Nov 17 01:33:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Nov 2022 01:33:54 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request
In-Reply-To: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
Message-ID: <15VWYW4kLQWv4ImsLcvqE_TSb0tOhIEoN4A4ypvflbg=.89d072f4-a205-4b7d-8720-1fe39b1e3fa8@github.com>

On Wed, 16 Nov 2022 18:52:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a re-do fix for the race condition while cancelling request.
> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
> This is fixed in this new iteration.

src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 188:

> 186:         // race condition with propagateError: we need to wait until
> 187:         // subscription is finished before calling onError;
> 188:         subscriptionLock.lock();

More of a question than a review comment - I see that the only place in this class where we were using `synchronized` is while dealing with the `subscribed`. The PR replaces the `synchronized` blocks with a `ReentrantLock`. Does that have an advantage in context of this code?

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

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

From ccleary at openjdk.org  Thu Nov 17 08:42:55 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 17 Nov 2022 08:42:55 GMT
Subject: Integrated: 8288717: Add a means to close idle connections in HTTP/2
 connection pool
In-Reply-To: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
References: <nYrrnyUMQ5os9DMDQn1g2BD1xTol2NISaBeIs51BsQQ=.cc54d20a-8913-474c-a1af-1dc743748d43@github.com>
Message-ID: <BD6tZQ13eUboY_VQdowu94Qmw9585ffX1oW7TyN2aIY=.b2a357a4-e0c6-4c51-a785-a3513d2069b7@github.com>

On Tue, 6 Sep 2022 13:56:15 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> When using HTTP/2 with the HttpClient, it can often be necessary to close an idle Http2 Connection before a server sends a GOAWAY frame. For example, a server or cloud based tool could close a TCP connection silently when it is idle for too long resulting in ConnectionResetException being thrown by the HttpClient.
> 
> **Proposed Solution**
> A new system property, `jdk.httpclient.idleConnectionTimeout`, was added and is used to specify in Milliseconds how long an idle connection (idle connections are those which have no currently active streams) for the HttpClient before the connection is closed.

This pull request has now been integrated.

Changeset: b9db16ab
Author:    Conor Cleary <ccleary at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9db16ab097058903cfd12d25becbbe802957143
Stats:     278 lines in 4 files changed: 273 ins; 2 del; 3 mod

8288717: Add a means to close idle connections in HTTP/2 connection pool

Reviewed-by: dfuchs, michaelm

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

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

From dfuchs at openjdk.org  Thu Nov 17 09:59:50 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Nov 2022 09:59:50 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request
In-Reply-To: <jU-3oPQThLunClx24PQRt0qfiBqBIYn4f93OTOueSMw=.a4d8e02c-85d7-496d-9e09-9dae4cd741e8@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
 <jU-3oPQThLunClx24PQRt0qfiBqBIYn4f93OTOueSMw=.a4d8e02c-85d7-496d-9e09-9dae4cd741e8@github.com>
Message-ID: <H5WVYdCtYCTLYjBSESThJCoe02vLNKfR6Y8af-Tzfh4=.e58f13c3-b21d-4847-8ec1-f49c7cae452e@github.com>

On Thu, 17 Nov 2022 01:23:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please find here a re-do fix for the race condition while cancelling request.
>> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
>> This is fixed in this new iteration.
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 138:
> 
>> 136: 
>> 137:     /**
>> 138:      * Called right after the userSubscriber::onSubscribe is called.
> 
> Hello Daniel, I suspect this comment will need a change now, since the implementation in this PR now calls `onSubscribed` before the `userSubscriber::onSubscribe`.

Ah! Good catch.

> src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 188:
> 
>> 186:         // race condition with propagateError: we need to wait until
>> 187:         // subscription is finished before calling onError;
>> 188:         subscriptionLock.lock();
> 
> More of a question than a review comment - I see that the only place in this class where we were using `synchronized` is while dealing with the `subscribed`. The PR replaces the `synchronized` blocks with a `ReentrantLock`. Does that have an advantage in context of this code?

Well - I am not sure. The code within the block calls onSubscribe on the user subscriber. Theoretically, this should not block, but it might kick off a loop (via calling subscription::request) that may run in the current thread for a while. Using a lock ensures that the waiter will be well-behaved for virtual threads if that ever happens - and no carrier thread will be pinned because of this.

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

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

From dfuchs at openjdk.org  Thu Nov 17 10:08:44 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Nov 2022 10:08:44 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request [v2]
In-Reply-To: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
Message-ID: <xQAzEScCtZVYovx8sJckVRuw8GTxVtn9MhgGaG2b_40=.d68999de-c16c-44ab-9037-72718cb2a644@github.com>

> Please find here a re-do fix for the race condition while cancelling request.
> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
> This is fixed in this new iteration.

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

  Fixed onSubscribed() doc comment and override access qualifiers (protected vs public)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11193/files
  - new: https://git.openjdk.org/jdk/pull/11193/files/fd527d54..60bbce6d

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

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

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

From jpai at openjdk.org  Thu Nov 17 10:13:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Nov 2022 10:13:43 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request [v2]
In-Reply-To: <xQAzEScCtZVYovx8sJckVRuw8GTxVtn9MhgGaG2b_40=.d68999de-c16c-44ab-9037-72718cb2a644@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
 <xQAzEScCtZVYovx8sJckVRuw8GTxVtn9MhgGaG2b_40=.d68999de-c16c-44ab-9037-72718cb2a644@github.com>
Message-ID: <0KRW2TL0QFqMM25vir877B2j-WVC31HG3C7xudyLSjg=.c3b721a4-d1e2-4526-a0e0-08d038bc7e16@github.com>

On Thu, 17 Nov 2022 10:08:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a re-do fix for the race condition while cancelling request.
>> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
>> This is fixed in this new iteration.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed onSubscribed() doc comment and override access qualifiers (protected vs public)

The latest changes in 60bbce6d look good to me.

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Thu Nov 17 10:13:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Nov 2022 10:13:44 GMT
Subject: RFR: 8297149: REDO JDK-8296889: Race condition when cancelling a
 request [v2]
In-Reply-To: <H5WVYdCtYCTLYjBSESThJCoe02vLNKfR6Y8af-Tzfh4=.e58f13c3-b21d-4847-8ec1-f49c7cae452e@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
 <jU-3oPQThLunClx24PQRt0qfiBqBIYn4f93OTOueSMw=.a4d8e02c-85d7-496d-9e09-9dae4cd741e8@github.com>
 <H5WVYdCtYCTLYjBSESThJCoe02vLNKfR6Y8af-Tzfh4=.e58f13c3-b21d-4847-8ec1-f49c7cae452e@github.com>
Message-ID: <IVnLEaIQvKzD10MxsH5rsayuYaRdGx6f4qwSpbkT1HI=.5237245e-1b18-4dbf-a735-1b3909220837@github.com>

On Thu, 17 Nov 2022 09:56:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 188:
>> 
>>> 186:         // race condition with propagateError: we need to wait until
>>> 187:         // subscription is finished before calling onError;
>>> 188:         subscriptionLock.lock();
>> 
>> More of a question than a review comment - I see that the only place in this class where we were using `synchronized` is while dealing with the `subscribed`. The PR replaces the `synchronized` blocks with a `ReentrantLock`. Does that have an advantage in context of this code?
>
> Well - I am not sure. The code within the block calls onSubscribe on the user subscriber. Theoretically, this should not block, but it might kick off a loop (via calling subscription::request) that may run in the current thread for a while. Using a lock ensures that the waiter will be well-behaved for virtual threads if that ever happens - and no carrier thread will be pinned because of this.

Thank you for that detail. I was suspecting the virtual thread usecase is what might have prompted this but wanted to be sure.

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

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

From dfuchs at openjdk.org  Thu Nov 17 15:12:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Nov 2022 15:12:32 GMT
Subject: Integrated: 8297149: REDO JDK-8296889: Race condition when cancelling
 a request
In-Reply-To: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
References: <20crJp4QKQiDjdlm5-3FYGHmgswZsHJhaIHNm3JhW9M=.4f670f78-8014-48ea-86c7-f2b7cc82f770@github.com>
Message-ID: <ZI9qR0R23wTCUjFtEoNuJHi3Xc1wxsUmauYGq-3Ajps=.29294b9a-f4b2-45cd-8503-847195e00926@github.com>

On Wed, 16 Nov 2022 18:52:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a re-do fix for the race condition while cancelling request.
> The previous fix failed because it registered the subscriber too late (after having called userSubsciber.onSubscribe()), which opened a window for the call to unregister to occur before the call to register.
> This is fixed in this new iteration.

This pull request has now been integrated.

Changeset: 134acab5
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/134acab5a40b3f927ff6343aa49477a490e410b5
Stats:     44 lines in 5 files changed: 31 ins; 6 del; 7 mod

8297149: REDO JDK-8296889: Race condition when cancelling a request
8297075: java/net/httpclient/CancelStreamedBodyTest.java fails with "java.lang.AssertionError: WARNING: tracker for HttpClientImpl(1) has outstanding operations"

Reviewed-by: jpai

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

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

From darcy at openjdk.org  Thu Nov 17 21:55:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Nov 2022 21:55:44 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview
Message-ID: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>

Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

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

Commit messages:
 - JDK-8297215: Update libs tests to use @enablePreview

Changes: https://git.openjdk.org/jdk/pull/11222/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297215
  Stats: 122 lines in 36 files changed: 33 ins; 1 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/11222.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222

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

From jjg at openjdk.org  Thu Nov 17 22:31:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 17 Nov 2022 22:31:43 GMT
Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java
Message-ID: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>

Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
(See https://bugs.openjdk.org/browse/JDK-8297165)

In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

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

Commit messages:
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297164
  Stats: 8944 lines in 29 files changed: 471 ins; 1589 del; 6884 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

From dholmes at openjdk.org  Fri Nov 18 02:35:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Nov 2022 02:35:11 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Hi @jonathan-gibbons ,

I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

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

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

From alanb at openjdk.org  Fri Nov 18 08:31:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Nov 2022 08:31:50 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>

On Thu, 17 Nov 2022 21:48:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

test/jdk/java/lang/Thread/BuilderTest.java line 29:

> 27:  * @enablePreview
> 28:  * @compile BuilderTest.java
> 29:  * @run testng/othervm BuilderTest

I assume `@compile` can be dropped from both of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes.

test/jdk/java/lang/Thread/virtual/JfrEvents.java line 31:

> 29:  * @enablePreview
> 30:  * @compile JfrEvents.java
> 31:  * @run testng/othervm JfrEvents

This one needs to be /othervm.

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

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

From michaelm at openjdk.org  Fri Nov 18 13:58:15 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 18 Nov 2022 13:58:15 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info
Message-ID: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>

Hi,

Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)

Thanks,
Michael

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

Commit messages:
 - first draft

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

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

From dfuchs at openjdk.org  Fri Nov 18 14:38:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 18 Nov 2022 14:38:21 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <BxbwluPXtfNYRLmUIYS346lf58QHu8egYJA_GfVx3nM=.75db71ff-0a19-494e-84ac-197bfb9a92f5@github.com>

On Fri, 18 Nov 2022 13:50:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

I think we should limit ourselves to document properties that are of interest to users of the API - so probably looking at what is documented in the [Java Core Libraries Developer's Guide](https://docs.oracle.com/en/java/javase/19/core/java-networking.html#GUID-86B96A42-74FE-4E7D-8E60-D64A03862083)

Also it should be made clear that these system properties should be specified on the java command line (no guarantee that a value specified with System.setProperty() willl be taken into account) and are implementation specific properties, not part of the specification. That is - another implementation of `java.net.http.HttpClient` may not support them or may support a different set.

src/java.net.http/share/classes/module-info.java line 96:

> 94:  * <li><p><b>{@systemProperty jdk.httpclient.keepalive.timeout}</b> (default: 1200)<br>
> 95:  * The number of seconds to keep idle HTTP/1.1 connections alive in the keep alive cache.
> 96:  * </li>

This is no longer strictly true. Also `jdk.httpclient.keepalive.timeout.h2` should be documented, see [JDK-8295649](https://bugs.openjdk.org/browse/JDK-8295649)

src/java.net.http/share/classes/module-info.java line 134:

> 132:  * <li><p><b>{@systemProperty jdk.internal.httpclient.hpack.debug}</b> (default: false)<br>
> 133:  * Enables general HTTP/2 HPACK debug tracing.
> 134:  * </li>

These three *.debug properties are too low level and should not be documented.

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

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

From darcy at openjdk.org  Fri Nov 18 18:45:01 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Nov 2022 18:45:01 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2]
In-Reply-To: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
Message-ID: <C2vP-llqT9p0j3HEIijDyZfDdUP7T1uOBxGW7fswZtQ=.04f824f8-91f1-4ff7-86fd-98ef6fa0db97@github.com>

> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11222/files
  - new: https://git.openjdk.org/jdk/pull/11222/files/88a566c6..f3fc9e26

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

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

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

From darcy at openjdk.org  Fri Nov 18 18:45:03 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Nov 2022 18:45:03 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2]
In-Reply-To: <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>
Message-ID: <rabpzS3ujhWVgkcUrO8FlWygff6uhZAhk8tGHVhb0Zk=.47e1d912-a80a-473c-b9d8-d3104aba54c9@github.com>

On Fri, 18 Nov 2022 08:28:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/jdk/java/lang/Thread/BuilderTest.java line 29:
> 
>> 27:  * @enablePreview
>> 28:  * @compile BuilderTest.java
>> 29:  * @run testng/othervm BuilderTest
> 
> I assume `@compile` can be dropped from most of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes.

Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient.

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

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

From jjg at openjdk.org  Fri Nov 18 18:56:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 18 Nov 2022 18:56:31 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <D3Q8gAsHMilCljln-KmHdt5XFxlSuD6aexymC8Bznm4=.7c5b2d08-2bb8-4909-aab6-d73fa4e14afe@github.com>
Message-ID: <l58Z_Qi8-iqqqDhcbhgRgqetaiapUzMdHPPpqMgXzPY=.83952a70-fb4a-43e0-8d1b-4ec22689e398@github.com>

On Fri, 18 Nov 2022 02:31:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi @jonathan-gibbons ,
> 
> I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly?

Yes, at least in all the files I verified and I have no reason to believe it might be different in any other files.

On a Mac, you can just do `man <path-to-file>` to render the contents of a troff file. That is how I checked the files that I did.

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

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

From alanb at openjdk.org  Fri Nov 18 19:08:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Nov 2022 19:08:24 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2]
In-Reply-To: <rabpzS3ujhWVgkcUrO8FlWygff6uhZAhk8tGHVhb0Zk=.47e1d912-a80a-473c-b9d8-d3104aba54c9@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>
 <rabpzS3ujhWVgkcUrO8FlWygff6uhZAhk8tGHVhb0Zk=.47e1d912-a80a-473c-b9d8-d3104aba54c9@github.com>
Message-ID: <LUd4rFPP2MnDiLQ1vdWtco72N7yATog-SoXZ3U8iCOA=.3c726745-ee86-43c3-b64a-f88c86af1d71@github.com>

On Fri, 18 Nov 2022 18:38:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/BuilderTest.java line 29:
>> 
>>> 27:  * @enablePreview
>>> 28:  * @compile BuilderTest.java
>>> 29:  * @run testng/othervm BuilderTest
>> 
>> I assume `@compile` can be dropped from most of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes.
>
> Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient.

`@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`.   I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area.

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

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

From darcy at openjdk.org  Fri Nov 18 21:32:19 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Nov 2022 21:32:19 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2]
In-Reply-To: <LUd4rFPP2MnDiLQ1vdWtco72N7yATog-SoXZ3U8iCOA=.3c726745-ee86-43c3-b64a-f88c86af1d71@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>
 <rabpzS3ujhWVgkcUrO8FlWygff6uhZAhk8tGHVhb0Zk=.47e1d912-a80a-473c-b9d8-d3104aba54c9@github.com>
 <LUd4rFPP2MnDiLQ1vdWtco72N7yATog-SoXZ3U8iCOA=.3c726745-ee86-43c3-b64a-f88c86af1d71@github.com>
Message-ID: <nQtrninQMXoU9Wnv8JJCW5c8YCVja0em6juzOu_YHd8=.b4febfbc-4b73-4c04-91b3-8bec0de30d81@github.com>

On Fri, 18 Nov 2022 19:06:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient.
>
> `@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`.   I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area.

I think I got most of those in the PR. There was a file or two I didn't update because not all the @compile/@run directives in the file used --enablePreview and the @enablePreview directive applies to all @compile and @run directives.

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

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

From alanb at openjdk.org  Sat Nov 19 08:32:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Nov 2022 08:32:10 GMT
Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2]
In-Reply-To: <nQtrninQMXoU9Wnv8JJCW5c8YCVja0em6juzOu_YHd8=.b4febfbc-4b73-4c04-91b3-8bec0de30d81@github.com>
References: <tc_tYnGZ-vffHa80jkOhsmVumjixoO9B-0D7xvbMo_I=.7577a2f4-b4c0-4bc8-93fe-1313077d1769@github.com>
 <M0Fj2x_ae9yHkf-F3Ro_vyiXiY7y0V1NQSX4vYbyxAc=.5f31bdd6-77e0-4cd1-913f-fc669e7ff141@github.com>
 <rabpzS3ujhWVgkcUrO8FlWygff6uhZAhk8tGHVhb0Zk=.47e1d912-a80a-473c-b9d8-d3104aba54c9@github.com>
 <LUd4rFPP2MnDiLQ1vdWtco72N7yATog-SoXZ3U8iCOA=.3c726745-ee86-43c3-b64a-f88c86af1d71@github.com>
 <nQtrninQMXoU9Wnv8JJCW5c8YCVja0em6juzOu_YHd8=.b4febfbc-4b73-4c04-91b3-8bec0de30d81@github.com>
Message-ID: <sdvOjSLKx4Ho3A2PvWw-U3vT5hS84s-bJZTU9UFFmas=.e8e8941e-55f9-4231-b44e-45923fba1bdf@github.com>

On Fri, 18 Nov 2022 21:29:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> `@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`.   I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area.
>
> I think I got most of those in the PR. There was a file or two I didn't update because not all the @compile/@run directives in the file used --enablePreview and the @enablePreview directive applies to all @compile and @run directives.

Most of the tests in test/jdk/java/lang/Thread/virtual/ still have `@compile` and othervm, is it possible you didn't push the update with those changes?

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

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

From dholmes at openjdk.org  Mon Nov 21 01:35:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Nov 2022 01:35:20 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <RjHY72h2dKDge8MpnS7cKpLDKWBiwNVCBPYmd-uJfjY=.76af7ca7-77db-4d55-b097-d0641701aab8@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Looks okay.

Thanks for doing this before the end-of-release updates!

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

Marked as reviewed by dholmes (Reviewer).

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

From xuelei at openjdk.org  Mon Nov 21 06:38:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 21 Nov 2022 06:38:36 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
 <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
Message-ID: <7yv16ND_X74NRuQbKdOsiVu1RwY6ugNgXdlJQN7E01E=.60aa3666-6b8e-4d3a-b95f-8027fc8def7b@github.com>

On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Unfortunately, I only have author status and can only comment.
>> 
>> I think OpenJDK Author can approve as well.  I just need to get another Reviewer approval before integration.
>
>> > Unfortunately, I only have author status and can only comment.
>> 
>> I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.
> 
> For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.
> 
> I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

@seanjmullan Did you have cycle to review this PR and CSR?  This CSR is similar to the one we did for signature algorithms.  I was wondering if it is possible to have it in JDK 20 so that more specific TLS benchmarks could be introduced sooner.  Thanks!

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

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

From jpai at openjdk.org  Mon Nov 21 06:56:35 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 06:56:35 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-lenght in response
Message-ID: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>

Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.

No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

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

Commit messages:
 - 8297211: Expensive fillInStackTrace operation in HttpURLConnection.getOutputStream0 when no content-lenght in response

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

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

From simonis at openjdk.org  Mon Nov 21 10:56:03 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 21 Nov 2022 10:56:03 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response
In-Reply-To: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
Message-ID: <PRQpe3lG8b0oC7cVzMV86_mSP0OYWlKcsjqIzBJI7pY=.649b8ee2-d2d0-44c2-9ca1-86e227e09544@github.com>

On Mon, 21 Nov 2022 06:47:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
> 
> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

Your fix looks good, but there are two other places in the file with the same pattern in getHeaderFieldDate() and getHeaderFieldLong(). Can you please fix them as well?

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

Changes requested by simonis (Reviewer).

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

From pminborg at openjdk.org  Mon Nov 21 11:00:13 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:00:13 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
Message-ID: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>

This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 

Design choices in this PR:

There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.

The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.

In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.

On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".

I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.

This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

Commit messages:
 - Guard usages of DirectBuffer::address

Changes: https://git.openjdk.org/jdk/pull/11260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296024
  Stats: 277 lines in 26 files changed: 191 ins; 4 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From michaelm at openjdk.org  Mon Nov 21 11:00:54 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 21 Nov 2022 11:00:54 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v2]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <tIqbTGWxJqEXoTBlW-V-jbxE3PKlPs1Oe_rk8WFR3-A=.c3d7efd3-3320-46c7-840d-19e9638b4326@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  update after Daniel's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/4a99c86e..284aa8e2

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

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

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

From jpai at openjdk.org  Mon Nov 21 11:17:27 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 11:17:27 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
Message-ID: <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>

> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
> 
> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

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

  review suggestion - do a similar change in URLConnection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11258/files
  - new: https://git.openjdk.org/jdk/pull/11258/files/0b18b96f..441d3770

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

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

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

From jpai at openjdk.org  Mon Nov 21 11:17:28 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 11:17:28 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response
In-Reply-To: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
Message-ID: <LMymBPChW4BnunMv6ujsbq_cVE7DJgaT-51fem7X0O0=.c2a572b1-3b5d-46f8-b518-dcad08e850d0@github.com>

On Mon, 21 Nov 2022 06:47:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
> 
> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

Hello Volker, I have updated to PR to include those 3 places as well (there was one more in addition to the couple you noted).

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

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

From alanb at openjdk.org  Mon Nov 21 11:31:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:31:16 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/nio/Buffer.java line 785:

> 783:                 static final JavaNioAccess.SessionAcquisition NO_OP_CLOSE = new JavaNioAccess.SessionAcquisition() {
> 784:                     @Override
> 785:                     public void close() throws RuntimeException {}

The throws RuntimeException is not needed here. Also would it be possible to reflow the comment to avoid the wildly long line.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 161:

> 159: 
> 160:         @Override
> 161:         void close() throws RuntimeException;

You can drop throws RuntimeEXcepton here too.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 38:

> 36:     // try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 37:     //     performOperation(bb.address());
> 38:     // }

This comment is very messy and needs to be cleaned up.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:

> 250:         try {
> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
> 252:             // Hence, there is no need for acquiring any session.

This comment is will be confusing to anyone reading this code. Is this really needed?

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

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

From alanb at openjdk.org  Mon Nov 21 11:36:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:36:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/util/zip/Adler32.java line 102:

> 100:             return;
> 101:         if (buffer.isDirect()) {
> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {

We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

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

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

From pminborg at openjdk.org  Mon Nov 21 11:40:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:40:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
Message-ID: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>

On Mon, 21 Nov 2022 11:29:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
> 
>> 250:         try {
>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>> 252:             // Hence, there is no need for acquiring any session.
> 
> This comment is will be confusing to anyone reading this code. Is this really needed?

The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:09:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
Message-ID: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>

On Mon, 21 Nov 2022 11:32:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
> 
>> 100:             return;
>> 101:         if (buffer.isDirect()) {
>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
> 
> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

Eventually, I hope most of them will be named `_`.

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

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

From alanb at openjdk.org  Mon Nov 21 12:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
Message-ID: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>

On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
>> 
>>> 250:         try {
>>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>>> 252:             // Hence, there is no need for acquiring any session.
>> 
>> This comment is will be confusing to anyone reading this code. Is this really needed?
>
> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:20:01 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:20:01 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <IdvkKlVEKF8ztjOHvgSwd3z2aJLRJtbUA-2P4H4A42Y=.faab2987-1d1d-4f4f-82df-f9f8db576caf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/23a6fd14..9fafafac

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

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

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

From mcimadamore at openjdk.org  Mon Nov 21 12:20:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 12:20:05 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
Message-ID: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>

On Mon, 21 Nov 2022 12:03:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
>> 
>>> 100:             return;
>>> 101:         if (buffer.isDirect()) {
>>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
>> 
>> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.
>
> Eventually, I hope most of them will be named `_`.

maybe just `bufferLock` and and just `acquireBuffer` ?

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

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

From alanb at openjdk.org  Mon Nov 21 12:21:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:21:56 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
Message-ID: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>

On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Eventually, I hope most of them will be named `_`.
>
> maybe just `bufferLock` and and just `acquireBuffer` ?

Would it be possible to re-examine acquireSession returning Runnable and 
acquireSessionAsAutoCloseable returning AutoCloseable. The naming is awkward at most of the use sites and maybe we can do better.

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

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

From michaelm at openjdk.org  Mon Nov 21 12:31:44 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 21 Nov 2022 12:31:44 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

Michael McMahon 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 http.properties
 - update after Daniel's review
 - first draft

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/284aa8e2..22fca6f8

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

  Stats: 27778 lines in 593 files changed: 10467 ins; 13998 del; 3313 mod
  Patch: https://git.openjdk.org/jdk/pull/11241.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11241/head:pull/11241

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

From pminborg at openjdk.org  Mon Nov 21 12:37:33 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <hhDVmcADk7zrfplELPNulJjOm0n56IKFmBE8Dmr2K4w=.d4f2ee38-2199-4323-85f7-b840e084904c@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fafafac..9fcf2bb3

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

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

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

From eastigeevich at openjdk.org  Mon Nov 21 12:38:23 2022
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Nov 2022 12:38:23 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
Message-ID: <kBV0psG8wV09N-FX_-mnCEZwf4SwMspJqGLaG0iAPZQ=.10ee7ba4-12a3-4c37-a78d-7d4e3499f0ad@github.com>

On Mon, 21 Nov 2022 11:17:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review suggestion - do a similar change in URLConnection

lgtm

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

Marked as reviewed by eastigeevich (Committer).

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

From duke at openjdk.org  Mon Nov 21 12:51:30 2022
From: duke at openjdk.org (Hannes Greule)
Date: Mon, 21 Nov 2022 12:51:30 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
Message-ID: <7JYUJ4OIZnl3gz9yRcziwjsc0_5AZPeHUbMukUM0fsA=.f373fe91-c9cd-4436-8538-a8c279cbe009@github.com>

On Mon, 21 Nov 2022 11:17:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review suggestion - do a similar change in URLConnection

src/java.base/share/classes/java/net/URLConnection.java line 680:

> 678:             try {
> 679:                 return Date.parse(value);
> 680:             } catch (NumberFormatException e) { }

(not a reviewer) I think NumberFormatException isn't sufficient here. `Date.parse` might throw an `IllegalArgumentException`.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:54:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:54:17 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
Message-ID: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>

On Mon, 21 Nov 2022 12:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> maybe just `bufferLock` and and just `acquireBuffer` ?
>
> Would it be possible to re-examine acquireSession returning Runnable and 
> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.

I think it would be confusing to have overloads with the same name. 

The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

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

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

From pminborg at openjdk.org  Mon Nov 21 13:02:48 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:02:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Rename methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fcf2bb3..c081b4ae

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

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

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

From eastigeevich at openjdk.org  Mon Nov 21 13:06:43 2022
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Nov 2022 13:06:43 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
Message-ID: <WbPbF1ScigWIgO0kPaUh--47OtM4eIrdLrwezAGE48Y=.4b3f26b6-16c9-49e8-afc7-ba38db44c925@github.com>

On Mon, 21 Nov 2022 11:17:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review suggestion - do a similar change in URLConnection

Changes requested by eastigeevich (Committer).

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

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

From eastigeevich at openjdk.org  Mon Nov 21 13:06:44 2022
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Nov 2022 13:06:44 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <7JYUJ4OIZnl3gz9yRcziwjsc0_5AZPeHUbMukUM0fsA=.f373fe91-c9cd-4436-8538-a8c279cbe009@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
 <7JYUJ4OIZnl3gz9yRcziwjsc0_5AZPeHUbMukUM0fsA=.f373fe91-c9cd-4436-8538-a8c279cbe009@github.com>
Message-ID: <e5PW3qo3I_NdjrOjNJsQn4WFklAt0_7f2DJXZQJSxa4=.e5c10ead-1c17-44f4-b37e-6c1d10c61dc5@github.com>

On Mon, 21 Nov 2022 12:49:20 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review suggestion - do a similar change in URLConnection
>
> src/java.base/share/classes/java/net/URLConnection.java line 680:
> 
>> 678:             try {
>> 679:                 return Date.parse(value);
>> 680:             } catch (NumberFormatException e) { }
> 
> (not a reviewer) I think NumberFormatException isn't sufficient here. `Date.parse` might throw an `IllegalArgumentException`.

@SirYwell Thanks for spotting this. You are right: [Date.parse](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Date.html#parse(java.lang.String))

Attempts to interpret the string s as a representation of a date and time.
If the attempt is successful...
If the attempt fails, an IllegalArgumentException is thrown.

@jaikiran I suggest to use the original code for catching exceptions: `} catch (Exception e) { }`

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

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

From simonis at openjdk.org  Mon Nov 21 13:10:21 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 21 Nov 2022 13:10:21 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
Message-ID: <eiAOEvBd0GAkiDG7CE_oUAQJNRZkdri6RBw1kl7A-xc=.f5caf424-dba5-4bfe-8b18-ed7c6ee3c1f4@github.com>

On Mon, 21 Nov 2022 11:17:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review suggestion - do a similar change in URLConnection

Looks good now. Thanks for finding the additional occurrence.

One final comment: could you please leave the empty catch blocks in one line, i.e.

} catch (NumberFormatException e) { }

instead of:

} catch (NumberFormatException e) {
}

This format is also recommended in the [Java Style Guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces) for empty blocks.

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

Changes requested by simonis (Reviewer).

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

From jpai at openjdk.org  Mon Nov 21 13:36:15 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 13:36:15 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v3]
In-Reply-To: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
Message-ID: <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>

> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
> 
> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

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

  review comment - fix Date.parse exception handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11258/files
  - new: https://git.openjdk.org/jdk/pull/11258/files/441d3770..69073624

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

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

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

From duke at openjdk.org  Mon Nov 21 13:39:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:39:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 94:

> 92:      * required to guarantee safety.
> 93:      * {@snippet lang = java:
> 94:      * var handler = acquireSessionOrNoOp(buffer);

Suggestion:

     * var handler = acquireSessionOrNull(buffer, async);

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:

> 39:     // An example of a guarded use of a memory address is shown here:
> 40:     //
> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {

Suggestion:

    // try (var guard = NIO_ACCESS.acquireSession(bb)) {

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

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

From jpai at openjdk.org  Mon Nov 21 13:42:55 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 13:42:55 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <eiAOEvBd0GAkiDG7CE_oUAQJNRZkdri6RBw1kl7A-xc=.f5caf424-dba5-4bfe-8b18-ed7c6ee3c1f4@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
 <eiAOEvBd0GAkiDG7CE_oUAQJNRZkdri6RBw1kl7A-xc=.f5caf424-dba5-4bfe-8b18-ed7c6ee3c1f4@github.com>
Message-ID: <EdJhxPq5T2TmvRq8gsuSu-jkGtFlv-2n11h0iqEw9kM=.3bfcac9a-27db-4bdb-b07e-316d2c4d16bb@github.com>

On Mon, 21 Nov 2022 13:07:04 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> One final comment: could you please leave the empty catch blocks in one line

Done. Updated the PR with this suggested format.

Testing in progress to make sure there are no regressions from these changes.

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

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

From jpai at openjdk.org  Mon Nov 21 13:42:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Nov 2022 13:42:58 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v2]
In-Reply-To: <7JYUJ4OIZnl3gz9yRcziwjsc0_5AZPeHUbMukUM0fsA=.f373fe91-c9cd-4436-8538-a8c279cbe009@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <ci0dGthWD3ZTshoF6e7WNc6SIMnLR98I7ABodGvqCzo=.2dcad550-66d1-49ee-832f-0b22550b2417@github.com>
 <7JYUJ4OIZnl3gz9yRcziwjsc0_5AZPeHUbMukUM0fsA=.f373fe91-c9cd-4436-8538-a8c279cbe009@github.com>
Message-ID: <i3kCR3zWgAb4N28HNtluJXud2gX6-MEq70casIy-FCI=.5e0df89d-07f9-4d28-a412-63285a9828f8@github.com>

On Mon, 21 Nov 2022 12:49:20 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review suggestion - do a similar change in URLConnection
>
> src/java.base/share/classes/java/net/URLConnection.java line 680:
> 
>> 678:             try {
>> 679:                 return Date.parse(value);
>> 680:             } catch (NumberFormatException e) { }
> 
> (not a reviewer) I think NumberFormatException isn't sufficient here. `Date.parse` might throw an `IllegalArgumentException`.

You are right @SirYwell. It was a copy/paste error on my part. Thank you for catching it. I have updated the PR to fix that part and catch `Exception` like previously.

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

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

From pminborg at openjdk.org  Mon Nov 21 13:43:21 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:43:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v5]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <iECO8UBKUoYcWn5I67E9kbCsy4tLqdswYhddUllpcLQ=.494414bf-1401-4e40-bc14-4f86f60b335e@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup static declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/c081b4ae..eca7c388

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

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

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

From dfuchs at openjdk.org  Mon Nov 21 13:45:12 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 13:45:12 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
Message-ID: <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>

On Mon, 21 Nov 2022 12:31:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon 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 http.properties
>  - update after Daniel's review
>  - first draft

src/java.net.http/share/classes/module-info.java line 113:

> 111:  * <li><p><b>{@systemProperty jdk.httpclient.maxstreams}</b> (default: 100)<br>
> 112:  * The maximum number of HTTP/2 streams per connection.
> 113:  * </li>

It might be useful to be a bit more precise here: this is the maximum number of concurrent push streams that a server is allowed to initiate on an HTTP/2 connection

src/java.net.http/share/classes/module-info.java line 133:

> 131:  * This allows the thread to terminate when no longer needed. The value provided is limited
> 132:  * to the range from 1 to 1200(???) seconds.
> 133:  * </li>

Do we need to document this property? If yes then what is the meaning of the `(???)` question marks?

src/java.net.http/share/classes/module-info.java line 136:

> 134:  * <li><p><b>{@systemProperty jdk.httpclient.sendBufferSize}</b> (default: operating system default)<br>
> 135:  * The HTTP client socket send buffer size. Values less than or equal to zero are ignored.
> 136:  * </li>

I wonder if we should make a note that attempting to specify a receive or send buffer size may be detrimental to performance as it might prevent the underlying system to optimize sending and receiving. Also a link to the corresponding StandardOptions may be in order (same for receive buffer size above).

src/java.net.http/share/classes/module-info.java line 139:

> 137:  * <li><p><b>{@systemProperty jdk.internal.httpclient.disableHostnameVerification}</b> (default: false)<br>
> 138:  * If true, hostname verification in SSL certificates is disabled. This is a system property only.
> 139:  * </li>

Should we emphasize that it is intended for testing purposes?

src/java.net.http/share/classes/module-info.java line 147:

> 145:  * A comma separated list of HTTP authentication scheme names, that are disallowed for use by
> 146:  * the HTTP client implementation, for HTTP CONNECT tunneling.
> 147:  * </li>

Should we provide a link to net-properties.html here?

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

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

From pminborg at openjdk.org  Mon Nov 21 13:49:09 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
Message-ID: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>

On Mon, 21 Nov 2022 13:32:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
> 
>> 39:     // An example of a guarded use of a memory address is shown here:
>> 40:     //
>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 
> Suggestion:
> 
>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {

Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

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

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

From duke at openjdk.org  Mon Nov 21 13:49:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
 <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
Message-ID: <UQL92ereV30YE4RxJFFHfF8YQFznI0les962qyQjsT4=.6123ea57-7532-41c3-a8d6-b00282d4fa3b@github.com>

On Mon, 21 Nov 2022 13:43:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
>> 
>>> 39:     // An example of a guarded use of a memory address is shown here:
>>> 40:     //
>>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
>> 
>> Suggestion:
>> 
>>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
>
> Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

This?change was?missed in?commit?<https://github.com/openjdk/jdk/pull/11260/commits/c081b4aebb7b52c7161656b4cba9b0a60d36202a>.

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

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

From pminborg at openjdk.org  Mon Nov 21 14:02:38 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:02:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eca7c388..a0de3bcf

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

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

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

From pminborg at openjdk.org  Mon Nov 21 14:06:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:06:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v7]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <85JCc27fZGJjTrQbm1vJfA6BY1KgAZ9PLlRJQgbcj3M=.1707b29d-4c0c-4f0f-9be9-acbfc341d571@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains six commits:

 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Cleanup static declarations
 - Rename methods
 - Remove comments
 - Cleanup after comments
 - Guard usages of DirectBuffer::address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/a0de3bcf..17a72e9f

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

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

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

From alanb at openjdk.org  Mon Nov 21 14:11:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:11:31 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/java/util/zip/Adler32.java line 105:

> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
> 104:             } finally {
> 105:                 Reference.reachabilityFence(buffer);

The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

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

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

From dfuchs at openjdk.org  Mon Nov 21 14:11:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 14:11:31 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v3]
In-Reply-To: <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
Message-ID: <vmRwR21V3yv4Vh54o4i8wZIjiN4x8Q434TLpl9URAWk=.85eadb2a-99f5-4364-86ba-7259a8ca2e64@github.com>

On Mon, 21 Nov 2022 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment - fix Date.parse exception handling

Changes look good to me. Approving provided that tier2 passes.

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.org  Mon Nov 21 14:16:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:16:41 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
Message-ID: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>

On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:

> 90:      * allocated from the heap.
> 91:      * <p>
> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.

This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

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

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

From dfuchs at openjdk.org  Mon Nov 21 15:24:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 15:24:21 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections
Message-ID: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>

Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.

This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.

The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.

This fix works this way: 

- first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
- then it takes this information into account when matching the number of actual connections with the number of expected connection,
- additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 

Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.

With this fix I no longer observe the test failing.

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

Commit messages:
 - 8223783

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

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

From simonis at openjdk.org  Mon Nov 21 15:27:58 2022
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 21 Nov 2022 15:27:58 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v3]
In-Reply-To: <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
Message-ID: <AhB9NZNQbK7DCpeeiLYSFJfOE4fLiCH4GQZz5khIlhk=.a8bd6dfc-dfcb-40d0-9f8f-244114310911@github.com>

On Mon, 21 Nov 2022 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment - fix Date.parse exception handling

LGTM.

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

Marked as reviewed by simonis (Reviewer).

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

From pminborg at openjdk.org  Mon Nov 21 15:31:32 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:31:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
Message-ID: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>

On Mon, 21 Nov 2022 14:14:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:
> 
>> 90:      * allocated from the heap.
>> 91:      * <p>
>> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.
> 
> This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

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

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

From pminborg at openjdk.org  Mon Nov 21 15:34:54 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:34:54 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <wajuJrHs8kgD4SezHUCBWvAceHqa5YSY2olr7QPLSms=.42f6db8c-23bf-486d-97d4-0ebaac18f7e1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'guard-directbuffer-address' of https://github.com/minborg/jdk into guard-directbuffer-address
 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/17a72e9f..88ed3aa2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=06-07

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

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

From pminborg at openjdk.org  Mon Nov 21 16:10:27 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 16:10:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
Message-ID: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>

On Mon, 21 Nov 2022 14:07:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 105:
> 
>> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
>> 104:             } finally {
>> 105:                 Reference.reachabilityFence(buffer);
> 
> The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

This can certainly be done. We could, for example, add a new method to the `JavaNioAccess` interface:

```AddressAcquisition acquireSession2(Buffer buffer); // to be renamed```

This would allow us to go from:


            try (var guard = NIO_ACCESS.acquireSession(buffer)) {
                adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
            } finally {
                Reference.reachabilityFence(buffer);
            }


to


            try (var guard = NIO_ACCESS.acquireSession2(buffer)) {
                adler = updateByteBuffer(adler, guard.address(), pos, rem);
            }


Although this looks much simpler and concise, it means "a new object is created for each invocation" (*). This also allows us to remove the `@SupressWarnings("try")` annotations.

Here is how the undercarriage might look like:


                @Override
                public AddressAcquisition acquireSession2(Buffer buffer) {
                    var session = buffer.session();
                    if (session == null) {
                        return AddressAcquisition.create(buffer, () -> {});
                    }
                    session.acquire0();
                    return AddressAcquisition.create(buffer, session::release0);
                }



and


sealed interface AddressAcquisition extends AutoCloseable {

        long address();

        @Override
        void close();

        static AddressAcquisition create(Buffer buffer, Runnable closeActions) {
            return new AddressAcquisitionImpl(buffer, closeActions);
        }

        final class AddressAcquisitionImpl implements AddressAcquisition {

            private final DirectBuffer directBuffer;
            private final Runnable closeAction;

            public AddressAcquisitionImpl(Buffer buffer,
                                          Runnable closeAction) {
                this.directBuffer = (DirectBuffer) buffer;
                this.closeAction = closeAction;
            }

            @Override
            public long address() {
                return directBuffer.address();
            }

            @Override
            public void close() {
                try {
                    closeAction.run();
                } finally {
                    Reference.reachabilityFence(directBuffer);
                }
            }
        }

    }



(*) In reality,  a representation of the object might be allocated on the stack instead.

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

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

From michaelm at openjdk.org  Mon Nov 21 16:14:23 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 21 Nov 2022 16:14:23 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
Message-ID: <Flg5gGEDVlcbH_BuL-mk2nnK0t79aiB3fPMZo8Hz2_M=.ac7f8da5-4320-41dc-bf1a-c7b79313a516@github.com>

On Mon, 21 Nov 2022 13:36:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon 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 http.properties
>>  - update after Daniel's review
>>  - first draft
>
> src/java.net.http/share/classes/module-info.java line 113:
> 
>> 111:  * <li><p><b>{@systemProperty jdk.httpclient.maxstreams}</b> (default: 100)<br>
>> 112:  * The maximum number of HTTP/2 streams per connection.
>> 113:  * </li>
> 
> It might be useful to be a bit more precise here: this is the maximum number of concurrent push streams that a server is allowed to initiate on an HTTP/2 connection

Right, good point. It's the client telling the server how many streams it is allowed to open. So, that implies push streams only

> src/java.net.http/share/classes/module-info.java line 133:
> 
>> 131:  * This allows the thread to terminate when no longer needed. The value provided is limited
>> 132:  * to the range from 1 to 1200(???) seconds.
>> 133:  * </li>
> 
> Do we need to document this property? If yes then what is the meaning of the `(???)` question marks?

The question mark was a place holder to query the value range. 1200 seemed extremely high. But, I think we don't need to document it at all.

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

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

From mullan at openjdk.org  Mon Nov 21 16:36:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Nov 2022 16:36:28 GMT
Subject: RFR: 8281236: (D)TLS key exchange named groups [v3]
In-Reply-To: <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
References: <cpXVPvxe0JDaMxU9m-p0501h2s9pVRpz666YeSjMQkE=.4b14e1c6-c4b9-45b6-b094-1f80c76210a8@github.com>
 <Bwa6P_KrLQQ-FbpoIBLEoB77A8RWwToKv7LUZkOTPJQ=.63c0ea4e-a51f-4117-84be-40bfb198fa20@github.com>
 <crsVdEXraQTzoqyZjvy_esRIFbUjk2_XT9mkz90Fch8=.1fd12ff1-cb73-4cc3-83d9-24d4d60940f2@github.com>
 <XfqYgnSWF-7JLGTbgX_IXqjkyNT_av33GFopiRkDuSA=.789e57ab-8f69-4158-bd2b-d330c80cbfdd@github.com>
 <S5gZVNcEBNsXlQ0jICAc-SOqsSDfGENZPLRgjilMUmE=.6d4f3883-78b5-42c9-ba93-e34066206903@github.com>
Message-ID: <5JDd7s4X4Iy0YzM2tLQimSyyFigR7W9cWixtgmcK3WY=.5e27e22c-03c3-4aa9-bb6a-0a9d6b36b109@github.com>

On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Unfortunately, I only have author status and can only comment.
>> 
>> I think OpenJDK Author can approve as well.  I just need to get another Reviewer approval before integration.
>
>> > Unfortunately, I only have author status and can only comment.
>> 
>> I think OpenJDK Author can approve as well. I just need to get another Reviewer approval before integration.
> 
> For a CSR, I believe that is true. But you will need a Reviewer for the PR, and they may have comments on parts that are covered by the CSR.
> 
> I would suggest moving the CSR to Proposed (which doesn't require a Reviewer AFAIK). That will move it forward a bit.

> @seanjmullan Did you have cycle to review this PR and CSR? This CSR is similar to the one we did for signature algorithms. I was wondering if it is possible to have it in JDK 20 so that more specific TLS benchmarks could be introduced sooner. Thanks!

I added my name as Reviewer to the CSR, so you can finalize that, as that will give you a better chance of it being approved and getting this into JDK 20. It will take me a little while longer to review the code changes, though I don't expect it will impact the API.

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

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

From alanb at openjdk.org  Mon Nov 21 16:37:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 16:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
Message-ID: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>

On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Although this looks much simpler and concise, it means "a new object is created for each invocation" 

My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
 <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
Message-ID: <GtZ7D3vC5YXHj_8J1pOlB7FceWDEWD4FiSvBB-cLqAI=.00dc532b-de35-4766-8d9b-abd9102246e6@github.com>

On Mon, 21 Nov 2022 12:50:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Would it be possible to re-examine acquireSession returning Runnable and 
>> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.
>
> I think it would be confusing to have overloads with the same name. 
> 
> The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

IIRC, Runnable was chosen back then because of the issues with using TWR which was generating warnings (because resource not accessed in body of TWR). I don't have strong opinions on this, other than we should only have one way to do things, rather than 2-3. Since the JDK has capabilities to acquire and release a session w/o a TWR and/or Runnable, one might also consider whether exposing acquire/release separately, and just use those.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
Message-ID: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>

On Mon, 21 Nov 2022 16:34:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
> 
> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

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

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

From jjg at openjdk.org  Mon Nov 21 17:54:15 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 17:54:15 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Fix merge issue
 - Merge with upstream/master
 - JDK-8297164: Update troff man pages and CheckManPageOptions.java

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

Changes: https://git.openjdk.org/jdk/pull/11223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=01
  Stats: 8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod
  Patch: https://git.openjdk.org/jdk/pull/11223.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223

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

From dfuchs at openjdk.org  Mon Nov 21 18:19:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Nov 2022 18:19:23 GMT
Subject: RFR: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java [v2]
In-Reply-To: <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
 <sFWIetw6eDaMCBrPKvef-nw2oN29pOGBp5uLM7tn7YI=.807e8ba0-f0b4-4f02-96d9-20e36200b307@github.com>
Message-ID: <BfqsAA59PbkyFi7ceXdE3JClChGmOoN7zxbWxPP_pxw=.7948deb7-49d0-4553-8923-69f4daefb1ea@github.com>

On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
>> (See https://bugs.openjdk.org/browse/JDK-8297165)
>> 
>> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Fix merge issue
>  - Merge with upstream/master
>  - JDK-8297164: Update troff man pages and CheckManPageOptions.java

The diffs are a bit difficult to read but I didn't spot anything obviously wrong with jwebserver. I could see that the new compress option was there in jmod man page too. +1.

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

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

From alanb at openjdk.org  Mon Nov 21 20:08:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 20:08:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
Message-ID: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>

On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Although this looks much simpler and concise, it means "a new object is created for each invocation" 
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>
>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
> 
> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

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

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

From aturbanov at openjdk.org  Mon Nov 21 21:03:26 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Nov 2022 21:03:26 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <mWrG_l3s4CLXbz8LBmrqgHbH7XcP8Yi8ZF_MmzaM5tU=.e18b51b5-3a45-470d-bf12-78b30ff9ec10@github.com>

On Mon, 21 Nov 2022 15:12:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 448:

> 446:             while (!done) {
> 447:                 int c = in.read();
> 448:                 last =  System.nanoTime();

Suggestion:

                last = System.nanoTime();

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 544:

> 542:                     s.close();
> 543:                 } catch (Exception e) { }
> 544:                 MultiThreadTest.debug("worker: " + id  + " end at " +

Nit:
Suggestion:

                MultiThreadTest.debug("worker: " + id + " end at " +

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

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

From jjg at openjdk.org  Mon Nov 21 22:06:36 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 21 Nov 2022 22:06:36 GMT
Subject: Integrated: JDK-8297164: Update troff man pages and
 CheckManPageOptions.java
In-Reply-To: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
References: <AiX_1o8ZS-ArE4xmr4wMN7Is3Ur6A6SQZ6EmnreH5jQ=.57c27d4c-d960-4cec-91d0-0a939b42bc17@github.com>
Message-ID: <heN0GBRdomaSVnNUZIi7L1vA_uegGEvn0ZQ1mOD6Mwc=.fb15980e-f807-42bb-976a-f112e0f642e3@github.com>

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
> 
> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc.

This pull request has now been integrated.

Changeset: 5a45c251
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a45c25151b1da8e329ea2be21a0e4d2652f8b4a
Stats:     8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod

8297164: Update troff man pages and CheckManPageOptions.java

Reviewed-by: dholmes

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

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

From jpai at openjdk.org  Tue Nov 22 01:48:23 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Nov 2022 01:48:23 GMT
Subject: RFR: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response [v3]
In-Reply-To: <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
 <C3x6s40xDe8oMocdQTqih7xa_v2RWQJSVjN30YQvaoY=.894cad90-687c-4e69-a494-1ea7d8c1e1da@github.com>
Message-ID: <B7OZVn_7dlmmdrGLY3EMfvw3XojNO3xBJ_J6l2G0jSg=.5bd43e54-4f4e-4592-b8bb-d844d365b4a6@github.com>

On Mon, 21 Nov 2022 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
>> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
>> 
>> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment - fix Date.parse exception handling

The tests came back fine without any related failures.

Thank you everyone for the reviews and suggestions.

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

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

From jpai at openjdk.org  Tue Nov 22 01:52:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Nov 2022 01:52:05 GMT
Subject: Integrated: 8297211: Expensive fillInStackTrace operation in
 HttpURLConnection.getOutputStream0 when no content-length in response
In-Reply-To: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
References: <zxXGd3WnFnjxno_4eQUARZRaBB1t0CQXLLY-7LqQjXs=.c46badb1-7c1a-4dae-a0f5-5d98a66d7742@github.com>
Message-ID: <VrRqr8tKRdJoRnmwfQXtPl8bUPmoPz-uv-cvPeFDvHg=.cce3a94e-e1d3-4de2-aeb6-6759e32f1e8c@github.com>

On Mon, 21 Nov 2022 06:47:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this small change which addresses https://bugs.openjdk.org/browse/JDK-8297211? 
> The change checks if the `content-length` header value is present before parsing it into a `Long` value. The commit also now catches the more specific `NumberFormatException` instead of a general `Exception`. Given the context of the code, I believe this change in the exception type in the catch block should be fine.
> 
> No new test has been introduced given the nature of this change. I have triggered existing tests to verify no unexpected regressions show up.

This pull request has now been integrated.

Changeset: 392ac705
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/392ac7055d4697c56fa85ac5572f5bc4dc431f1d
Stats:     25 lines in 2 files changed: 9 ins; 0 del; 16 mod

8297211: Expensive fillInStackTrace operation in HttpURLConnection.getOutputStream0 when no content-length in response

Reviewed-by: simonis, dfuchs

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

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Rework Acquisition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ed3aa2..0526e3dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=07-08

  Stats: 249 lines in 19 files changed: 66 ins; 91 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
 <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
Message-ID: <LI4GrAv6ZiaCaopZaAhzdzyCpchKYlV43-0W0aObAeU=.020fac2b-6e3d-4911-9f5a-13673f9ce7b0@github.com>

On Mon, 21 Nov 2022 20:06:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>>> 
>>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>> 
>> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.
>
> Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

I have reworked Acquisition. I think we could merge the old and new way in a separate PR.

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

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

From alanb at openjdk.org  Tue Nov 22 09:34:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 09:34:36 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
 <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
Message-ID: <CHWjD0UP6P-l-JvOzxkaosyV6qcfXEtjPwpgSVDz2PU=.7c420616-8bc4-43de-8e32-91d2f1d4d0ff@github.com>

On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

The faraway use sites look much better now. The performance sensitive usages need close attention. Can you summarise the changes to DatagramChannel, are you creating a NoOpScopeAcquisition for every  send/receive? This is low level code where we do do something different to avoid the try-with-resources.

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

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

From duke at openjdk.org  Tue Nov 22 09:38:12 2022
From: duke at openjdk.org (Ismael Juma)
Date: Tue, 22 Nov 2022 09:38:12 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <vrCPeO8q_rSPwnS51968i5vGlFh4Z-xxQxkT9LWkYuQ=.55b3889b-80c5-4823-a2f8-1a7e9368ae2d@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

> because this PR is touching several low level and performance critical code paths

Indeed. Have we verified that performance doesn't regress with these changes?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:38:15 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:38:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:

> 912:          * If so, make a copy to put the dst data in.
> 913:          */
> 914:         @SuppressWarnings("try")

After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

src/java.base/share/classes/java/nio/Buffer.java line 827:

> 825: 
> 826:                 @Override
> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {

If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:


Buffer b = ...
try {
    // use buffer.address();
} finally {
    Reference.reachabilityFence(b);
}


We could transform to this:


Buffer b = ...
acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
try {
    // use buffer.address();
} finally {
    release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
}

This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:

> 588:                                         int pos)
> 589:             throws IOException {
> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {

Why was the old code not using reachability fences? Bug or feature?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:42:23 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:42:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>

On Tue, 22 Nov 2022 09:32:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
> 
>> 588:                                         int pos)
>> 589:             throws IOException {
>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
> 
> Why was the old code not using reachability fences? Bug or feature?

I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).

Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

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

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

From duke at openjdk.org  Tue Nov 22 10:23:04 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 10:23:04 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <UwTUKJq45-sC2tDcnUGqv1Uwv9cVn7etUEBK88WJhvw=.f30994f7-a292-43f7-a9c7-5d68abfead96@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 43:

> 41:     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
> 42:     //     performOperation(bb.address());
> 43:     // }

Again, updating?this?comment was?missed:
Suggestion:

    // try (var guard = NIO_ACCESS.acquireScope(bb)) {
    //     performOperation(guard.address());
    // }

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

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

From ccleary at openjdk.org  Tue Nov 22 11:17:57 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 22 Nov 2022 11:17:57 GMT
Subject: RFR: 8297030: Reduce Default Keep-Alive Timeout Value for httpclient
Message-ID: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>

Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.

This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.

Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

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

Commit messages:
 - 8297030: Reduce Default Keep-Alive Timeout Value for httpclient

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

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

From ccleary at openjdk.org  Tue Nov 22 11:28:01 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 22 Nov 2022 11:28:01 GMT
Subject: RFR: 8297030: Reduce Default Keep-Alive Timeout Value for
 httpclient
In-Reply-To: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
References: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
Message-ID: <78oJAWfW82d_CsR6lnLEMKA2EZ_PPcKbs1kHjpc57nc=.e30da09b-7d69-4a38-a784-a0be2789b70e@github.com>

On Tue, 22 Nov 2022 11:10:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.
> 
> This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.
> 
> Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

Some data on default Keep-Alive values for servers...

- Apache default Keepalive timeout is 15s
- AWS CloudFront default idle connection timeout value is 5-60s
- Load Balancers, tend to have longer defaults. Probably due to queing/access-control systems preparing for high demmand.
  - Azure minimum is 240s
  - AWS ELB, default of 350s

This data is hard to come by without digging into sources for the above but it is clear that our default should at the very least  be lower than present.

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4GRnrg0zNGXoQdiG3uL9JeQyj4bdDVubzv0oMoIuSnM=.1dabdf13-e8b7-477d-86d0-20e5ba2f47bf@github.com>

On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/java/nio/Buffer.java line 827:
> 
>> 825: 
>> 826:                 @Override
>> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {
> 
> If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:
> 
> 
> Buffer b = ...
> try {
>     // use buffer.address();
> } finally {
>     Reference.reachabilityFence(b);
> }
> 
> 
> We could transform to this:
> 
> 
> Buffer b = ...
> acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
> try {
>     // use buffer.address();
> } finally {
>     release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
> }
> 
> This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

The AutoCloseable experiment was interesting to try but I think you are right, acquire try { .. } finally release would be simpler and also remove the concerns about the performance critical code paths.

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
Message-ID: <WHS_9EM_JrRB2ZtSQmTO4qJLhOjPv5XCP0iGLbiqQ0k=.75963d9c-1c9b-4506-b234-74e8658e0d9a@github.com>

On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>> 
>>> 588:                                         int pos)
>>> 589:             throws IOException {
>>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
>> 
>> Why was the old code not using reachability fences? Bug or feature?
>
> I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).
> 
> Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

Yes, once the memory/linker APIs are permanent then the SCTP implementation would be a good candidate to redo.

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

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

From dfuchs at openjdk.org  Tue Nov 22 12:22:57 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 12:22:57 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v2]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <8eQg3Ebg3TbfEhA8ladhGC0lc9SZZTD0CvNWyNGSZS0=.bba8e89a-a90e-41bf-b947-9376263de764@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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

 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/1e9ada3e..c809cbf4

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

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

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

From dfuchs at openjdk.org  Tue Nov 22 12:29:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 12:29:21 GMT
Subject: RFR: 8297030: Reduce Default Keep-Alive Timeout Value for
 httpclient
In-Reply-To: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
References: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
Message-ID: <W1WpDuajvJPFk-vS8wHhWgZU7HBJVNiyRc5wYvcV7u4=.915b886d-8331-4825-9a05-536605e18b79@github.com>

On Tue, 22 Nov 2022 11:10:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.
> 
> This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.
> 
> Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

I agree that 30s seems a much better default value than 1200s. Would be good to get @Michael-Mc-Mahon opinion too. This change will have to be coordinated with https://git.openjdk.org/jdk/pull/11241: Depending on which PR gets integrated first, you may have to update module-info (or leave it to Michael)

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

Marked as reviewed by dfuchs (Reviewer).

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

From pminborg at openjdk.org  Tue Nov 22 13:52:22 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 13:52:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>

On Tue, 22 Nov 2022 09:23:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
> 
>> 912:          * If so, make a copy to put the dst data in.
>> 913:          */
>> 914:         @SuppressWarnings("try")
> 
> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

Well spotted. I will remove the guarding here.

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

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

From pminborg at openjdk.org  Tue Nov 22 14:01:39 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 14:01:39 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v10]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <VU9F8S77u_MTYUEeJNuEIVQzsDSvFjj5IrAp81VPJOw=.8408fba0-e45a-4551-9a41-9255e39640b1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove redundant guard and fix comment permanently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0526e3dc..06c764ca

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

  Stats: 59 lines in 2 files changed: 19 ins; 26 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From michaelm at openjdk.org  Tue Nov 22 16:27:30 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Nov 2022 16:27:30 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v2]
In-Reply-To: <8eQg3Ebg3TbfEhA8ladhGC0lc9SZZTD0CvNWyNGSZS0=.bba8e89a-a90e-41bf-b947-9376263de764@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <8eQg3Ebg3TbfEhA8ladhGC0lc9SZZTD0CvNWyNGSZS0=.bba8e89a-a90e-41bf-b947-9376263de764@github.com>
Message-ID: <jnp-SiHC857hwFe4bQC-PNt0sixj4grTIQmyYAnmMnw=.725866ba-3feb-4cd5-8db0-26c6463bfe58@github.com>

On Tue, 22 Nov 2022 12:22:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
>> 
>> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
>> 
>> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
>> 
>> This fix works this way: 
>> 
>> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
>> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
>> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
>> 
>> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
>> 
>> With this fix I no longer observe the test failing.
>
> Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 83:

> 81:     // The number of time an idle timeout was detected by any worker
> 82:     // on the server side.
> 83:     static final AtomicInteger IDLE_TIME_EXCEEDED = new AtomicInteger();

IDLE_TIME_EXCEEDED is allocated and incremented, but not referenced anywhere else. Did you mean to include it in a debug log or something?

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

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

From dfuchs at openjdk.org  Tue Nov 22 16:39:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 16:39:01 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v3]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <F4DnTU7Xf0jjqr-Xsnyam7tZZm21lDMSQCS7ubU4WJI=.e049acaf-0b38-43ef-ba3d-05327d619256@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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 four additional commits since the last revision:

 - Merge branch 'master' into MultiThreadTest-8223783
 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - 8223783

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/c809cbf4..0185710f

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

  Stats: 22395 lines in 222 files changed: 9263 ins; 3213 del; 9919 mod
  Patch: https://git.openjdk.org/jdk/pull/11268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11268/head:pull/11268

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

From dfuchs at openjdk.org  Tue Nov 22 16:51:30 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 16:51:30 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v2]
In-Reply-To: <jnp-SiHC857hwFe4bQC-PNt0sixj4grTIQmyYAnmMnw=.725866ba-3feb-4cd5-8db0-26c6463bfe58@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <8eQg3Ebg3TbfEhA8ladhGC0lc9SZZTD0CvNWyNGSZS0=.bba8e89a-a90e-41bf-b947-9376263de764@github.com>
 <jnp-SiHC857hwFe4bQC-PNt0sixj4grTIQmyYAnmMnw=.725866ba-3feb-4cd5-8db0-26c6463bfe58@github.com>
Message-ID: <cflx2j31w2ltixE7Rv9prVAfsIC3VtIUPBIHwmKsiyA=.08dfac20-76f2-4250-9aaf-63d824c35479@github.com>

On Tue, 22 Nov 2022 16:24:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 83:
> 
>> 81:     // The number of time an idle timeout was detected by any worker
>> 82:     // on the server side.
>> 83:     static final AtomicInteger IDLE_TIME_EXCEEDED = new AtomicInteger();
> 
> IDLE_TIME_EXCEEDED is allocated and incremented, but not referenced anywhere else. Did you mean to include it in a debug log or something?

Yes - I meant to use it but in the end it was also necessary to include the time the worker has been idle since it last read/wrote a byte and the end of the test (the time at which all requests had been sent) - so I ended up not using it.  I could remove it.

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

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

From dfuchs at openjdk.org  Tue Nov 22 17:30:56 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 17:30:56 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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

  Incorporated review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/0185710f..694b9dd6

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

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

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

From dfuchs at openjdk.org  Tue Nov 22 17:34:00 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 17:34:00 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed once
 in AssertionError due to selector thread remaining alive
Message-ID: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>

The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.

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

Commit messages:
 - 8297200
 - 8297200

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

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

From duke at openjdk.org  Tue Nov 22 19:28:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 19:28:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
Message-ID: <-3UxCy1TSFrc9DMZZMdsiUpX7i3wOmiTRTHpyRKEjYs=.54eef999-bad4-49ce-9c66-d45fd16fe9b5@github.com>

On Tue, 22 Nov 2022 13:49:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
>> 
>>> 912:          * If so, make a copy to put the dst data in.
>>> 913:          */
>>> 914:         @SuppressWarnings("try")
>> 
>> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).
>
> Well spotted. I will remove the guarding here.

This?`@SuppressWarnings` annotation is?no?longer?needed:
Suggestion:

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

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

From dfuchs at openjdk.org  Tue Nov 22 21:34:38 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Nov 2022 21:34:38 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v2]
In-Reply-To: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
Message-ID: <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>

> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.

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

  Fixed race condition in detecting if selector is still alive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11294/files
  - new: https://git.openjdk.org/jdk/pull/11294/files/204f279c..25efbd8b

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

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

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

From mullan at openjdk.org  Tue Nov 22 21:55:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 21:55:29 GMT
Subject: RFR: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
 <eaQo5K31X-GED34pdV5FX10_EaS0-ixDFVmh9msdqMw=.4d983b31-6f3f-4f88-9b07-035a13b5685e@github.com>
 <tE-XCaAOq7dpJa0np6pcDQJyTD9hSPPWQ7JEYDY9gPw=.14f640d7-aa20-4ee4-bb5e-e17c3aa582a0@github.com>
Message-ID: <epAQxLZ0QUsOPhbOWTAL5lvt0pkG3F7E36xBnzxvXFs=.c4085c5e-0a5e-48a5-add2-2b2f61fa8893@github.com>

On Wed, 16 Nov 2022 17:39:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>>> 
>>> > The wording in this PR specifically refers to the protocol version that
>>> 
>>> was specified. It isn't covering other optional protocols that may be supported.
>>> 
>>> Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version. 
>> 
>> Where in the javadoc APIs does it say that? I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
>
>> > _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
>> > > The wording in this PR specifically refers to the protocol version that
>> > 
>> > 
>> > was specified. It isn't covering other optional protocols that may be supported.
>> > Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled in security properties refers to protocol version.
>> 
>> Where in the javadoc APIs does it say that?
> 
> The Javadoc APIs specification does not say it is referring to TLS protocol version.  In the standard algorithm documentation, the word "SSLContext Algorithms" is used and here is an example:
> 
> 
> Algorithm Name | Description
> -- | --
> TLSv1.2 | Supports?RFC 5246: TLS version 1.2; may support other SSL/TLS versions
> 
> 
>> I think the only assumption you can make is that the SSLContext that is returned supports the protocol version that was specified. Whether or not it supports other versions is completely implementation-specific AFAICT.
> 
> Yes.  So we cannot assume that the literal SSLContext algorithm is the only supported TLS version for an JSSE provider, including the SunJSSE provider.

I plan to withdraw this PR for now. @XueleiFan you make some good points that the implementation note is too specific (there are other failure scenarios) and also that a connection may still be successfully established using other protocols if the implementation supports other protocols than what was requested.

I really think that what is needed is a better class description in the javadoc of the `SSLContext` class about what the protocol passed to `getInstance` means. Something similar to what is documented in the JSSE Developer's Guide: https://docs.oracle.com/en/java/javase/19/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-9BAC1902-A203-4422-8163-61D64ADD2FF7
I will open an RFE for that.

After that we can add more information on specific implementation specific scenarios, such as what is being proposed here.

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

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

From mullan at openjdk.org  Tue Nov 22 21:55:29 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Nov 2022 21:55:29 GMT
Subject: Withdrawn: 8296820: Add implementation note to SSLContext.getInstance
 noting subsequent behavior if protocol is disabled
In-Reply-To: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
References: <86L4rN0m9tJSW7_58YgUuTK1UK2J0dqTnuBEGDg4VKg=.6f494d7a-b7db-48e2-a21d-7f1b961d5e75@github.com>
Message-ID: <Y2CwFxsCj0raGJqogEPpqUVzXKApSaetELstP9oc8aU=.a0e48979-ca20-4b3b-9ce7-f704a89940bd@github.com>

On Tue, 15 Nov 2022 17:41:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this PR to add an implementation note to the`SSLContext.getInstance` methods to document the behavior when a protocol is disabled.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Tue Nov 22 22:04:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 22:04:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

  Prefix RFC titles with `RFC NNNN:`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8

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

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

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

From djelinski at openjdk.org  Wed Nov 23 07:48:22 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Nov 2022 07:48:22 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v2]
In-Reply-To: <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>
Message-ID: <SeKx3e-XxdOcH-bSisHa1AFH8fmkK6A_zSs6AhNew6M=.2d41c3bd-a137-4c67-a9d9-54955059bc23@github.com>

On Tue, 22 Nov 2022 21:34:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed race condition in detecting if selector is still alive

src/java.net.http/share/classes/jdk/internal/net/http/common/OperationTrackers.java line 69:

> 67:         // Whether the implementation of the facade
> 68:         // is still referenced
> 69:         boolean isImplementationReferenced();

This method appears to be unused

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

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

From djelinski at openjdk.org  Wed Nov 23 08:54:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Nov 2022 08:54:25 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
Message-ID: <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>

On Tue, 22 Nov 2022 17:30:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
>> 
>> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
>> 
>> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
>> 
>> This fix works this way: 
>> 
>> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
>> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
>> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
>> 
>> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
>> 
>> With this fix I no longer observe the test failing.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated review feedback

Changes requested by djelinski (Committer).

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 28:

> 26:  * @bug 4636628
> 27:  * @summary HttpURLConnection duplicates HTTP GET requests when used with multiple threads
> 28:  * @run main MultiThreadTest

do we really need to run this test 5 times?

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 183:

> 181:         try {
> 182:             Object lock = MultiThreadTest.getLock();
> 183:             List<MultiThreadTest> tests = new ArrayList<>();

this list is not used

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 253:

> 251: 
> 252:             if (validConnections != cnt) {
> 253:                 // these connections are not necessarily unexpected if SLEEP exceeds keep-alive.

Well actually these are unexpected connections; every connection from the tested client will equally count towards `cnt` and `validConnections`.

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 263:

> 261:             debug("waiting for worker to shutdown at " + at() +"ms");
> 262:             for (Worker worker : svr.workers()) {
> 263:                 // we could call worker.done(); to force the worker

The `done()` method is unused, and as you pointed out here, we don't want to use it; can you remove it?

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 390:

> 388:         volatile int timeoutExceeded;
> 389:         // Number of requests handled by this worker
> 390:         volatile int requestHandled;

not used

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 423:

> 421:          * than the KEEP_ALIVE timeout. This will be true if the worker detected
> 422:          * that the idle timeout was exceeded between two consecutive request, or
> 423:          * if the time between the last reply

this needs cleanup

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

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

From michaelm at openjdk.org  Wed Nov 23 11:08:58 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 11:08:58 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
Message-ID: <4C450ZI9QpCeRHMuUgbORDfd64tQSDDz-RuHN3nqxbE=.efcab39b-7c90-4d26-a220-5de31ff02d21@github.com>

On Mon, 21 Nov 2022 13:41:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon 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 http.properties
>>  - update after Daniel's review
>>  - first draft
>
> src/java.net.http/share/classes/module-info.java line 136:
> 
>> 134:  * <li><p><b>{@systemProperty jdk.httpclient.sendBufferSize}</b> (default: operating system default)<br>
>> 135:  * The HTTP client socket send buffer size. Values less than or equal to zero are ignored.
>> 136:  * </li>
> 
> I wonder if we should make a note that attempting to specify a receive or send buffer size may be detrimental to performance as it might prevent the underlying system to optimize sending and receiving. Also a link to the corresponding StandardOptions may be in order (same for receive buffer size above).

I would agree with linking to the StandardSocketOption descriptions, as that would also help to distinguish the send buffer option from the write buffer option, which sounds similar. In my view, any discussion of performance trade-offs should be in the StandardSocketOption apidoc rather than here.

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

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

From michaelm at openjdk.org  Wed Nov 23 11:11:38 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 11:11:38 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v4]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <C7d_u2-zE9YDQxsZSKN7hc8DkUDSUoFHobky64Twc8k=.c61485fb-dff2-446f-93d5-53dfcd1f08a5@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  update after review round 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/22fca6f8..e5530406

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

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

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

From dfuchs at openjdk.org  Wed Nov 23 11:40:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 11:40:20 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v2]
In-Reply-To: <SeKx3e-XxdOcH-bSisHa1AFH8fmkK6A_zSs6AhNew6M=.2d41c3bd-a137-4c67-a9d9-54955059bc23@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>
 <SeKx3e-XxdOcH-bSisHa1AFH8fmkK6A_zSs6AhNew6M=.2d41c3bd-a137-4c67-a9d9-54955059bc23@github.com>
Message-ID: <nGZHPW00hMHmdfV5kDGqRt8ki1Thh6JwtFmGkHdESOE=.1b1c3a67-3d3c-48f5-9500-a2b3b1cd04a4@github.com>

On Wed, 23 Nov 2022 07:46:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed race condition in detecting if selector is still alive
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/OperationTrackers.java line 69:
> 
>> 67:         // Whether the implementation of the facade
>> 68:         // is still referenced
>> 69:         boolean isImplementationReferenced();
> 
> This method appears to be unused

Yes - I'm planning to update some tests to use it in some future PRs.

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

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

From dfuchs at openjdk.org  Wed Nov 23 11:45:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 11:45:23 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
 <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
Message-ID: <z1FhW6IvIY0uzjZk8e--AgG47et-U0BjVmBQagSKFbM=.8d07ce67-9278-4b41-8533-c85979aa05a7@github.com>

On Wed, 23 Nov 2022 08:16:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated review feedback
>
> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 28:
> 
>> 26:  * @bug 4636628
>> 27:  * @summary HttpURLConnection duplicates HTTP GET requests when used with multiple threads
>> 28:  * @run main MultiThreadTest
> 
> do we really need to run this test 5 times?

Good point. I will remove them. That was just my trick for increasing the chances of failures while testing the change.

> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 183:
> 
>> 181:         try {
>> 182:             Object lock = MultiThreadTest.getLock();
>> 183:             List<MultiThreadTest> tests = new ArrayList<>();
> 
> this list is not used

Good catch. That's a left over from some additional experiment.

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

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

From dfuchs at openjdk.org  Wed Nov 23 12:03:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:03:29 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
 <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
Message-ID: <hNvvKuRVBb4WaVJrUDi1JW-jlvDQFWTYspL8U7vwHME=.ef1fe77b-b986-48da-abb4-5bd996b4c8c2@github.com>

On Wed, 23 Nov 2022 08:31:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated review feedback
>
> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 253:
> 
>> 251: 
>> 252:             if (validConnections != cnt) {
>> 253:                 // these connections are not necessarily unexpected if SLEEP exceeds keep-alive.
> 
> Well actually these are unexpected connections; every connection from the tested client will equally count towards `cnt` and `validConnections`.

Ah! good point. I mixed up cnt and threads. I will clean that up.

> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 390:
> 
>> 388:         volatile int timeoutExceeded;
>> 389:         // Number of requests handled by this worker
>> 390:         volatile int requestHandled;
> 
> not used

yeah. it happens to be the same thing than headerFound, unless there's an exception while sending the reply.

> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 423:
> 
>> 421:          * than the KEEP_ALIVE timeout. This will be true if the worker detected
>> 422:          * that the idle timeout was exceeded between two consecutive request, or
>> 423:          * if the time between the last reply
> 
> this needs cleanup

In what way?

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

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

From dfuchs at openjdk.org  Wed Nov 23 12:03:29 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:03:29 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <hNvvKuRVBb4WaVJrUDi1JW-jlvDQFWTYspL8U7vwHME=.ef1fe77b-b986-48da-abb4-5bd996b4c8c2@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
 <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
 <hNvvKuRVBb4WaVJrUDi1JW-jlvDQFWTYspL8U7vwHME=.ef1fe77b-b986-48da-abb4-5bd996b4c8c2@github.com>
Message-ID: <XKJmcgWkdKqlmCO0i7auNpITk1zjBrgJ6D87QZeQiAc=.c82f17d2-a082-44be-a53c-1959bee021fa@github.com>

On Wed, 23 Nov 2022 11:55:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 423:
>> 
>>> 421:          * than the KEEP_ALIVE timeout. This will be true if the worker detected
>>> 422:          * that the idle timeout was exceeded between two consecutive request, or
>>> 423:          * if the time between the last reply
>> 
>> this needs cleanup
>
> In what way?

Oh - I see - I didn't finish that sentence.

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

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

From dfuchs at openjdk.org  Wed Nov 23 12:18:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:18:39 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v5]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <IWV2q_KtlbNb0fibKf-KEcOwFDu_ypfw50ZCLMzQpFA=.eeafce21-014d-403b-8e35-ad2f4d122246@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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

  Incorporated review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/694b9dd6..20c66241

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

  Stats: 32 lines in 1 file changed: 3 ins; 15 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11268/head:pull/11268

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

From pminborg at openjdk.org  Wed Nov 23 12:21:07 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:21:07 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v11]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <Kjp4PS4MZ9xnK5J6RH0LkSqmiG4REMfF2HT62Ca67Mc=.f433fbb7-5a98-494f-a91e-6796d96e6edf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Refactor to try-finally handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/06c764ca..88ae68b8

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

  Stats: 677 lines in 20 files changed: 286 ins; 152 del; 239 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From dfuchs at openjdk.org  Wed Nov 23 12:23:30 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:23:30 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <4C450ZI9QpCeRHMuUgbORDfd64tQSDDz-RuHN3nqxbE=.efcab39b-7c90-4d26-a220-5de31ff02d21@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
 <4C450ZI9QpCeRHMuUgbORDfd64tQSDDz-RuHN3nqxbE=.efcab39b-7c90-4d26-a220-5de31ff02d21@github.com>
Message-ID: <r3hZNnBPRrBOSLKLFzJESacyDezQoZKD6TDflbL9XmM=.c16df9c4-d02d-4cf9-9527-ddc4bd8eba66@github.com>

On Wed, 23 Nov 2022 11:05:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.net.http/share/classes/module-info.java line 136:
>> 
>>> 134:  * <li><p><b>{@systemProperty jdk.httpclient.sendBufferSize}</b> (default: operating system default)<br>
>>> 135:  * The HTTP client socket send buffer size. Values less than or equal to zero are ignored.
>>> 136:  * </li>
>> 
>> I wonder if we should make a note that attempting to specify a receive or send buffer size may be detrimental to performance as it might prevent the underlying system to optimize sending and receiving. Also a link to the corresponding StandardOptions may be in order (same for receive buffer size above).
>
> I would agree with linking to the StandardSocketOption descriptions, as that would also help to distinguish the send buffer option from the write buffer option, which sounds similar. In my view, any discussion of performance trade-offs should be in the StandardSocketOption apidoc rather than here.

Sounds reasonable to me. BTW - you seem to have tripped jcheck due to trailing white spaces.

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

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

From pminborg at openjdk.org  Wed Nov 23 12:39:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:39:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ae68b8..682b6f5a

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

  Stats: 23 lines in 9 files changed: 1 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From dfuchs at openjdk.org  Wed Nov 23 12:47:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:47:43 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>

On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix RFC titles with `RFC NNNN:`

Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

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

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

From michaelm at openjdk.org  Wed Nov 23 13:55:19 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 13:55:19 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v5]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <9AzEBIQUWeGc15wD4lZbON5AyjsVZRi6PaEGh69go9Y=.027ae31e-f5dc-4130-844e-ac3cf3f460f5@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  removed trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/e5530406..1faf6da8

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

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

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

From michaelm at openjdk.org  Wed Nov 23 13:55:23 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 13:55:23 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
Message-ID: <ocUFfZwP4A2YcJYWFhg6nvoRAdGDM9DbEFFuhB76yLc=.5471d7cb-e31c-430e-b45f-93223adb755c@github.com>

On Mon, 21 Nov 2022 13:41:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon 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 http.properties
>>  - update after Daniel's review
>>  - first draft
>
> src/java.net.http/share/classes/module-info.java line 139:
> 
>> 137:  * <li><p><b>{@systemProperty jdk.internal.httpclient.disableHostnameVerification}</b> (default: false)<br>
>> 138:  * If true, hostname verification in SSL certificates is disabled. This is a system property only.
>> 139:  * </li>
> 
> Should we emphasize that it is intended for testing purposes?

Yes, good idea

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

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

From michaelm at openjdk.org  Wed Nov 23 13:58:53 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 13:58:53 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
Message-ID: <Z65FlCnbL-9AsqUuMmp6btJ8xP-BFE3-htkkksMUBxk=.3e541c90-c235-48ca-859b-e09b89bcadd3@github.com>

On Mon, 21 Nov 2022 13:42:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon 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 http.properties
>>  - update after Daniel's review
>>  - first draft
>
> src/java.net.http/share/classes/module-info.java line 147:
> 
>> 145:  * A comma separated list of HTTP authentication scheme names, that are disallowed for use by
>> 146:  * the HTTP client implementation, for HTTP CONNECT tunneling.
>> 147:  * </li>
> 
> Should we provide a link to net-properties.html here?

I don't see the benefit in that?

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

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

From michaelm at openjdk.org  Wed Nov 23 14:04:09 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Nov 2022 14:04:09 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v6]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <KVOM3b8hPtS4E5rvkcD1NwarsLY37bfqXvJ_CkobQW0=.09b4d4e2-7fcd-4e47-8c4e-3ebabd389aba@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  update to SSL cert check property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/1faf6da8..1d6447ce

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

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

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

From dfuchs at openjdk.org  Wed Nov 23 14:24:51 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 14:24:51 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <Z65FlCnbL-9AsqUuMmp6btJ8xP-BFE3-htkkksMUBxk=.3e541c90-c235-48ca-859b-e09b89bcadd3@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
 <Z65FlCnbL-9AsqUuMmp6btJ8xP-BFE3-htkkksMUBxk=.3e541c90-c235-48ca-859b-e09b89bcadd3@github.com>
Message-ID: <bVaqeWDycUK782jKyieY_vGiHRdxOQZ8pZP26unuCY0=.ac3f1370-fcd3-4aaa-887b-9ce6f3383cc8@github.com>

On Wed, 23 Nov 2022 13:55:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.net.http/share/classes/module-info.java line 147:
>> 
>>> 145:  * A comma separated list of HTTP authentication scheme names, that are disallowed for use by
>>> 146:  * the HTTP client implementation, for HTTP CONNECT tunneling.
>>> 147:  * </li>
>> 
>> Should we provide a link to net-properties.html here?
>
> I don't see the benefit in that?

I believe these properties are documented there already.

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

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

From dfuchs at openjdk.org  Wed Nov 23 14:25:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 14:25:37 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v6]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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

  Use the tests list to simplify the logic of waiting for clients to finish

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/20c66241..7b66e0b8

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

  Stats: 38 lines in 1 file changed: 6 ins; 21 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11268/head:pull/11268

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

From duke at openjdk.org  Wed Nov 23 14:32:23 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 23 Nov 2022 14:32:23 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
Message-ID: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>

Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,

This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8294047
 - cleanup of test
 - close HttpResponseInputStream and throw exception on interrupt

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

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

From dfuchs at openjdk.org  Wed Nov 23 14:36:48 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 14:36:48 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v3]
In-Reply-To: <bVaqeWDycUK782jKyieY_vGiHRdxOQZ8pZP26unuCY0=.ac3f1370-fcd3-4aaa-887b-9ce6f3383cc8@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <i5fgkVHnHb92SWik5Ikxmc8Jh0-fkX37VNRYazGvTlE=.842e06b5-6e74-4571-a2e5-89a779758dc4@github.com>
 <EA4_PWM3mSPwGqGQ4TSpKfB2kT3E-ocYGT5zmoNF-LE=.029dca43-f4e6-4dce-b11a-1f7ad0786d8c@github.com>
 <Z65FlCnbL-9AsqUuMmp6btJ8xP-BFE3-htkkksMUBxk=.3e541c90-c235-48ca-859b-e09b89bcadd3@github.com>
 <bVaqeWDycUK782jKyieY_vGiHRdxOQZ8pZP26unuCY0=.ac3f1370-fcd3-4aaa-887b-9ce6f3383cc8@github.com>
Message-ID: <VLcKrRs_brvi77KaC44Nyv3Hxnl5YGvN4CPs2SMIFtw=.c9de4b55-116d-417f-930b-ab06bc2184cc@github.com>

On Wed, 23 Nov 2022 14:21:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I don't see the benefit in that?
>
> I believe these properties are documented there already.

Ah - no. They are not. My mistake. They are documented in conf/net.properties but we can't have a link to that.

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

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

From dfuchs at openjdk.org  Wed Nov 23 14:58:09 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 14:58:09 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v4]
In-Reply-To: <z1FhW6IvIY0uzjZk8e--AgG47et-U0BjVmBQagSKFbM=.8d07ce67-9278-4b41-8533-c85979aa05a7@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <GZ_UHxORCRuWIe7LfXgfYkdoJhhiZZipVc5_Mf3y_cg=.515bc42d-73ed-4a70-a2d5-5a3db3152dd7@github.com>
 <1CUW-9zEghC-s9ndj0TMXkBHyV34Xfad8QWgogZDqjc=.58e5df49-9a53-4a55-a5f7-7447d3c7cc80@github.com>
 <z1FhW6IvIY0uzjZk8e--AgG47et-U0BjVmBQagSKFbM=.8d07ce67-9278-4b41-8533-c85979aa05a7@github.com>
Message-ID: <YneUAsdyZNfv5yu_SOPhhqq6GhWjAviqjvk2xoedKB4=.9db2232e-22b0-473a-8a0f-1cf522e09823@github.com>

On Wed, 23 Nov 2022 11:41:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 183:
>> 
>>> 181:         try {
>>> 182:             Object lock = MultiThreadTest.getLock();
>>> 183:             List<MultiThreadTest> tests = new ArrayList<>();
>> 
>> this list is not used
>
> Good catch. That's a left over from some additional experiment.

I decided to follow up on your (offline) suggestion and actually join the client threads (later). I have also added a countdown latch to make the wait cleaner. As a result the END atomic long is no longer needed and a simple local variable can be used instead.

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

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

From dfuchs at openjdk.org  Wed Nov 23 15:09:38 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 15:09:38 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <6-EcUMbg_o4cV0ViodIZhrTWgOcL-9TfZPckro9tEI4=.d87b1563-5b2b-4792-abf5-c50acd902d58@github.com>

On Wed, 23 Nov 2022 14:21:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 485:

> 483:                 } catch (InterruptedException ex) {
> 484:                     close();
> 485:                     throw new IOException("interrupted", ex);

I'd suggest to throw `InterruptedIOException` here instead. Also it might be better to swallow any exception close() might throw - using `try-finally` around close() should do that.

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

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

From dfuchs at openjdk.org  Wed Nov 23 15:13:04 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 15:13:04 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <RcEQqTTSCC6HL3xjbCwQ-dYS2kiL-kWW_Ec9uH8X95o=.72c7912a-0756-42ca-9016-14fe2ccc0a82@github.com>

On Wed, 23 Nov 2022 14:21:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 87:

> 85:             Thread interrupterThread = new Thread(() -> {
> 86:                 try {
> 87:                     countDownLatch.await();

It would be useful to add a comment before waiting on the latch to explain what you are waiting for.

test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 107:

> 105:     static class Handler implements HttpHandler {
> 106: 
> 107:         CountDownLatch countDownLatch;

Maybe a better name than `countDownLatch` could be found - that could give a clue on what this latch is used to wait for?

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

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

From mcimadamore at openjdk.org  Wed Nov 23 16:17:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Nov 2022 16:17:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
Message-ID: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>

On Wed, 23 Nov 2022 12:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:

> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
> 124:      */
> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);

I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.

I suggest to rename:

* `acquireSession` -> `acquireSessionAsRunnable`
* `acquireScopeOrNull` -> `acquireSession`
* `releaseScope` -> `releaseSession`

Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:

> 162:     int pageSize();
> 163: 
> 164:     sealed interface ScopeAcquisition extends AutoCloseable {

Is this still needed?

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

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

From jjg at openjdk.org  Wed Nov 23 16:47:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 16:47:22 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
 <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com>

On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages.

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

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

From pminborg at openjdk.org  Wed Nov 23 17:40:24 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 17:40:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
 <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
Message-ID: <R-M2NOUc9X1tA-Pe-Jm81A06WpAJ-NizI8IliAGDMR4=.e8c0957c-f78b-4573-8e68-90e90df6c101@github.com>

On Wed, 23 Nov 2022 16:14:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup
>
> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:
> 
>> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
>> 124:      */
>> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);
> 
> I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.
> 
> I suggest to rename:
> 
> * `acquireSession` -> `acquireSessionAsRunnable`
> * `acquireScopeOrNull` -> `acquireSession`
> * `releaseScope` -> `releaseSession`
> 
> Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

The name "scope" was used in anticipation of the new proposed Java 20 naming. But I can change it back to session again. We could always rename later.

> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:
> 
>> 162:     int pageSize();
>> 163: 
>> 164:     sealed interface ScopeAcquisition extends AutoCloseable {
> 
> Is this still needed?

Well spotted.

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

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

From jjg at openjdk.org  Wed Nov 23 18:57:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 18:57:03 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

  Remove updates from unexported files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83

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

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

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

From dfuchs at openjdk.org  Wed Nov 23 19:23:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:23:53 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

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

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

From dfuchs at openjdk.org  Wed Nov 23 19:46:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:46:32 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails in
 AssertionError due to misplaced assert
Message-ID: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>

The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.

After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.

Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.

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

Commit messages:
 - 8297424

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

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

From jjg at openjdk.org  Wed Nov 23 22:09:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 22:09:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
Message-ID: <CN_yhlxSOuJ_vrZwgtwLXWapiBa9Df2Cab1ySShZvu4=.b3e2212d-2f5d-4cea-a28b-8a02e3b18159@github.com>

On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information.

The general history of this work is:
* version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish
* version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load
* version 3: new tag, with no external file needed -- as you see here

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

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

From joehw at openjdk.org  Wed Nov 23 23:08:05 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:08:05 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:

> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition

Hi Jon,

I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
points to the fifth edition while @see second.

A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.

[1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

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

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

From joehw at openjdk.org  Wed Nov 23 23:43:57 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:43:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc).

src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35:

> 33:  *
> 34:  * @spec https://www.w3.org/TR/xslt xslt cover page - W3C
> 35:  * @see <a href="http://www.w3.org/TR/xslt#output">

The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? 
      https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0
      
The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: 
    https://www.w3.org/TR/1999/REC-xslt-19991116#output

src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104:

> 102:  * @author  Norman Walsh
> 103:  * @author  Jeff Suttor
> 104:  * @see <a href="http://www.w3.org/TR/xpath">XML Path Language (XPath) Version 1.0</a>

Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be:
    https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0
    
Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref.

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

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

From duke at openjdk.org  Thu Nov 24 04:09:20 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 24 Nov 2022 04:09:20 GMT
Subject: RFR: 8051627: Invariants about java.net.URI resolve and relativize
 are wrong [v2]
In-Reply-To: <wDSjIlOQDiZAMd7_HC45Zx3EFUBaI98-benpJ8jt-QU=.ba85c97b-1816-4ab5-8581-d359944ed200@github.com>
References: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
 <pdycK3KGzPs0pH2yjmLMdZHLJKjgiqjU3NSL-fINpVs=.4ac4dbb8-989b-4267-8ad5-dc84e64b7084@github.com>
 <MaEBNWgVrkBzJaFaZSdGH5LrSJX6eledIlDysgsLn5k=.d5af09f8-c8a8-4581-b5b5-db9df6adf145@github.com>
 <wDSjIlOQDiZAMd7_HC45Zx3EFUBaI98-benpJ8jt-QU=.ba85c97b-1816-4ab5-8581-d359944ed200@github.com>
Message-ID: <Sd4Ji_83TPbVP3RrDzzA9rrFLuWvlejHDlAwQmpK6d0=.558e6c8c-3a3f-44f1-9ac7-4d092c3c9a6e@github.com>

On Wed, 28 Sep 2022 11:11:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch 
>> Thank you for your review and suggestions.
>> 
>>> A colon ':' may be more appropriate than a period '.' at the end of this sentence:
>>> I'd suggest:
>> 
>> You?re right. I changed to use a colon.
>> 
>>> Could you update the UriTest with some examples and counter-examples to validate this claim?
>> 
>> I added tests in URI/Test.java.  
>> The tests include testing if the resolve-relativize relationship stand when the two URIs meet the condition of the modified javadoc.  
>> The tests also include testing if the relationship does not stand when the two specific URIs which meets the condition of the original javadoc are given. These URIs are excluded by the condition of the modiied javadoc.
>
> Hi @tkiriyama sorry for taking so long to get back to you. I had a look at the CSR - and fixed a few missing fields, and added myself as reviewer. Please move its state to "Proposed" to get this moving further.

@dfuch 
The CSR of this pull request was moved to "CLOSED".   
Could you review this pull request again?

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

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

From djelinski at openjdk.org  Thu Nov 24 09:47:18 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Nov 2022 09:47:18 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v6]
In-Reply-To: <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>
Message-ID: <fM5Mv0cBTMayMTLYtnEkYT8OkC_ryP5rqgdtVwGuNwI=.d73ae549-d1b1-437a-8a39-681eaeda19f2@github.com>

On Wed, 23 Nov 2022 14:25:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
>> 
>> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
>> 
>> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
>> 
>> This fix works this way: 
>> 
>> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
>> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
>> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
>> 
>> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
>> 
>> With this fix I no longer observe the test failing.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the tests list to simplify the logic of waiting for clients to finish

Marked as reviewed by djelinski (Committer).

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

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

From alanb at openjdk.org  Thu Nov 24 10:56:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 10:56:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <W_PDXjCTWZO6xXPHhF-LLKnDxtRgwgI9zdv9Se52Rqo=.0ae98a38-5f76-4839-b579-ab19faf1945b@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.se/share/classes/module-info.java line 39:

> 37:  *
> 38:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 39:  * @spec jni/index.html Java Native Interface Specification

One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already?

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

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

From michaelm at openjdk.org  Thu Nov 24 11:13:17 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Nov 2022 11:13:17 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v6]
In-Reply-To: <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>
Message-ID: <Q8FwLkEolVtdM0wD7Vf9rUVKtzZwyAJkz3wDrbbK4xE=.eb3646a3-598a-43e1-9491-cbe77af3233c@github.com>

On Wed, 23 Nov 2022 14:25:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
>> 
>> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
>> 
>> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
>> 
>> This fix works this way: 
>> 
>> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
>> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
>> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
>> 
>> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
>> 
>> With this fix I no longer observe the test failing.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the tests list to simplify the logic of waiting for clients to finish

test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 193:

> 191:             // our client. We should only count those workers for which
> 192:             // the expected header has been found.
> 193:             int validConnections = 0;

Could you also add a comment like:

// We detect worker threads that may have timed out, so we don't include them in
// the count to compare with the number of connections.

Otherwise, LGTM

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

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

From michaelm at openjdk.org  Thu Nov 24 11:18:33 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Nov 2022 11:18:33 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  update to be compatible with JDK-8297030

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/1d6447ce..55380083

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

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

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

From pminborg at openjdk.org  Thu Nov 24 11:42:52 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 11:42:52 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove redundant method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/682b6f5a..0546b23b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11-12

  Stats: 213 lines in 20 files changed: 12 ins; 105 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From dfuchs at openjdk.org  Thu Nov 24 11:53:11 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 11:53:11 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v7]
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <RVxSNdA9ECYEvsDPUrzaH7dfOv8T7JDrl2VS-m3Pl9Y=.1e020644-f7af-41ad-8071-30f2b2b00498@github.com>

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

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

 - Merge branch 'master' into MultiThreadTest-8223783
 - Add a comment
 - Use the tests list to simplify the logic of waiting for clients to finish
 - Incorporated review feedback
 - Incorporated review feedback
 - Merge branch 'master' into MultiThreadTest-8223783
 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - 8223783

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11268/files
  - new: https://git.openjdk.org/jdk/pull/11268/files/7b66e0b8..c5c13325

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

  Stats: 7285 lines in 154 files changed: 4611 ins; 1815 del; 859 mod
  Patch: https://git.openjdk.org/jdk/pull/11268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11268/head:pull/11268

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

From dfuchs at openjdk.org  Thu Nov 24 11:53:15 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 11:53:15 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v6]
In-Reply-To: <Q8FwLkEolVtdM0wD7Vf9rUVKtzZwyAJkz3wDrbbK4xE=.eb3646a3-598a-43e1-9491-cbe77af3233c@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <UB6tK11UTQtoiHSkoWdQ5KLbH11yLdbIKDBbTOZxX1A=.1297386a-46be-4ebd-8148-7b8bb5877ac7@github.com>
 <Q8FwLkEolVtdM0wD7Vf9rUVKtzZwyAJkz3wDrbbK4xE=.eb3646a3-598a-43e1-9491-cbe77af3233c@github.com>
Message-ID: <TixotdkcxODRmpnAx-a83LBB8Usb6opKNYgwiXK_HRE=.c7e55ad8-6c93-44ea-ada3-e2d72ecd32c7@github.com>

On Thu, 24 Nov 2022 11:10:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the tests list to simplify the logic of waiting for clients to finish
>
> test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java line 193:
> 
>> 191:             // our client. We should only count those workers for which
>> 192:             // the expected header has been found.
>> 193:             int validConnections = 0;
> 
> Could you also add a comment like:
> 
> // We detect worker threads that may have timed out, so we don't include them in
> // the count to compare with the number of connections.
> 
> Otherwise, LGTM

Done!

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

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

From mcimadamore at openjdk.org  Thu Nov 24 11:53:28 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:53:28 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <U9NPKtU24wSF4q7X1EkgR2dbIW5k3Oe1mLs8iqAs1Ks=.c12f9a79-db57-46d0-8ccd-b26c0a077816@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

Looks good - I'm glad that the changes to IOUtil turned out simpler than expected!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.org  Thu Nov 24 11:57:09 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:57:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:

> 517:     }
> 518: 
> 519:     record LinkedRunnable(Runnable node, Runnable next)

Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

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

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

From dfuchs at openjdk.org  Thu Nov 24 11:59:48 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 11:59:48 GMT
Subject: RFR: 8051627: Invariants about java.net.URI resolve and relativize
 are wrong [v2]
In-Reply-To: <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
References: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
 <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
Message-ID: <8A1x0PsDVO3w0JYJLV4vN4mA9VtGUrPGWdfjQpZkFss=.9f85251d-3aa3-4f2b-9314-ea2bba788d81@github.com>

On Fri, 16 Sep 2022 07:20:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> The current documentation of URI class describes relationship between resolve and relativize methods as follows.
>> 
>> 
>> For any two normalized URIs u and v,
>>     u.relativize(u.resolve(v)).equals(v) and
>>     u.resolve(u.relativize(v)).equals(v) .
>> 
>> 
>> However, there are some cases where this relationship is not true. For example, when u and v are "http://a/b" and "c/d", respectively, both u.relativize(u.resolve(v)) and u.resolve(u.relativize(v)) equal to "http://a/c/d" not "c/d". The documentation should be updated to avoid confusion by describing the relationship between resolve nd relativize methods under certain conditions of the URI. Note that these conditions are sufficient but not necessary for the statement.
>
> KIRIYAMA Takuya 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:
> 
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - Merge branch 'master' into 8051627
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong

Marked as reviewed by dfuchs (Reviewer).

Done! Thanks for reminding me.

If you need a sponsor please drop a note here after integrating.

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

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

From mcimadamore at openjdk.org  Thu Nov 24 12:00:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
Message-ID: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>

On Thu, 24 Nov 2022 11:54:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
> 
>> 517:     }
>> 518: 
>> 519:     record LinkedRunnable(Runnable node, Runnable next)
> 
> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).

Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

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

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

From mcimadamore at openjdk.org  Thu Nov 24 12:00:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
Message-ID: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>

On Thu, 24 Nov 2022 11:57:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
>> 
>>> 517:     }
>>> 518: 
>>> 519:     record LinkedRunnable(Runnable node, Runnable next)
>> 
>> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.
>
> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
> 
> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

(to be clear, some of the above comments refer to the code that was already there before your changes)

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

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

From duke at openjdk.org  Thu Nov 24 12:13:54 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 24 Nov 2022 12:13:54 GMT
Subject: RFR: 8051627: Invariants about java.net.URI resolve and relativize
 are wrong [v2]
In-Reply-To: <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
References: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
 <u7x-J4emb0_NXSZUTuuZpWAKQ7WmYQkd6DQ-MhAVaoM=.7dbd6e8e-7621-4af7-a678-a9fcf2683f52@github.com>
Message-ID: <Pyu91Ix9DKycAOU-CPfwmX9ZY8Mf2UVeNk8ghpKjWGo=.66931e7b-32af-4aa4-b2df-82d74708959c@github.com>

On Fri, 16 Sep 2022 07:20:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> The current documentation of URI class describes relationship between resolve and relativize methods as follows.
>> 
>> 
>> For any two normalized URIs u and v,
>>     u.relativize(u.resolve(v)).equals(v) and
>>     u.resolve(u.relativize(v)).equals(v) .
>> 
>> 
>> However, there are some cases where this relationship is not true. For example, when u and v are "http://a/b" and "c/d", respectively, both u.relativize(u.resolve(v)) and u.resolve(u.relativize(v)) equal to "http://a/c/d" not "c/d". The documentation should be updated to avoid confusion by describing the relationship between resolve nd relativize methods under certain conditions of the URI. Note that these conditions are sufficient but not necessary for the statement.
>
> KIRIYAMA Takuya 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:
> 
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - Merge branch 'master' into 8051627
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong
>  - 8051627: Invariants about java.net.URI resolve and relativize are wrong

Thank you for your review. Could you sponsor this pull request, please?

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

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

From michaelm at openjdk.org  Thu Nov 24 12:16:24 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Nov 2022 12:16:24 GMT
Subject: RFR: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections [v7]
In-Reply-To: <RVxSNdA9ECYEvsDPUrzaH7dfOv8T7JDrl2VS-m3Pl9Y=.1e020644-f7af-41ad-8071-30f2b2b00498@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
 <RVxSNdA9ECYEvsDPUrzaH7dfOv8T7JDrl2VS-m3Pl9Y=.1e020644-f7af-41ad-8071-30f2b2b00498@github.com>
Message-ID: <cAZGNduFtaCu_MMMlxtzgdwR8ogHtL4dYpWrqtNIcHg=.57082388-2430-47b9-a07e-f9e0c373d4ec@github.com>

On Thu, 24 Nov 2022 11:53:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
>> 
>> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
>> 
>> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
>> 
>> This fix works this way: 
>> 
>> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
>> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
>> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
>> 
>> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
>> 
>> With this fix I no longer observe the test failing.
>
> 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into MultiThreadTest-8223783
>  - Add a comment
>  - Use the tests list to simplify the logic of waiting for clients to finish
>  - Incorporated review feedback
>  - Incorporated review feedback
>  - Merge branch 'master' into MultiThreadTest-8223783
>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - 8223783

Marked as reviewed by michaelm (Reviewer).

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

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

From alanb at openjdk.org  Thu Nov 24 12:17:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 12:17:06 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 790:

> 788:         try {
> 789:             int n = receive0(fd,
> 790:                     ((DirectBuffer)bb).address() + pos, rem,

Would it be possible to restore the original alignment, just to make it easier to read.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 39:

> 37:     // silent unrelated memory mutation and JVM crashes.
> 38:     //
> 39:     // Guards are available in the JavaNioAccess class.

Did you mean to leave the word "Guards" in the comment? I guess I would say something "See JavaNioAccess for methods to acquire/release" or something like that.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:

> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
> 480:             throw new IllegalStateException("Confined session not supported");

No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 543:

> 541:         @Override public void run() { releaseScope(bb, session); }
> 542:         static Runnable of(ByteBuffer bb, MemorySessionImpl session) { return new Releaser(bb, session); }
> 543:         static Runnable ofNullable(ByteBuffer bb, MemorySessionImpl session) {

Would it be possible to re-format this to make it more readable? There's just a bit more going on compared to the original and it's harder to read.

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

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

From jpai at openjdk.org  Thu Nov 24 12:28:56 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Nov 2022 12:28:56 GMT
Subject: RFR: 8297569: URLPermission constructor throws
 IllegalArgumentException: Invalid characters in hostname after JDK-8294378
Message-ID: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>

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

Recently we fixed a bug in `java.net.URLPermission` where that class used to run into an exception while trying to convert a hostname into lowercase, when run in Turkish locale https://bugs.openjdk.org/browse/JDK-8294378. The approach we decided to take in that fix  was to use an internal `HostPortRange.toLowerCase` method which was unaffected by `Locale`s. The other alternative was to use `String.toLowerCase(Locale.ROOT)`, but we decided to use the former since it was already being used in other parts of the code in that area.

The implementation of `HostPortRange.toLowerCase` is very strict and it allows only a specific set of characters. The `_` (underscore character) isn't one of them. Before the change we did there, a `URLPermission` constructor could be passed a string `http://foo_bar` and it used to construct the instance successfully. However, after that change, it now fails with the exception noted in the issue.

The commit here reverts the previous fix and instead now uses `String.toLowerCase(Locale.ROOT)` to lowercase the authority. Additionally, an `else` block that we had introduced in the previous fix has been removed to bring us back to the old behaviour.

The test has been updated to include `http://foo_bar` (and its one more variant) string to construct the `URLPermission` instance.

JCK testing with the changes in this PR passed and other `tier` testing is currently in progress.

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

Commit messages:
 - 8297569: URLPermission constructor throws IllegalArgumentException: Invalid characters in hostname after JDK-8294378

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

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

From michaelm at openjdk.org  Thu Nov 24 14:07:01 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Nov 2022 14:07:01 GMT
Subject: RFR: 8297030: Reduce Default Keep-Alive Timeout Value for
 httpclient
In-Reply-To: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
References: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
Message-ID: <zAWLr2U8SxlR2JuGa2_2vmVo-3STN5lkSSy3zsI0_JE=.5d3be193-af26-410d-b2fc-da94f294adad@github.com>

On Tue, 22 Nov 2022 11:10:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.
> 
> This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.
> 
> Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

Marked as reviewed by michaelm (Reviewer).

30 seconds sounds good.

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

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

From pminborg at openjdk.org  Thu Nov 24 14:52:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:52:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
 <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
Message-ID: <dy4zEuWXA_iymssRu8PCeqXXnU77AA-ncC3veSg6xOA=.7d822c4a-9c34-4e1b-9dcf-6d6956601e4b@github.com>

On Thu, 24 Nov 2022 11:58:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
>> 
>> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.
>
> (to be clear, some of the above comments refer to the code that was already there before your changes)

I also found the above as a bit odd but tried to stick with the existing implementation and style as much as possible.

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

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

From pminborg at openjdk.org  Thu Nov 24 14:58:19 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:58:19 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
Message-ID: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>

On Thu, 24 Nov 2022 12:06:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
> 
>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>> 480:             throw new IllegalStateException("Confined session not supported");
> 
> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

This was the old behaviour which was retained in this PR.

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

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

From duke at openjdk.org  Thu Nov 24 16:19:39 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 24 Nov 2022 16:19:39 GMT
Subject: Integrated: 8051627: Invariants about java.net.URI resolve and
 relativize are wrong
In-Reply-To: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
References: <sJnAbkXl10kX_eI6XmGowrno6UBLtyDEMJf3Ao0Q9c0=.1c3c2e6d-6001-46c5-8f0b-6c334c271419@github.com>
Message-ID: <VirHWQ6oUfFD6cYfhPxMM-uto1eNlQ6aO3rgH9E8t6M=.ea8b8163-0756-4378-aaeb-1e75a9e34e85@github.com>

On Thu, 28 Jul 2022 06:48:56 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> The current documentation of URI class describes relationship between resolve and relativize methods as follows.
> 
> 
> For any two normalized URIs u and v,
>     u.relativize(u.resolve(v)).equals(v) and
>     u.resolve(u.relativize(v)).equals(v) .
> 
> 
> However, there are some cases where this relationship is not true. For example, when u and v are "http://a/b" and "c/d", respectively, both u.relativize(u.resolve(v)) and u.resolve(u.relativize(v)) equal to "http://a/c/d" not "c/d". The documentation should be updated to avoid confusion by describing the relationship between resolve nd relativize methods under certain conditions of the URI. Note that these conditions are sufficient but not necessary for the statement.

This pull request has now been integrated.

Changeset: ab1f9ffa
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab1f9ffa78ca95b67b6d57936a70c49abf18fd00
Stats:     57 lines in 2 files changed: 52 ins; 0 del; 5 mod

8051627: Invariants about java.net.URI resolve and relativize are wrong

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.org  Thu Nov 24 16:21:38 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 16:21:38 GMT
Subject: Integrated: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java
 sometimes detect threads+1 connections
In-Reply-To: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
References: <WhLF_ogZtp97wgMHSwkkI9jze-Hj1qlQxyhfKzaFW1Q=.68bbcce1-75e4-4c05-b009-e0ff704a4132@github.com>
Message-ID: <Oath-0HHDPQbqTUWwQMbZXHPDYsE_QXopW1M0sfhhAE=.312e2b58-5cbf-4739-937d-532df66538e2@github.com>

On Mon, 21 Nov 2022 15:12:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a test fix for the sun/net/www/http/HttpClient/MultiThreadTest.
> 
> This test makes concurrent connections to a server using multiple threads, and due to keep-alive, expects that there should not be more connections than concurrent threads. However, the test has been seen occasionally and intermittently failing because it observed more connections than threads. The test has some built-in logic to exclude connections that do not come from the test itself, so external interference should not be the cause.
> 
> The suspicion is that occasionally some connection might remain idle for more than the keep-alive timeout, which then causes it to be closed, and allows the client to open a new connection.
> 
> This fix works this way: 
> 
> - first it adds some logic to figure out whether a Worker thread might have remained idle for more than the keep-alive timeout
> - then it takes this information into account when matching the number of actual connections with the number of expected connection,
> - additionally it reduces the keep-alive timeout to one second, and forces some sleep on the client side after half the requests have been sent to increase the probability that some connections will be idle long enough to trigger the idle-time detection logic (as a means to test the fix itself). 
> 
> Finally it improves logging by adding more diagnosis (including human readable time stamps), so that future failures, if any, will be easier to diagnose. Note that reducing the keep-alive time to 1 second makes the test run much faster even with the 1500ms sleep on the client side.
> 
> With this fix I no longer observe the test failing.

This pull request has now been integrated.

Changeset: 8effaa8f
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8effaa8f1f550d2cd0ff369f99436a8a7401fa10
Stats:     256 lines in 1 file changed: 169 ins; 24 del; 63 mod

8223783: sun/net/www/http/HttpClient/MultiThreadTest.java sometimes detect threads+1 connections

Reviewed-by: djelinski, michaelm

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

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

From pminborg at openjdk.org  Thu Nov 24 16:21:42 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 16:21:42 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Reformat and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0546b23b..30aff118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12-13

  Stats: 26 lines in 3 files changed: 13 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From duke at openjdk.org  Thu Nov 24 16:39:20 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Thu, 24 Nov 2022 16:39:20 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
In-Reply-To: <RcEQqTTSCC6HL3xjbCwQ-dYS2kiL-kWW_Ec9uH8X95o=.72c7912a-0756-42ca-9016-14fe2ccc0a82@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <RcEQqTTSCC6HL3xjbCwQ-dYS2kiL-kWW_Ec9uH8X95o=.72c7912a-0756-42ca-9016-14fe2ccc0a82@github.com>
Message-ID: <J3IjLKuKT-ixLm66Qw4_p3so5xY1OgrCYHCcjwvrN8I=.08e5259a-a1d9-4321-a844-301f1acdd7f8@github.com>

On Wed, 23 Nov 2022 15:10:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 107:
> 
>> 105:     static class Handler implements HttpHandler {
>> 106: 
>> 107:         CountDownLatch countDownLatch;
> 
> Maybe a better name than `countDownLatch` could be found - that could give a clue on what this latch is used to wait for?

I was thinking maybe `messageLatch`, `messageReceivedLatch` or `clientReadyLatch`

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

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

From dfuchs at openjdk.org  Thu Nov 24 17:08:02 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 17:08:02 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
In-Reply-To: <J3IjLKuKT-ixLm66Qw4_p3so5xY1OgrCYHCcjwvrN8I=.08e5259a-a1d9-4321-a844-301f1acdd7f8@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <RcEQqTTSCC6HL3xjbCwQ-dYS2kiL-kWW_Ec9uH8X95o=.72c7912a-0756-42ca-9016-14fe2ccc0a82@github.com>
 <J3IjLKuKT-ixLm66Qw4_p3so5xY1OgrCYHCcjwvrN8I=.08e5259a-a1d9-4321-a844-301f1acdd7f8@github.com>
Message-ID: <LsMmMZ1IUO_VRdnDpQ94NzSeqBayMasiNb2_Rl3zWI4=.f332201b-5e05-447b-bd6f-d1302d9cc029@github.com>

On Thu, 24 Nov 2022 16:36:51 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 107:
>> 
>>> 105:     static class Handler implements HttpHandler {
>>> 106: 
>>> 107:         CountDownLatch countDownLatch;
>> 
>> Maybe a better name than `countDownLatch` could be found - that could give a clue on what this latch is used to wait for?
>
> I was thinking maybe `messageLatch`, `messageReceivedLatch` or `clientReadyLatch`

Maybe we rename both:

countDownLatch  => interruptReadyLatch
interruptLatch  => interruptDoneLatch

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

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

From dfuchs at openjdk.org  Thu Nov 24 17:13:57 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 17:13:57 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <iKVi8L4atOqC0H8A7whOBI1ikkdpYtwSHlpv7XG1e3E=.66b4fd8a-8745-4f05-95f0-4fe21563633c@github.com>

On Wed, 23 Nov 2022 14:21:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 71:

> 69:         port = server.getAddress().getPort();
> 70:         Handler handler = new Handler(countDownLatch, interruptLatch);
> 71:         server.createContext("/", handler);

It would be good to use a path unique for this test to avoid potential interferences. I would suggest registering the context under "/HttpResponseInputStreamInterruptTest/" instead of "/".

And use that when building the URI below as well.

This is important because the handler is using latches, and therefore can be invoked only once...

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

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

From dfuchs at openjdk.org  Thu Nov 24 17:19:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Nov 2022 17:19:21 GMT
Subject: RFR: 8297569: URLPermission constructor throws
 IllegalArgumentException: Invalid characters in hostname after JDK-8294378
In-Reply-To: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
References: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
Message-ID: <zwxHUiIVloaJmlIMQG04EGylAJU8L8EpnSXvlpeIVjY=.e1765e04-573b-444a-926a-bc06c40935eb@github.com>

On Thu, 24 Nov 2022 12:19:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8297569?
> 
> Recently we fixed a bug in `java.net.URLPermission` where that class used to run into an exception while trying to convert a hostname into lowercase, when run in Turkish locale https://bugs.openjdk.org/browse/JDK-8294378. The approach we decided to take in that fix  was to use an internal `HostPortRange.toLowerCase` method which was unaffected by `Locale`s. The other alternative was to use `String.toLowerCase(Locale.ROOT)`, but we decided to use the former since it was already being used in other parts of the code in that area.
> 
> The implementation of `HostPortRange.toLowerCase` is very strict and it allows only a specific set of characters. The `_` (underscore character) isn't one of them. Before the change we did there, a `URLPermission` constructor could be passed a string `http://foo_bar` and it used to construct the instance successfully. However, after that change, it now fails with the exception noted in the issue.
> 
> The commit here reverts the previous fix and instead now uses `String.toLowerCase(Locale.ROOT)` to lowercase the authority. Additionally, an `else` block that we had introduced in the previous fix has been removed to bring us back to the old behaviour.
> 
> The test has been updated to include `http://foo_bar` (and its one more variant) string to construct the `URLPermission` instance.
> 
> JCK testing with the changes in this PR passed and other `tier` testing is currently in progress.

Marked as reviewed by dfuchs (Reviewer).

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

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

From aturbanov at openjdk.org  Thu Nov 24 20:23:18 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Nov 2022 20:23:18 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v2]
In-Reply-To: <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <1zgQ3Gw5kNbXEh-KVis-Supsk1QGoe9j7xwcTIXiE4w=.b33566ac-6e6f-4a67-9b90-d51f6c894ab2@github.com>
Message-ID: <Ea0QV8Lsvibjn1wzwjxy5vy4fiO6La10bZpLLRjUfpY=.443f6617-2317-4b8f-88ce-335ec51c6c5a@github.com>

On Tue, 22 Nov 2022 21:34:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed race condition in detecting if selector is still alive

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

> 246:         if (fail != null) {
> 247:             if (printThreads && tracker.isSelectorAlive()) {
> 248:                 var msg = "Selector manager threads are still alive for "  + tracker.getName() + ": ";

Nit:
Suggestion:

                var msg = "Selector manager threads are still alive for " + tracker.getName() + ": ";

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

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

From jpai at openjdk.org  Fri Nov 25 01:28:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 01:28:24 GMT
Subject: RFR: 8297569: URLPermission constructor throws
 IllegalArgumentException: Invalid characters in hostname after JDK-8294378
In-Reply-To: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
References: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
Message-ID: <aOSSfYhkEyi433rK0K8doOH9U56aTBGCSeThK3J2Ht8=.3f80bd05-99aa-4916-b09e-a3860982feff@github.com>

On Thu, 24 Nov 2022 12:19:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8297569?
> 
> Recently we fixed a bug in `java.net.URLPermission` where that class used to run into an exception while trying to convert a hostname into lowercase, when run in Turkish locale https://bugs.openjdk.org/browse/JDK-8294378. The approach we decided to take in that fix  was to use an internal `HostPortRange.toLowerCase` method which was unaffected by `Locale`s. The other alternative was to use `String.toLowerCase(Locale.ROOT)`, but we decided to use the former since it was already being used in other parts of the code in that area.
> 
> The implementation of `HostPortRange.toLowerCase` is very strict and it allows only a specific set of characters. The `_` (underscore character) isn't one of them. Before the change we did there, a `URLPermission` constructor could be passed a string `http://foo_bar` and it used to construct the instance successfully. However, after that change, it now fails with the exception noted in the issue.
> 
> The commit here reverts the previous fix and instead now uses `String.toLowerCase(Locale.ROOT)` to lowercase the authority. Additionally, an `else` block that we had introduced in the previous fix has been removed to bring us back to the old behaviour.
> 
> The test has been updated to include `http://foo_bar` (and its one more variant) string to construct the `URLPermission` instance.
> 
> JCK testing with the changes in this PR passed and other `tier` testing is currently in progress.

Thank you Daniel for the review.

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

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

From jpai at openjdk.org  Fri Nov 25 01:28:25 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 01:28:25 GMT
Subject: Integrated: 8297569: URLPermission constructor throws
 IllegalArgumentException: Invalid characters in hostname after JDK-8294378
In-Reply-To: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
References: <IvleGYyS2m90cKx9E3TWAzVtSeeyQASXMNusEhW7x5o=.642e3871-20e6-46dd-8d73-e5f864fa643f@github.com>
Message-ID: <zDMQxn9EzJQLgbSZY94dU0nsaH1cFPuqYQvcj1EE1AU=.1cb341f4-7031-488c-81c9-c3d0b84c332e@github.com>

On Thu, 24 Nov 2022 12:19:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8297569?
> 
> Recently we fixed a bug in `java.net.URLPermission` where that class used to run into an exception while trying to convert a hostname into lowercase, when run in Turkish locale https://bugs.openjdk.org/browse/JDK-8294378. The approach we decided to take in that fix  was to use an internal `HostPortRange.toLowerCase` method which was unaffected by `Locale`s. The other alternative was to use `String.toLowerCase(Locale.ROOT)`, but we decided to use the former since it was already being used in other parts of the code in that area.
> 
> The implementation of `HostPortRange.toLowerCase` is very strict and it allows only a specific set of characters. The `_` (underscore character) isn't one of them. Before the change we did there, a `URLPermission` constructor could be passed a string `http://foo_bar` and it used to construct the instance successfully. However, after that change, it now fails with the exception noted in the issue.
> 
> The commit here reverts the previous fix and instead now uses `String.toLowerCase(Locale.ROOT)` to lowercase the authority. Additionally, an `else` block that we had introduced in the previous fix has been removed to bring us back to the old behaviour.
> 
> The test has been updated to include `http://foo_bar` (and its one more variant) string to construct the `URLPermission` instance.
> 
> JCK testing with the changes in this PR passed and other `tier` testing is currently in progress.

This pull request has now been integrated.

Changeset: 2f47f83a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f47f83addd7f69db2c7070552a7ec67bd07d62e
Stats:     7 lines in 3 files changed: 2 ins; 3 del; 2 mod

8297569: URLPermission constructor throws IllegalArgumentException: Invalid characters in hostname after JDK-8294378

Reviewed-by: dfuchs

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

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

From jpai at openjdk.org  Fri Nov 25 06:02:06 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 06:02:06 GMT
Subject: RFR: 8297030: Reduce Default Keep-Alive Timeout Value for
 httpclient
In-Reply-To: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
References: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
Message-ID: <ryyJNAEZ5NVayyGO6bvKRauuo4N6isK-JP8qW4IG2IA=.44cb4add-d2a7-4fa9-bc34-8df4c6bc7962@github.com>

On Tue, 22 Nov 2022 11:10:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.
> 
> This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.
> 
> Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

Marked as reviewed by jpai (Reviewer).

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

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

From jpai at openjdk.org  Fri Nov 25 06:30:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 06:30:17 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert
In-Reply-To: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
Message-ID: <loKKnh9tFrfmxoO2cWg06gB2e-0WBRCsxebsnOFNutA=.4b4c284e-aa09-42b6-b8a2-f0703d84d105@github.com>

On Wed, 23 Nov 2022 19:38:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
> 
> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
> 
> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.

Hello Daniel, the change where we move the assert into the synchronized block looks fine to me. Looking at the code I think the check to see that the `buffers` can accomodate at least 2 elements (when `onSubscribe` is called) looks correct to me because the `buffers` will be initialized in the constructor of `HttpResponseInputStream` with a capacity of at least 2. So the assert itself looks correct.

This PR also has changes in the `Stream` class. Some of those changes are typo related fixes, so that's fine. However, it also has other functional changes. Is that intentional and related?

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

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

From duke at openjdk.org  Fri Nov 25 06:49:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 25 Nov 2022 06:49:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
Message-ID: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>

On Thu, 24 Nov 2022 14:56:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
>> 
>>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>>> 480:             throw new IllegalStateException("Confined session not supported");
>> 
>> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.
>
> This was the old behaviour which was retained in this PR.

I?believe `UnsupportedOperationException` would?be?better for?this.

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

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

From jpai at openjdk.org  Fri Nov 25 07:15:27 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 07:15:27 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
Message-ID: <H3mwvY44DyobtkEaEerX7IMQAm0Ad4h5f0Cl0jmVIHE=.e8e17c8f-aace-4a9e-b816-1db711a931e7@github.com>

On Thu, 24 Nov 2022 11:18:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to be compatible with JDK-8297030

src/java.net.http/share/classes/module-info.java line 84:

> 82:  *   <li>ssl</li>
> 83:  *   <li>trace</li>
> 84:  *   <li>channel</li>

Hello Michael, is it intentional that we haven't documented `content` in this list?

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

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

From alanb at openjdk.org  Fri Nov 25 07:17:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Nov 2022 07:17:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
 <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
Message-ID: <AaszrcsHg-zt8e_GlzGdKqfyrJ-mbkKIgVmUDxjzJWc=.cfca580b-34e7-458b-b3d1-daedc73e1ba9@github.com>

On Fri, 25 Nov 2022 06:46:52 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?believe `UnsupportedOperationException` would?be?better for?this.

It would but Per is right that this it is throwing ISE today, it's just that the PR adds an explicit check and that highlights that the wrong exception is thrown. Buffers that are views over memory that is thread confined can't be used with the AsynchronousXXXX APIs and this will needed to be specified. There is further work required in this area too because IOUtil was intended for synchronous I/O. The "async" support was added on a temporary basis and will need to be re-visited at some point.

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

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

From jpai at openjdk.org  Fri Nov 25 07:24:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 07:24:08 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
Message-ID: <aYZy347MIGRdklccnwK7XZSh_dIfBbhbV_mpqjh5Ups=.f6795bd9-05fb-468e-a5cd-2c6585b51af4@github.com>

On Thu, 24 Nov 2022 11:18:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to be compatible with JDK-8297030

src/java.net.http/share/classes/module-info.java line 59:

> 57:  * <li><p><b>{@systemProperty jdk.httpclient.connectionWindowSize}</b> (default: 2^26)<br>
> 58:  * The HTTP/2 client connection window size in bytes. The maximum size is 2^31-1. This value cannot be
> 59:  * smaller than the stream window size.

Should this additionally point to the `jdk.httpclient.windowsize` system property? Something like `This value cannot be smaller than the stream window size, which can be configured through {@code jdk.httpclient.windowsize} system property`?

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

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

From jpai at openjdk.org  Fri Nov 25 07:27:37 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 07:27:37 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
Message-ID: <LwK_EWVG2vFddbXMctqcmiu6Di47NMEuqyBEytfTl98=.9a7a5ff2-7d05-4024-8dd4-f1036c5b1a99@github.com>

On Thu, 24 Nov 2022 11:18:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to be compatible with JDK-8297030

src/java.net.http/share/classes/module-info.java line 136:

> 134:  * <li><p><b>{@systemProperty jdk.internal.httpclient.disableHostnameVerification}</b> (default: false)<br>
> 135:  * If true, hostname verification in SSL certificates is disabled. This is a system property only and not
> 136:  * available in {@code conf/net.properties}. It is provided for testing purposes only.

>From what I can see in the code `jdk.internal.net.http.common.Utils#hostnameVerificationDisabledValue()`, we consider an empty value for this property to imply `true`. Perhaps we should note that here?

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

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

From dfuchs at openjdk.org  Fri Nov 25 10:22:10 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 10:22:10 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert [v2]
In-Reply-To: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
Message-ID: <_CN-qwa04lG_Xczy2ebw18OyfTRcGSv_RBA9Hq5Z9fQ=.23695b67-7d05-454f-96ea-3ff1a1c23ccf@github.com>

> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
> 
> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
> 
> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.

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 AsyncExecutorShutdown-8297424
 - Revert assignement of pendingResponseSubscriber to null to avoid race conditions with ternary operators
 - 8297424

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11332/files
  - new: https://git.openjdk.org/jdk/pull/11332/files/b4e462b4..71b59be3

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

  Stats: 8939 lines in 305 files changed: 5754 ins; 2091 del; 1094 mod
  Patch: https://git.openjdk.org/jdk/pull/11332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11332/head:pull/11332

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

From dfuchs at openjdk.org  Fri Nov 25 10:22:11 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 10:22:11 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert
In-Reply-To: <loKKnh9tFrfmxoO2cWg06gB2e-0WBRCsxebsnOFNutA=.4b4c284e-aa09-42b6-b8a2-f0703d84d105@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
 <loKKnh9tFrfmxoO2cWg06gB2e-0WBRCsxebsnOFNutA=.4b4c284e-aa09-42b6-b8a2-f0703d84d105@github.com>
Message-ID: <k41vS4EZ9p674qSyj6ePS7D89BlKZrdCN5S6yrFefZQ=.3f69ad89-36e0-4e79-bd0e-923f0165285e@github.com>

On Fri, 25 Nov 2022 06:26:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This PR also has changes in the `Stream` class. Some of those changes are typo related fixes, so that's fine. However, it also has other functional changes. Is that intentional and related?

These are changes I made when investigating the fix, and they are not related. The `pendingResponseSubscriber` is a temporary field that holds the subscriber value until the `responseSubscriber` is handled and subscribed by the `schedule` loop. It is a bit confusing to see a non null `pendingResponseSubscriber` after it has been handled by that loop. Practically, setting it to `null` or leaving it assigned at this point should have no effect on the behavior of this class... Hmmm... except I see ternary operators that first look at the subscriber and then at the pending subscriber. So this change now introduce a potential race condition if they are executed concurrently with the `schedule` loop. Good observation. I will revert that.

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

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

From dfuchs at openjdk.org  Fri Nov 25 10:24:25 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 10:24:25 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v3]
In-Reply-To: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
Message-ID: <OzWm7rX9KlXPxDEEJGt1jxPW-U-reWKCSreYCHneKNU=.59b4308a-7ae4-4daa-a153-6f3b898ed442@github.com>

> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).

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

  Update test/jdk/java/net/httpclient/ReferenceTracker.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11294/files
  - new: https://git.openjdk.org/jdk/pull/11294/files/25efbd8b..8142a728

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

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

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

From duke at openjdk.org  Fri Nov 25 11:09:11 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 25 Nov 2022 11:09:11 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

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

  implemented feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11323/files
  - new: https://git.openjdk.org/jdk/pull/11323/files/0d8dd4bd..560719eb

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

  Stats: 30 lines in 2 files changed: 7 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11323.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11323/head:pull/11323

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

From dfuchs at openjdk.org  Fri Nov 25 11:34:35 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 11:34:35 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
Message-ID: <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>

On Fri, 25 Nov 2022 11:09:11 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 489:

> 487:                     } catch (IOException ignored) {
> 488:                     }
> 489:                     throw new InterruptedIOException();

Thanks for doing that. Maybe we should keep the caught InterruptedException as the cause of the new InterruptedIOException. I'd suggest to add a new utility method to the `...common.Utils` class for that. I mean - something like:

    InterruptedIOException Utils.toInterruptedIOException(InterruptedException ex);

test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 111:

> 109: 
> 110:         CountDownLatch interruptReadyLatch;
> 111:         CountDownLatch interruptDoneLatch;

should be `final`

test/jdk/java/net/httpclient/HttpResponseInputStreamInterruptTest.java line 167:

> 165:                 // countdown on latch, and assert that an IOException is throw due to the interrupt
> 166:                 interruptReadyLatch.countDown();
> 167:                 assertThrows(InterruptedIOException.class, () -> response.body().readAllBytes(), "excepted IOException");

Maybe change the message while you're at it since we're actually expecting InterruptedIOException

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

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

From michaelm at openjdk.org  Fri Nov 25 11:45:03 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 11:45:03 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <aYZy347MIGRdklccnwK7XZSh_dIfBbhbV_mpqjh5Ups=.f6795bd9-05fb-468e-a5cd-2c6585b51af4@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
 <aYZy347MIGRdklccnwK7XZSh_dIfBbhbV_mpqjh5Ups=.f6795bd9-05fb-468e-a5cd-2c6585b51af4@github.com>
Message-ID: <7JjrrZXWbF6XazpVCk_YCjJ37IHi0V7MD4LUnGXcF1Q=.e9be26ad-a25e-4998-aad7-193a891ad430@github.com>

On Fri, 25 Nov 2022 07:20:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to be compatible with JDK-8297030
>
> src/java.net.http/share/classes/module-info.java line 59:
> 
>> 57:  * <li><p><b>{@systemProperty jdk.httpclient.connectionWindowSize}</b> (default: 2^26)<br>
>> 58:  * The HTTP/2 client connection window size in bytes. The maximum size is 2^31-1. This value cannot be
>> 59:  * smaller than the stream window size.
> 
> Should this additionally point to the `jdk.httpclient.windowsize` system property? Something like `This value cannot be smaller than the stream window size, which can be configured through {@code jdk.httpclient.windowsize} system property`?

Good idea!

> src/java.net.http/share/classes/module-info.java line 84:
> 
>> 82:  *   <li>ssl</li>
>> 83:  *   <li>trace</li>
>> 84:  *   <li>channel</li>
> 
> Hello Michael, is it intentional that we haven't documented `content` in this list?

Thanks for noticing that omission Jai!

> src/java.net.http/share/classes/module-info.java line 136:
> 
>> 134:  * <li><p><b>{@systemProperty jdk.internal.httpclient.disableHostnameVerification}</b> (default: false)<br>
>> 135:  * If true, hostname verification in SSL certificates is disabled. This is a system property only and not
>> 136:  * available in {@code conf/net.properties}. It is provided for testing purposes only.
> 
> From what I can see in the code `jdk.internal.net.http.common.Utils#hostnameVerificationDisabledValue()`, we consider an empty value for this property to imply `true`. Perhaps we should note that here?

Yes, agreed!

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

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

From dfuchs at openjdk.org  Fri Nov 25 12:15:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 12:15:47 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
Message-ID: <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>

> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).

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

 - Merge branch 'master' into SpecialHeadersTest-8297200
 - Update test/jdk/java/net/httpclient/ReferenceTracker.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Fixed race condition in detecting if selector is still alive
 - 8297200
 - 8297200

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11294/files
  - new: https://git.openjdk.org/jdk/pull/11294/files/8142a728..01fab390

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

  Stats: 8937 lines in 304 files changed: 5754 ins; 2089 del; 1094 mod
  Patch: https://git.openjdk.org/jdk/pull/11294.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11294/head:pull/11294

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

From dfuchs at openjdk.org  Fri Nov 25 12:23:48 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 12:23:48 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
Message-ID: <0gwwT5pKs5owqWXFB4rH-xQpT1ALy0SsFVzR8rd0e64=.e2511cb4-47c1-48dc-bbaa-14f880fcc22e@github.com>

On Thu, 24 Nov 2022 11:18:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to be compatible with JDK-8297030

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/module-info.java line 76:

> 74:  * <li><p><b>{@systemProperty jdk.httpclient.HttpClient.log}</b> (default: none)<br>
> 75:  * Enables high-level logging of various events through the Java Logging API (which is contained in the
> 76:  * package java.util.logging). The value contains a comma-separated list of any of the following items:

java.util.logging is actually only the default backend, so I'd suggest to reword as:

 * Enables high-level logging of various events through the {@linkplain java.lang.System.Logger Platform Logging API}.
 * The value contains ...
 ```

src/java.net.http/share/classes/module-info.java line 94:

> 92:  * </ul><br>
> 93:  * Specifying an item adds it to the HTTP client's log. For example, if you specify the following value,
> 94:  * then the Java Logging API logs all possible HTTP Client events:<br>

Same here - use `Platform Logging API` rather than `Java Logging API`.

src/java.net.http/share/classes/module-info.java line 102:

> 100:  * The number of seconds to keep idle HTTP connections alive in the keep alive cache. This property
> 101:  * applies to both HTTP/1.1 and HTTP/2. The value for HTTP/2 can be overridden with the
> 102:  * jdk.httpclient.keepalive.timeout.h2 property.

`{@code jdk.httpclient.keepalive.timeout.h2}` ?

src/java.net.http/share/classes/module-info.java line 106:

> 104:  * <li><p><b>{@systemProperty jdk.httpclient.keepalive.timeout.h2}</b> (default: see below)<br>
> 105:  * The number of seconds to keep idle HTTP/2 connections alive. If not set, then the
> 106:  * jdk.httpclient.keepalive.timeout setting is used.

`{@code jdk.httpclient.keepalive.timeout}` ?

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

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

From duke at openjdk.org  Fri Nov 25 13:20:52 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Fri, 25 Nov 2022 13:20:52 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file extension
Message-ID: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>

This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.

# How to reproduce

You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...

## Sources

`main.c`:

#include <stdio.h>

int main() {
  printf("Hello browser debug console...\n");
}


`Server.java`:

import com.sun.net.httpserver.HttpServer;
import com.sun.net.httpserver.SimpleFileServer;

import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.nio.file.Path;

import static java.lang.System.exit;
import static java.lang.System.out;

public class Server {
    public static void main(String... args) {
        if (args.length != 2) {
            out.println("Usage: java Server <port> <web dir path>");
            exit(1);
        }
        final int port = Integer.parseInt(args[0]);
        final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
        final Path root = Path.of(args[1]).toAbsolutePath();
        final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
        out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
        server.start();
    }
}

## Build

$ mkdir out
$ emcc main.c -s WASM=1 -o out/main.html
$ ls out/
main.html  main.js  main.wasm

You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)

## Execution

$ java --version
openjdk 19.0.1 2022-10-18
$ javac Server.java
$ java Server 8888 ./out/
Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888


When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:

![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)

When I switch to the JDK patched with this patch and run the server again:

$ java Server 8888 ./out/
Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888

I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:

![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)

Thank you for your time.

Cheers
K.

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

Commit messages:
 - Adds missing MIME application/wasm

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

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

From duke at openjdk.org  Fri Nov 25 13:20:53 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Fri, 25 Nov 2022 13:20:53 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
Message-ID: <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>

On Tue, 22 Nov 2022 10:43:42 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
> 
> # How to reproduce
> 
> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
> 
> ## Sources
> 
> `main.c`:
> 
> #include <stdio.h>
> 
> int main() {
>   printf("Hello browser debug console...\n");
> }
> 
> 
> `Server.java`:
> 
> import com.sun.net.httpserver.HttpServer;
> import com.sun.net.httpserver.SimpleFileServer;
> 
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.nio.file.Path;
> 
> import static java.lang.System.exit;
> import static java.lang.System.out;
> 
> public class Server {
>     public static void main(String... args) {
>         if (args.length != 2) {
>             out.println("Usage: java Server <port> <web dir path>");
>             exit(1);
>         }
>         final int port = Integer.parseInt(args[0]);
>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>         final Path root = Path.of(args[1]).toAbsolutePath();
>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>         server.start();
>     }
> }
> 
> ## Build
> 
> $ mkdir out
> $ emcc main.c -s WASM=1 -o out/main.html
> $ ls out/
> main.html  main.js  main.wasm
> 
> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
> 
> ## Execution
> 
> $ java --version
> openjdk 19.0.1 2022-10-18
> $ javac Server.java
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> 
> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
> 
> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
> 
> When I switch to the JDK patched with this patch and run the server again:
> 
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
> 
> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
> 
> Thank you for your time.
> 
> Cheers
> K.

@jerboaa Do you think I can go ahead and open PRs for 11u and 17u or the process is to wait for what happens with this one?

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

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

From sgehwolf at openjdk.org  Fri Nov 25 13:20:53 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 25 Nov 2022 13:20:53 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
Message-ID: <o_qo0pcnU_13N0ZpIXa5btZM2oDPsKh9qO_k843YbuY=.e16d3016-a9e1-4050-adb3-ba15dcc175a2@github.com>

On Tue, 22 Nov 2022 14:54:37 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

> @jerboaa Do you think I can go ahead and open PRs for 11u and 17u or the process is to wait for what happens with this one?

Yes, it's better to have it integrated in mainline before moving on to older releases.

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

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

From jpai at openjdk.org  Fri Nov 25 13:20:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Nov 2022 13:20:54 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
Message-ID: <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>

On Tue, 22 Nov 2022 14:54:37 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> @jerboaa Do you think I can go ahead and open PRs for 11u and 17u or the process is to wait for what happens with this one?

Hello @Karm, to officially initiate a review of this change, the review process (backed by bots) requires a JBS issue to be created and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297609 to track this.

Next, you will have to update the title of this PR to `8297609: Add application/wasm MIME type for wasm file extension` to link this PR against that issue. That will then initiate the necessary review process.

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

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

From duke at openjdk.org  Fri Nov 25 13:26:55 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Fri, 25 Nov 2022 13:26:55 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
 <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
Message-ID: <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>

On Fri, 25 Nov 2022 06:41:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @jerboaa Do you think I can go ahead and open PRs for 11u and 17u or the process is to wait for what happens with this one?
>
> Hello @Karm, to officially initiate a review of this change, the review process (backed by bots) requires a JBS issue to be created and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297609 to track this.
> 
> Next, you will have to update the title of this PR to `8297609: Add application/wasm MIME type for wasm file extension` to link this PR against that issue. That will then initiate the necessary review process.

@jaikiran Thanks.

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

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

From michaelm at openjdk.org  Fri Nov 25 13:30:21 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 13:30:21 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v7]
In-Reply-To: <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <lptPGKkREhKh208bOotzM4_vCiPcseWmajpW9cOcSjE=.387147e3-3562-443a-8aaf-8643b1d9c9c7@github.com>
Message-ID: <b101JiMGcrPY5_UGgihluvoKWW5zAvLyX7x4WATHEW0=.9a0c0d69-5425-4a9a-ac6b-fc5e76b49126@github.com>

On Thu, 24 Nov 2022 11:18:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to be compatible with JDK-8297030

Will push an update including the comments above and then a further update with just reformatting changes.

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

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

From michaelm at openjdk.org  Fri Nov 25 13:37:36 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 13:37:36 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v8]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <vWkMdgx79KWT6AgoGPQYwPeUOomGR2ILWmYnN63t1FU=.06f0a338-364d-4a9e-b472-ffaf7383f5d6@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/55380083..dcdefafe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11241&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11241&range=06-07

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

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

From michaelm at openjdk.org  Fri Nov 25 13:52:30 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 13:52:30 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v9]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <6WXXFMqR1GdKzzGcbl6TsFWstrGQMXap5Xu7LUx-IwQ=.21f74b78-b654-4ed9-a0b9-08907ee7422f@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

 - reformatting change only
 - Merge branch 'master' into http.properties
 - update after comments
 - update to be compatible with JDK-8297030
 - update to SSL cert check property
 - removed trailing whitespace
 - update after review round 2
 - Merge branch 'master' into http.properties
 - update after Daniel's review
 - first draft

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/dcdefafe..7fda2666

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11241&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11241&range=07-08

  Stats: 24737 lines in 395 files changed: 10965 ins; 4485 del; 9287 mod
  Patch: https://git.openjdk.org/jdk/pull/11241.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11241/head:pull/11241

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

From michaelm at openjdk.org  Fri Nov 25 13:56:09 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 13:56:09 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v8]
In-Reply-To: <vWkMdgx79KWT6AgoGPQYwPeUOomGR2ILWmYnN63t1FU=.06f0a338-364d-4a9e-b472-ffaf7383f5d6@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <vWkMdgx79KWT6AgoGPQYwPeUOomGR2ILWmYnN63t1FU=.06f0a338-364d-4a9e-b472-ffaf7383f5d6@github.com>
Message-ID: <YLInNJWe-M-rHnLke5BCqPrkQIJTpZJqPrrXbqeleLc=.d094d83c-d64b-4f7b-8b87-769c7578eb54@github.com>

On Fri, 25 Nov 2022 13:37:36 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after comments

CSR updated now.

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

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

From dfuchs at openjdk.org  Fri Nov 25 14:31:49 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 14:31:49 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v8]
In-Reply-To: <vWkMdgx79KWT6AgoGPQYwPeUOomGR2ILWmYnN63t1FU=.06f0a338-364d-4a9e-b472-ffaf7383f5d6@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <vWkMdgx79KWT6AgoGPQYwPeUOomGR2ILWmYnN63t1FU=.06f0a338-364d-4a9e-b472-ffaf7383f5d6@github.com>
Message-ID: <hCgB0UlLKhvXyY_E00QYqkdT5rdjk9Nle9JwLApg7mU=.df06dab2-76c0-446a-a6e3-675e94f6b1a6@github.com>

On Fri, 25 Nov 2022 13:37:36 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after comments

src/java.net.http/share/classes/module-info.java line 76:

> 74:  * </li>
> 75:  * <li><p><b>{@systemProperty jdk.httpclient.HttpClient.log}</b> (default: none)<br>
> 76:  * Enables high-level logging of various events through the {@link java.lang.System.Logger Platform Logging

Should be `{@linkplain }` otherwise the text will be in fixed font.

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

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

From michaelm at openjdk.org  Fri Nov 25 15:43:39 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Nov 2022 15:43:39 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v10]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <vs5xlWlqyeZUdGFF4n8dMbjaLXaofSpwF7Oc6rZlANw=.37dd1053-0422-4ed5-a90b-32c26cd73b2d@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  changed link to linkplain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/7fda2666..608239ce

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

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

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

From dfuchs at openjdk.org  Fri Nov 25 15:55:12 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 15:55:12 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v10]
In-Reply-To: <vs5xlWlqyeZUdGFF4n8dMbjaLXaofSpwF7Oc6rZlANw=.37dd1053-0422-4ed5-a90b-32c26cd73b2d@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <vs5xlWlqyeZUdGFF4n8dMbjaLXaofSpwF7Oc6rZlANw=.37dd1053-0422-4ed5-a90b-32c26cd73b2d@github.com>
Message-ID: <8iIazgNh7hj1G09Xsumyi3B-Z8V3ltu2X9vUQXJsIww=.6f692491-3c91-41f7-82a4-119f359e10aa@github.com>

On Fri, 25 Nov 2022 15:43:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed link to linkplain

Marked as reviewed by dfuchs (Reviewer).

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

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

From duke at openjdk.org  Fri Nov 25 16:10:11 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 25 Nov 2022 16:10:11 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
 <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>
Message-ID: <ejcZFALRqrgjIEbNLi9txuHsaCCigG7bwxQkN_WCKa8=.9b96da97-8a30-4dbd-89a6-2a2de5a4a0b6@github.com>

On Fri, 25 Nov 2022 11:28:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implemented feedback
>
> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 489:
> 
>> 487:                     } catch (IOException ignored) {
>> 488:                     }
>> 489:                     throw new InterruptedIOException();
> 
> Thanks for doing that. Maybe we should keep the caught InterruptedException as the cause of the new InterruptedIOException. I'd suggest to add a new utility method to the `...common.Utils` class for that. I mean - something like:
> 
>     InterruptedIOException Utils.toInterruptedIOException(InterruptedException ex);

So  something in utils like `return new InterruptedIOException(String.valueOf(exxeption));` ?

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

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

From dfuchs at openjdk.org  Fri Nov 25 16:15:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 16:15:21 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <ejcZFALRqrgjIEbNLi9txuHsaCCigG7bwxQkN_WCKa8=.9b96da97-8a30-4dbd-89a6-2a2de5a4a0b6@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
 <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>
 <ejcZFALRqrgjIEbNLi9txuHsaCCigG7bwxQkN_WCKa8=.9b96da97-8a30-4dbd-89a6-2a2de5a4a0b6@github.com>
Message-ID: <M-q1l0tqTH946b1OD0Cgh1ni5X3vh0wevVmEWysG1bM=.40b575b9-f65a-4f22-a477-81c309d34f54@github.com>

On Fri, 25 Nov 2022 16:07:47 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 489:
>> 
>>> 487:                     } catch (IOException ignored) {
>>> 488:                     }
>>> 489:                     throw new InterruptedIOException();
>> 
>> Thanks for doing that. Maybe we should keep the caught InterruptedException as the cause of the new InterruptedIOException. I'd suggest to add a new utility method to the `...common.Utils` class for that. I mean - something like:
>> 
>>     InterruptedIOException Utils.toInterruptedIOException(InterruptedException ex);
>
> So  something in utils like `return new InterruptedIOException(String.valueOf(exxeption));` ?

No something that would call `initCause(ex)` to set the root cause - as AFAICS there's no constructor that takes a root cause.

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

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

From duke at openjdk.org  Fri Nov 25 16:44:18 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 25 Nov 2022 16:44:18 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <M-q1l0tqTH946b1OD0Cgh1ni5X3vh0wevVmEWysG1bM=.40b575b9-f65a-4f22-a477-81c309d34f54@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
 <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>
 <ejcZFALRqrgjIEbNLi9txuHsaCCigG7bwxQkN_WCKa8=.9b96da97-8a30-4dbd-89a6-2a2de5a4a0b6@github.com>
 <M-q1l0tqTH946b1OD0Cgh1ni5X3vh0wevVmEWysG1bM=.40b575b9-f65a-4f22-a477-81c309d34f54@github.com>
Message-ID: <Uxnw5uYQG0SsZ9_6zGvh3BybJYs9sQRcx_yGZTCkmCU=.dabf3bd2-582a-4578-ad7b-e6fc7509d9ed@github.com>

On Fri, 25 Nov 2022 16:13:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> So  something in utils like `return new InterruptedIOException(String.valueOf(exxeption));` ?
>
> No something that would call `initCause(ex)` to set the root cause - as AFAICS there's no constructor that takes a root cause.

ah ok, so create a new `InterruptedIOException` and set the initcause to be the `interruptedException`.
is there anything else that would need to be set?

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

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

From dfuchs at openjdk.org  Fri Nov 25 17:11:17 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Nov 2022 17:11:17 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v2]
In-Reply-To: <Uxnw5uYQG0SsZ9_6zGvh3BybJYs9sQRcx_yGZTCkmCU=.dabf3bd2-582a-4578-ad7b-e6fc7509d9ed@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <07GdVCOAWu1C6M8uPaweO_ePOZGNf4O8qn-ZF9sQd0w=.e44e96f2-5a55-4df8-9358-7d9eff95d8f6@github.com>
 <48Hpexr-BHIVt8sjPfFnr33hIilRHikDRyOi5XEIH6A=.82317870-e1b0-4e6c-9b67-ad1b030dc744@github.com>
 <ejcZFALRqrgjIEbNLi9txuHsaCCigG7bwxQkN_WCKa8=.9b96da97-8a30-4dbd-89a6-2a2de5a4a0b6@github.com>
 <M-q1l0tqTH946b1OD0Cgh1ni5X3vh0wevVmEWysG1bM=.40b575b9-f65a-4f22-a477-81c309d34f54@github.com>
 <Uxnw5uYQG0SsZ9_6zGvh3BybJYs9sQRcx_yGZTCkmCU=.dabf3bd2-582a-4578-ad7b-e6fc7509d9ed@github.com>
Message-ID: <pgLs1t7ZFEMRNNsuDMJH6tKaVbC1iBbb_3LHQRaow5g=.86e51070-8987-4d83-8b8a-89b3310088e7@github.com>

On Fri, 25 Nov 2022 16:41:35 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> No something that would call `initCause(ex)` to set the root cause - as AFAICS there's no constructor that takes a root cause.
>
> ah ok, so create a new `InterruptedIOException` and set the initcause to be the `interruptedException`.
> is there anything else that would need to be set?

preserving the root cause is the main thing.

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

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

From jpai at openjdk.org  Sat Nov 26 01:42:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Nov 2022 01:42:11 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v10]
In-Reply-To: <vs5xlWlqyeZUdGFF4n8dMbjaLXaofSpwF7Oc6rZlANw=.37dd1053-0422-4ed5-a90b-32c26cd73b2d@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <vs5xlWlqyeZUdGFF4n8dMbjaLXaofSpwF7Oc6rZlANw=.37dd1053-0422-4ed5-a90b-32c26cd73b2d@github.com>
Message-ID: <srV2PrHLTQTOZBtWvfXLayniJw13pPYqFB3yTGFSAgc=.13165c08-782b-4b8c-90d6-0d29ecf3e88f@github.com>

On Fri, 25 Nov 2022 15:43:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed link to linkplain

Thank you Michael for these changes. These look fine to me. One final thing - I just noticed that the file will need a copyright year update.

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

Marked as reviewed by jpai (Reviewer).

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

From alanb at openjdk.org  Sun Nov 27 16:59:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 16:59:51 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Z2mQfsenB-2TKri8E4p_2REW20k6KEl4yy4TQnGBVvA=.e8d51dc4-afcf-4ef5-9e5a-d575db38bb49@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

The latest version (30aff118) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP  434 integrated or soon afterwards?

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

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

From alanb at openjdk.org  Sun Nov 27 17:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 17:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Pc74reEYC1KV1FK_32D_pMa_9tlnJhMaBtZbLupg59w=.c7c124e1-01e1-4579-942b-f7698aee0eb6@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

src/java.base/share/classes/java/util/zip/Deflater.java line 594:

> 592:                     try {
> 593:                         result = deflateBufferBytes(zsRef.address(),
> 594:                                 ((DirectBuffer) input).address() + inputPos, inputRem,

Somewhat subjective but the original code, with inputAddress, was a easier to read and avoided having too much going on in the parameters to deflateBufferBytes. In any case, you probably should fix the formatting to avoid have different parameters with different indentations.

src/java.base/share/classes/java/util/zip/Deflater.java line 717:

> 715:                         result = deflateBytesBuffer(zsRef.address(),
> 716:                             inputArray, inputPos, inputLim - inputPos,
> 717:                                 ((DirectBuffer) output).address() + outputPos, outputRem,

Same here, I think I would keep outputAddress to keep the call to deflateByteBuffer simple.

src/java.base/share/classes/java/util/zip/Deflater.java line 740:

> 738:                             try {
> 739:                                 result = deflateBufferBuffer(zsRef.address(),
> 740:                                     ((DirectBuffer) input).address() + inputPos, inputRem,

Another one where inputAddress and outputAddress have been removed so the call to deflatBufferBuffer is much hard to digest.

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

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

From mernst at openjdk.org  Sun Nov 27 17:53:30 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 27 Nov 2022 17:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.

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

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

From pminborg at openjdk.org  Mon Nov 28 08:38:55 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 08:38:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <lbi3L0o3TxVCaymOyYjKQ5BgYf3qrYkgwaYn0FcDX3Q=.1120c1d3-0375-48bd-af6f-4d6495ff6d86@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

> The latest version ([30aff11](https://github.com/openjdk/jdk/commit/30aff1187d4978c59d1e6feebafc2d45aba3e5f2)) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP 434 integrated or soon afterwards?

The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (*Session* -> *Scope*) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

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

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

From jpai at openjdk.org  Mon Nov 28 09:02:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:02:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
Message-ID: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>

On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.

I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

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

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

From jpai at openjdk.org  Mon Nov 28 09:07:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:07:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>

Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.

I'll raise separate PRs in the other remaining areas from that other PR.

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

Commit messages:
 - 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

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

From alanb at openjdk.org  Mon Nov 28 09:13:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:13:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <wvex0wjU2GnSsQ0xKXEHiZTVjMSeNGcGIG0BOHUJJtw=.93cd0d8d-cbea-4948-b439-d9049ad6e2e2@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Mon Nov 28 09:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:56:14 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:

> 65:    * to generate elements type your Subscriber is able to consume.
> 66:    * <p>
> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber

The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

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

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

From jpai at openjdk.org  Mon Nov 28 10:02:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:47 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

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

  Address review comment - don't change WithHelperPublisher.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11385/files
  - new: https://git.openjdk.org/jdk/pull/11385/files/85669caf..37a51582

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

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

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

From jpai at openjdk.org  Mon Nov 28 10:02:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:50 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
Message-ID: <GjK3gjMVUR8FxMELtrWBgSirJ-SDQR1mxc-UbzQ6GNs=.5bf874ca-47e8-4609-acab-bceae129bb49@github.com>

On Mon, 28 Nov 2022 09:54:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment - don't change WithHelperPublisher.java
>
> test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:
> 
>> 65:    * to generate elements type your Subscriber is able to consume.
>> 66:    * <p>
>> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber
> 
> The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

Hello Alan, I have now updated this PR to remove changes to this file.

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

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

From michaelm at openjdk.org  Mon Nov 28 10:36:29 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 28 Nov 2022 10:36:29 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v11]
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <UdMesD3fIzwVFJGyOZO0vXEvqPEnMJWOHNRrGqMF4fc=.4f532c5c-d509-4ae7-99fe-496f1cb8a00a@github.com>

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

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

  copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11241/files
  - new: https://git.openjdk.org/jdk/pull/11241/files/608239ce..cd2efa07

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

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

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

From jpai at openjdk.org  Mon Nov 28 10:36:29 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:36:29 GMT
Subject: RFR: 8296804: Document HttpClient configuration properties in
 java.net.http module-info [v11]
In-Reply-To: <UdMesD3fIzwVFJGyOZO0vXEvqPEnMJWOHNRrGqMF4fc=.4f532c5c-d509-4ae7-99fe-496f1cb8a00a@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
 <UdMesD3fIzwVFJGyOZO0vXEvqPEnMJWOHNRrGqMF4fc=.4f532c5c-d509-4ae7-99fe-496f1cb8a00a@github.com>
Message-ID: <S0DuxYQS3fh7wGWOTlH6eZhkCy_CMMCRbQDZ6liFUF0=.5fe45d8e-6488-47b6-9784-fccb7bde2be0@github.com>

On Mon, 28 Nov 2022 10:33:19 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright update

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11241

From pminborg at openjdk.org  Mon Nov 28 10:36:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:36:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Re-introduce address variables

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/30aff118..95c40581

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13-14

  Stats: 24 lines in 2 files changed: 11 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From jpai at openjdk.org  Mon Nov 28 10:39:30 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:39:30 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert [v2]
In-Reply-To: <_CN-qwa04lG_Xczy2ebw18OyfTRcGSv_RBA9Hq5Z9fQ=.23695b67-7d05-454f-96ea-3ff1a1c23ccf@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
 <_CN-qwa04lG_Xczy2ebw18OyfTRcGSv_RBA9Hq5Z9fQ=.23695b67-7d05-454f-96ea-3ff1a1c23ccf@github.com>
Message-ID: <Y5C1luACXyNXppSMKibZYsp86bt1bMJ3n_Of2VJml6g=.b792e3bb-367c-4772-854e-61d61e1f9877@github.com>

On Fri, 25 Nov 2022 10:22:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
>> 
>> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
>> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
>> 
>> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.
>
> 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 AsyncExecutorShutdown-8297424
>  - Revert assignement of pendingResponseSubscriber to null to avoid race conditions with ternary operators
>  - 8297424

Thank you Daniel. The latest changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11332

From alanb at openjdk.org  Mon Nov 28 10:40:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 10:40:11 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
Message-ID: <PhLwZqHpoyEWcne_UFcklZ4_Jz-gMRjYM4DId_9_YJ8=.602fe5db-c3d0-4513-843d-1c51c5574ac7@github.com>

On Mon, 28 Nov 2022 10:36:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce address variables

> The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (_Session_ -> _Scope_) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

Whatever is easiest. Given the fork for JDK 20 is coming up soon then it would be good to get the rename done soon after JEP 434 integrates, just to avoid JDK 20 having the mix of names.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Mon Nov 28 10:47:47 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:47:47 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Re-introduce yet another address vairable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/95c40581..eedf41ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14-15

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From lancea at openjdk.org  Mon Nov 28 11:29:09 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Nov 2022 11:29:09 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <Llh9tEhkVodoFQQR2a5Y3RS11724tea047BLBNjKXBo=.9c80845e-9d21-47bf-afce-49ed2e43c855@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From duke at openjdk.org  Mon Nov 28 13:18:40 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 28 Nov 2022 13:18:40 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v3]
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <otp4xtO-qkqQKuVVsw4cwsIdeuEoCC8N4xJxLEEKeAs=.7d2188fd-ecc7-4e79-9d3c-a85e5f1f2dfa@github.com>

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  set initCause for InterruptedIOException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11323/files
  - new: https://git.openjdk.org/jdk/pull/11323/files/560719eb..928176ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11323&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11323&range=01-02

  Stats: 12 lines in 3 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11323.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11323/head:pull/11323

PR: https://git.openjdk.org/jdk/pull/11323

From dfuchs at openjdk.org  Mon Nov 28 14:09:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:09:59 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert [v3]
In-Reply-To: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
Message-ID: <BL7MdDMuijbUZR9Rby3g8w3SIDLUJQ092zfRKm3nswE=.e3f0e701-ae47-490a-9f85-a6465cff0db9@github.com>

> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
> 
> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
> 
> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.

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 four additional commits since the last revision:

 - Merge branch 'master' into AsyncExecutorShutdown-8297424
 - Merge branch 'master' into AsyncExecutorShutdown-8297424
 - Revert assignement of pendingResponseSubscriber to null to avoid race conditions with ternary operators
 - 8297424

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11332/files
  - new: https://git.openjdk.org/jdk/pull/11332/files/71b59be3..33972211

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11332&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11332&range=01-02

  Stats: 4499 lines in 106 files changed: 3466 ins; 609 del; 424 mod
  Patch: https://git.openjdk.org/jdk/pull/11332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11332/head:pull/11332

PR: https://git.openjdk.org/jdk/pull/11332

From alanb at openjdk.org  Mon Nov 28 14:12:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 14:12:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <8-MFynuwsRGfpV5mqTvonYTwphy5h1Jzs0CO31Og-wQ=.1ec9c4d4-d7dd-4dd6-96de-d6aa60d89930@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From dfuchs at openjdk.org  Mon Nov 28 14:13:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:13:40 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v3]
In-Reply-To: <otp4xtO-qkqQKuVVsw4cwsIdeuEoCC8N4xJxLEEKeAs=.7d2188fd-ecc7-4e79-9d3c-a85e5f1f2dfa@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <otp4xtO-qkqQKuVVsw4cwsIdeuEoCC8N4xJxLEEKeAs=.7d2188fd-ecc7-4e79-9d3c-a85e5f1f2dfa@github.com>
Message-ID: <oO7oSK90lnqddIxjcBwsJRh2EXOsCOrxViYqpa0pf_A=.5644c20b-7dd3-4bee-a64b-dc99737420f0@github.com>

On Mon, 28 Nov 2022 13:18:40 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set initCause for InterruptedIOException

src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 489:

> 487:                     } catch (IOException ignored) {
> 488:                     }
> 489:                     // Throw InterruptedIOException where the initCause is set to the caught InterruptedException

nit: could you break this long line after "is"

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1141:

> 1139:         interruptedIOException.initCause(ex);
> 1140:         return interruptedIOException;
> 1141:     }

The copyright years need updating.

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From duke at openjdk.org  Mon Nov 28 14:21:01 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 28 Nov 2022 14:21:01 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
Message-ID: <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>

> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
> 
> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  fixed copyright year and formatting of a comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11323/files
  - new: https://git.openjdk.org/jdk/pull/11323/files/928176ac..83ff9c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11323&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11323&range=02-03

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11323.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11323/head:pull/11323

PR: https://git.openjdk.org/jdk/pull/11323

From dfuchs at openjdk.org  Mon Nov 28 14:27:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:27:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <6IgwmfUT8rOETK23hGf9t27oV1vdSLUUNr7QOvsmjII=.aa65f8e7-8c7a-4d3f-aa69-ef899725bcb4@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From dfuchs at openjdk.org  Mon Nov 28 14:27:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:27:37 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
Message-ID: <QjQJUM77HDUFeu_Lj8K3wl4fbAj3oUl1gesnXufk_SA=.a0e28f39-9518-4854-a650-52b6b8da2090@github.com>

On Mon, 28 Nov 2022 14:21:01 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright year and formatting of a comment

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From mcimadamore at openjdk.org  Mon Nov 28 15:00:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Nov 2022 15:00:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
 <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
Message-ID: <DPv9DAmeB5tuC5ax2uEHDxtJbGvuNsn_9ZywyI6Q9Cg=.f8b48d3b-4c1b-4d0d-b5e6-e4240e67c5c8@github.com>

On Mon, 21 Nov 2022 12:05:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.
>
> I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

> Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.


IMHO the renaming is not super important - the underlying abstraction managing the segment lifetime is still called MemorySession, even after https://git.openjdk.org/jdk/pull/10872. And, acquire/release are methods on MemorySession - so I think the current name might be more precise even after we integrate the latest API changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From jpai at openjdk.org  Mon Nov 28 15:09:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 15:09:38 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
Message-ID: <mm5vE-UtV8XM2x_ihvMyx_dVu_fWHp3zirxLfU-HcL0=.8aea7ebd-3ba8-4f37-8e21-0706bba53645@github.com>

On Fri, 25 Nov 2022 12:15:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

test/jdk/java/net/httpclient/SpecialHeadersTest.java line 379:

> 377:                     if (error != null) {
> 378:                         if (thrown != null) error.addSuppressed(thrown);
> 379:                         throw error;

If I am reading this code correctly, I think, we might end up losing (and not propagating) the original `thrown` if `error == null`. i.e. we might end up marking a test as passed even when an exception was thrown (and there were no more references left of the client). Perhaps add a else block:


if (error != null) {
  ...
} else if (thrown != null) {
   throw thrown;
}


Similar comment for the other places in this PR where this construct is being changed.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From jpai at openjdk.org  Mon Nov 28 15:15:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 15:15:02 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
Message-ID: <0NR7YwAPGVDfkUADrTUmkRL_9pLWoQqTXh8-FTmp3Pw=.9f0d257b-b1da-42c7-8c02-46f16d223447@github.com>

On Fri, 25 Nov 2022 12:15:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

test/jdk/java/net/httpclient/SpecialHeadersTest.java line 478:

> 476:                 if (!sameClient || client == null) {
> 477:                     client = newHttpClient("testAsync", sameClient);
> 478:                     tracker = TRACKER.getTracker(client);

Should this be outside this `if` block? Otherwise, in its current form, I think this `tracker` can be `null` and then later in this test where we do `TRACKER.check(tracker, ...)`, I believe it will lead to an NPE inside the `check` implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From jpai at openjdk.org  Mon Nov 28 15:52:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 15:52:21 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
Message-ID: <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>

On Fri, 25 Nov 2022 12:15:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

Hello Daniel, I've been looking at this proposed change, the current test and the failure logs that I have access to. The changes being proposed here at a high level are as follows:

1. Keeping track of whether or not the selector thread was started successfully (through `Thread.start()` call). Using that information to (only) decide whether a selector is active or not in reference tracking implementation.
2. Cleaning up the (internal) implementation of the (test code) `ReferenceTracker`
3. Updating the test to check for references per client tracker instead of all trackers.

Doing `#2` and `#3` changes I think are fine (I added some review comments for those but those can be addressed in a straightforward way).

`#1` is where I am having more and more questions. But before I get to those, I was looking at the test log run that failed and I couldn't find any crucial debug logs that our HttpClient generates. That would have given some hint on whether or not the selector manager thread shutdown was initiated. Looks like the `SpecialHeadersTest` doesn't set the `jdk.internal.httpclient.debug`. That also means that our logic in the `beforeMethod` to stop on first failure ended up being a no-op. Perhaps we should add that system property and wait for some runs to fail to capture the necessary details?

Coming to the failing `testHomeMadeIllegalHeader` test - this test issue a request whose `HttpRequest` instance is of a custom class and includes a disallowed request header. The test then calls `client.send(req, BodyHandlers.ofString());` and expects that to fail with a `IllegalArgumentException`. And looking at the logs, it does fail with this exception. We then set the `client = null`, run a GC and waits for 500 millis for all references and operations to finish. But apparently this test fails because the selector manager is still alive. The selector manager can only be alive if the facade is non-null (it is null from the logs) or pending operation count is more than 0. In this specific test the pending operation count will always be 0 since the request failed very early in the `send` operation and we never increment the pending operation count at that time. So that means that the selector manager thread would have been woken up and it would have started the shutdown process. The 
 `shutdown` process in the selector manager can be expensive since it closes all connections, but in this specific test there should be no connections at all since the request generation itself fails very early. So perhaps that means the selector manager thread has just started (and marked itself as alive) but hasn't yet reached the `selector.select` statement when the tracker checked if it was alive? Looking at the code that seems possible and perhaps explains why shortly later the tracker in its logging noted that the selector manager is no longer alive. This would then mean that the tracker is (and will always?) be inherently racy, isn't it?

Coming to the part `#1` change - so it appears that we now maintain a state if the selector manager thread doesn't start (i.e. fails in the rare case where `Thread.start()` throws Exception). We consider the selector manager to be alive in such cases. But this "aliveness" is only used for reference tracking. I think, if the selector manager thread has failed to start, that would mean the `HttpClient` instance cannot function, isn't it? But as far as I can see it wouldn't start throwing up errors but would silently accumulate requests (I'm using the term `requests` loosely here, but I mean the internal `AsyncEvent` instances). Did I read the code correctly? If so, should we be somehow propagating this thread start failure as actual exceptions whenever requests are issued?

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From jpai at openjdk.org  Mon Nov 28 15:58:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 15:58:17 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <0NR7YwAPGVDfkUADrTUmkRL_9pLWoQqTXh8-FTmp3Pw=.9f0d257b-b1da-42c7-8c02-46f16d223447@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <0NR7YwAPGVDfkUADrTUmkRL_9pLWoQqTXh8-FTmp3Pw=.9f0d257b-b1da-42c7-8c02-46f16d223447@github.com>
Message-ID: <y0G7moiuoGrMIaadIUloqa_IKzdipeBlBWiHg1_w1Ds=.59838829-a100-4f22-87f3-01ba43b2bdfd@github.com>

On Mon, 28 Nov 2022 15:11:22 GMT, Jaikiran Pai <jpai 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into SpecialHeadersTest-8297200
>>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Fixed race condition in detecting if selector is still alive
>>  - 8297200
>>  - 8297200
>
> test/jdk/java/net/httpclient/SpecialHeadersTest.java line 478:
> 
>> 476:                 if (!sameClient || client == null) {
>> 477:                     client = newHttpClient("testAsync", sameClient);
>> 478:                     tracker = TRACKER.getTracker(client);
> 
> Should this be outside this `if` block? Otherwise, in its current form, I think this `tracker` can be `null` and then later in this test where we do `TRACKER.check(tracker, ...)`, I believe it will lead to an NPE inside the `check` implementation.

Please disregard this comment. I took a more closer look and what you have here is fine, since we only call the `TRACKER.check(tracker,...)` when `sameClient = false` in which case this above `if` block would already have set the `tracker`.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Mon Nov 28 16:45:00 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 16:45:00 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
Message-ID: <e5gZkFnwni1NgGgUo_2CZ_4LWZszV2bNUbCmH6c-mPc=.8b674ac2-52a4-4ae4-a27c-e57deea87cc0@github.com>

On Mon, 28 Nov 2022 15:47:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> `#1` is where I am having more and more questions. But before I get to those, I was looking at the test log run that failed and I couldn't find any crucial debug logs that our HttpClient generates. That would have given some hint on whether or not the selector manager thread shutdown was initiated. Looks like the `SpecialHeadersTest` doesn't set the `jdk.internal.httpclient.debug`. That also means that our logic in the `beforeMethod` to stop on first failure ended up being a no-op. Perhaps we should add that system property and wait for some runs to fail to capture the necessary details?

What I could see from the log - and that was enough to understand the issue, is that the test observed "alive" being false, so decided that it didn't need to wait, then immediately after saw "alive" being true - and handled that is if alive was observed after the timeout had expired - when it had waited 0ms for the thread to shutdown. This is what this fix is fixing. We must wait until the thread has started, and has shut down, or the timeout has expired. We should stop waiting after the thread has exited, but keep on waiting until it has started & shutdown (unless Thread::start itself failed). That latter is not a condition I have ever observed - so the catch around selmgr::start is 'just' to keep things consistent.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Mon Nov 28 16:49:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 16:49:46 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
Message-ID: <C5Nz3H5rdNEO9hXGhAv4jai-S7gRuIP2L3qGAtfMRIQ=.2c2c49d1-3cf1-456e-bc00-566d938a903f@github.com>

On Mon, 28 Nov 2022 15:47:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So perhaps that means the selector manager thread has just started (and marked itself as alive) but hasn't yet reached the `selector.select` statement when the tracker checked if it was alive? Looking at the code that seems possible and perhaps explains why shortly later the tracker in its logging noted that the selector manager is no longer alive. This would then mean that the tracker is (and will always?) be inherently racy, isn't it?

See explanation above: when we started the wait loop, the thread had not started yet, so the tracker believed it had already exited, and stopped waiting. But before the checks were performed, the thread had started and isAlive was true, which caused the assertion error: the test was no longer waiting for shutdown at this point - it had already exited the waiting loop without waiting. Adding timeout debug in the reference tracker is what allowed me to understand the issue, as I could see that the reference tracker had not waited at all, and the timeout had not been honored.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Mon Nov 28 16:56:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 16:56:31 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
Message-ID: <MzyORmlPMKlLt-ghfg1ZnMBRSxhniPp6EjToXvDYHco=.96b63c13-6d5d-49a4-94cd-40ceadc656e9@github.com>

On Mon, 28 Nov 2022 15:47:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Coming to the part `#1` change - so it appears that we now maintain a state if the selector manager thread doesn't start (i.e. fails in the rare case where `Thread.start()` throws Exception). We consider the selector manager to be alive in such cases. But this "aliveness" is only used for reference tracking. I think, if the selector manager thread has failed to start, that would mean the `HttpClient` instance cannot function, isn't it? But as far as I can see it wouldn't start throwing up errors but would silently accumulate requests (I'm using the term `requests` loosely here, but I mean the internal `AsyncEvent` instances). Did I read the code correctly? If so, should we be somehow propagating this thread start failure as actual exceptions whenever requests are issued?

We don't consider the thread to be alive in this case, but we will consider that it has started. The combination started=true and alive=false means that it has finished running (in this degenerative case it has never run - as if run() had been a no-op)

start() is called from within the HttpClientImpl constructor, so if Thread::start fails I don't think it will be possible to get such a client - since the constructor will throw.  So it doesn't matter much anyway.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Mon Nov 28 17:57:52 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 17:57:52 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v5]
In-Reply-To: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
Message-ID: <n6elTxWCdgc4OJkHBvBKYJHu4LerMxFKq24rphYNWUo=.9cde562f-e5c4-4aa3-ab8d-6a1d6e55a7e3@github.com>

> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).

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 seven additional commits since the last revision:

 - Merge branch 'master' into SpecialHeadersTest-8297200
 - thrown should be thrown
 - Merge branch 'master' into SpecialHeadersTest-8297200
 - Update test/jdk/java/net/httpclient/ReferenceTracker.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Fixed race condition in detecting if selector is still alive
 - 8297200
 - 8297200

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11294/files
  - new: https://git.openjdk.org/jdk/pull/11294/files/01fab390..77f1a9aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11294&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11294&range=03-04

  Stats: 4512 lines in 107 files changed: 3478 ins; 609 del; 425 mod
  Patch: https://git.openjdk.org/jdk/pull/11294.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11294/head:pull/11294

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Mon Nov 28 18:33:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 18:33:01 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <mm5vE-UtV8XM2x_ihvMyx_dVu_fWHp3zirxLfU-HcL0=.8aea7ebd-3ba8-4f37-8e21-0706bba53645@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <mm5vE-UtV8XM2x_ihvMyx_dVu_fWHp3zirxLfU-HcL0=.8aea7ebd-3ba8-4f37-8e21-0706bba53645@github.com>
Message-ID: <o_iaS8xSBCmKWoA0SMe71TyyMvk_C3hnfgXq5w7wQ3w=.8046b824-37ef-4003-a127-542d6a03104d@github.com>

On Mon, 28 Nov 2022 15:05:43 GMT, Jaikiran Pai <jpai 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into SpecialHeadersTest-8297200
>>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Fixed race condition in detecting if selector is still alive
>>  - 8297200
>>  - 8297200
>
> test/jdk/java/net/httpclient/SpecialHeadersTest.java line 379:
> 
>> 377:                     if (error != null) {
>> 378:                         if (thrown != null) error.addSuppressed(thrown);
>> 379:                         throw error;
> 
> If I am reading this code correctly, I think, we might end up losing (and not propagating) the original `thrown` if `error == null`. i.e. we might end up marking a test as passed even when an exception was thrown (and there were no more references left of the client). Perhaps add a else block:
> 
> 
> if (error != null) {
>   ...
> } else if (thrown != null) {
>    throw thrown;
> }
> 
> 
> Similar comment for the other places in this PR where this construct is being changed.

Oh! Darn. Of course. Thanks for catching that! Fixed on last commit.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From psandoz at openjdk.org  Mon Nov 28 19:39:58 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Nov 2022 19:39:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

The approach looks good, and almost the least intrusive (see comment).

src/java.base/share/classes/java/nio/Buffer.java line 838:

> 836: 
> 837:                 @Override
> 838:                 public void releaseSession(Buffer buffer, MemorySessionImpl scope) {

I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From prr at openjdk.org  Mon Nov 28 23:27:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Nov 2022 23:27:55 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.desktop/share/classes/java/awt/package-info.java line 58:

> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
> 58:  *                  The Java AWT Native Interface (JAWT)</a>

Why only 1 of these 3 ?

src/java.desktop/share/classes/java/awt/package-info.java line 62:

> 60:  *
> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
> 62:  * @since 1.0

I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
But I also wonder why only the native_interface spec was added and not the other two ?

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:

> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 225:      * @see #TAG_COMPRESSION
> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>

Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From jpai at openjdk.org  Tue Nov 29 01:38:04 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 01:38:04 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v5]
In-Reply-To: <n6elTxWCdgc4OJkHBvBKYJHu4LerMxFKq24rphYNWUo=.9cde562f-e5c4-4aa3-ab8d-6a1d6e55a7e3@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <n6elTxWCdgc4OJkHBvBKYJHu4LerMxFKq24rphYNWUo=.9cde562f-e5c4-4aa3-ab8d-6a1d6e55a7e3@github.com>
Message-ID: <LSZbuZgDnNEszlxQ9j1Dx1peiZ5GNNIoNT4fBMozABw=.0e303fa7-b0cb-418c-886f-3dcb7ccfbbd8@github.com>

On Mon, 28 Nov 2022 17:57:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - thrown should be thrown
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

Hello Daniel,

> What I could see from the log - and that was enough to understand the issue, is that the test observed "alive" being false, so decided that it didn't need to wait, then immediately after saw "alive" being true - and handled that is if alive was observed after the timeout had expired - when it had waited 0ms for the thread to shutdown.

Thank you for that detail - that makes sense and answers the questions I had. I didn't notice that the tracker could completely skip the wait and then do an additional check which could trigger the failure. In context of this, what you propose for keeping track of start state of the selector manager looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From jpai at openjdk.org  Tue Nov 29 01:38:06 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 01:38:06 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v4]
In-Reply-To: <MzyORmlPMKlLt-ghfg1ZnMBRSxhniPp6EjToXvDYHco=.96b63c13-6d5d-49a4-94cd-40ceadc656e9@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <dzRaGL6Wmz3_LiQUUW4QBMhl1NIyb5TpY701HUtbE78=.cd4fbebc-d5a9-48fc-8573-766fee2cbb72@github.com>
 <aKMvBa_VEAjxl4JddOgu7Co6LWJtliB9D7NptqLrbSo=.eb86d181-99b8-4dc1-b2c8-8c2861acc9f4@github.com>
 <MzyORmlPMKlLt-ghfg1ZnMBRSxhniPp6EjToXvDYHco=.96b63c13-6d5d-49a4-94cd-40ceadc656e9@github.com>
Message-ID: <Ls3GaCx2wZ3RLN9ulqnjB0rs-lyFqA2Kfm_DbDCGUBk=.2413a72d-33c8-42f7-8767-ef1964c0d648@github.com>

On Mon, 28 Nov 2022 16:52:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> start() is called from within the HttpClientImpl constructor, so if Thread::start fails I don't think it will be possible to get such a client - since the constructor will throw. So it doesn't matter much anyway.

During yesterday's review I overlooked that we do indeed throw back the exception if thread start() fails and don't just set a flag. So yes, there's nothing more to do there.

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From jpai at openjdk.org  Tue Nov 29 05:55:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 05:55:05 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s)
Message-ID: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>

Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?

The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.

A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.

-------------

Commit messages:
 - 8297311: Improve exception message thrown by java.net.HostPortrange::toLowerCase(String s)

Changes: https://git.openjdk.org/jdk/pull/11407/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297311
  Stats: 59 lines in 2 files changed: 58 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11407/head:pull/11407

PR: https://git.openjdk.org/jdk/pull/11407

From jpai at openjdk.org  Tue Nov 29 05:56:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 05:56:20 GMT
Subject: RFR: 8297424: java/net/httpclient/AsyncExecutorShutdown.java fails
 in AssertionError due to misplaced assert [v3]
In-Reply-To: <BL7MdDMuijbUZR9Rby3g8w3SIDLUJQ092zfRKm3nswE=.e3f0e701-ae47-490a-9f85-a6465cff0db9@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
 <BL7MdDMuijbUZR9Rby3g8w3SIDLUJQ092zfRKm3nswE=.e3f0e701-ae47-490a-9f85-a6465cff0db9@github.com>
Message-ID: <87kZ4jDml9CpfTrAiQMlHGL3PskEKUK6hmNFqqF6zX0=.0b1bf072-82bc-4818-8077-f9f696098e19@github.com>

On Mon, 28 Nov 2022 14:09:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
>> 
>> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
>> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
>> 
>> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into AsyncExecutorShutdown-8297424
>  - Merge branch 'master' into AsyncExecutorShutdown-8297424
>  - Revert assignement of pendingResponseSubscriber to null to avoid race conditions with ternary operators
>  - 8297424

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11332

From pminborg at openjdk.org  Tue Nov 29 07:57:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 07:57:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
 <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
Message-ID: <RiwpEqwEUkQFRs2nQvTR75dUEXQtiyJY9TQ2MJ8jTvA=.b052a5de-fa63-43e2-a7b8-51ff4b87bec1@github.com>

On Mon, 28 Nov 2022 19:35:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

I agree. A similar approach was done in a previous incarnation of the PR whereby we exposed a `ScopeAcqusition` that held an internal copy of the buffer and provided means to release. We feared that would cause performance regression. But your comment made me think of another way of doing acquire/release which would not expose the session and that would always be performant. I will explore this idea a bit more.

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Tue Nov 29 09:40:58 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 09:40:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove session exposure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eedf41ae..619473ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15-16

  Stats: 125 lines in 20 files changed: 11 ins; 13 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Tue Nov 29 10:19:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Nov 2022 10:19:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <8HV7vdX-QrKG_OhlGWLwAG2uLsT8sKIbIqAce65bNWU=.68ffecbe-2065-418c-a0a5-1f0d04964717@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

This looks more symmetric, I like it. Since `acquire` was only really returning null if the underlying buffer had no associated session, I believe this rewriting preserves the semantics we had before (e.g. no accidental double releases).

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11260

From mstjohns at comcast.net  Tue Nov 29 03:14:20 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 28 Nov 2022 22:14:20 -0500
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
Message-ID: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>

Hi -

I need to repeat again.? Please avoid using www.ietf.org as the URL base 
for referencing RFCs.? The appropriate location is www.rfc-editor.org 
and is going to be more stable in the long run than any reference to an 
RFC that runs through the IETF's website.? These two websites have 
different purposes, and the structure of the IETF website has changed at 
least once recently and may change again relatively (~5 years) soon.

The most general and correct form for referencing RFCs is 
"https://www.rfc-editor.org/info/rfc<number>"? That will get you to the 
front page with pointers to all of the current semi-canonical versions 
of the spec (e.g. text, pdf-a, html, and xml).

Mike



On 11/28/2022 6:27 PM, Phil Race wrote:
> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>>>
>>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>>>
>>> "Normalized" means...
>>> * Use `https:` where possible (includes pretty much all cases)
>>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>>> * Point to the root page of a multi-page spec
>>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>>>
>>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>>>
>>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>>>
>>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>>>
>>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>>>
>>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>>>
>>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove updates from unexported files
> src/java.desktop/share/classes/java/awt/package-info.java line 58:
>
>> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
>> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
>> 58:  *                  The Java AWT Native Interface (JAWT)</a>
> Why only 1 of these 3 ?
>
> src/java.desktop/share/classes/java/awt/package-info.java line 62:
>
>> 60:  *
>> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
>> 62:  * @since 1.0
> I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
> But I also wonder why only the native_interface spec was added and not the other two ?
>
> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:
>
>> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
>> 225:      * @see #TAG_COMPRESSION
>> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
> Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11073



From daniel.fuchs at oracle.com  Tue Nov 29 11:03:04 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Nov 2022 11:03:04 +0000
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>
 <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net>
Message-ID: <65e42b26-6f83-b3a7-5247-7feb78b9e006@oracle.com>

We hear you Mike :-)

I have logged https://bugs.openjdk.org/browse/JDK-8297755 to update the
links in java.net / java.net.http API documentation.

best regards,

-- daniel

On 29/11/2022 03:14, Michael StJohns wrote:
> Hi -
> 
> I need to repeat again.? Please avoid using www.ietf.org as the URL base 
> for referencing RFCs.? The appropriate location is www.rfc-editor.org 
> and is going to be more stable in the long run than any reference to an 
> RFC that runs through the IETF's website.? These two websites have 
> different purposes, and the structure of the IETF website has changed at 
> least once recently and may change again relatively (~5 years) soon.
> 
> The most general and correct form for referencing RFCs is 
> "https://www.rfc-editor.org/info/rfc<number>"? That will get you to the 
> front page with pointers to all of the current semi-canonical versions 
> of the spec (e.g. text, pdf-a, html, and xml).
> 
> Mike


From michaelm at openjdk.org  Tue Nov 29 11:14:10 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Nov 2022 11:14:10 GMT
Subject: Integrated: 8296804: Document HttpClient configuration properties in
 java.net.http module-info
In-Reply-To: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
References: <Fr-w5Eq6a1QR5dxlCHbzsClTyTxGQwONg6ysFaefa04=.9fcabc58-a940-4a75-a68a-9af6bfd5f312@github.com>
Message-ID: <nlUNWh8NBEgGvLYJmtii6KeiG28Gvtu_KHYaO-N23gY=.90d60fcf-9148-470b-86dc-50f7cd285d59@github.com>

On Fri, 18 Nov 2022 13:50:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following doc change reviewed please? It documents the system/networking properties used by the java.net.http HTTP client in its module-info. (CSR to follow)
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: 48017b1d
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48017b1d9c3a7867984f54d61f17c7f034d213f5
Stats:     132 lines in 1 file changed: 130 ins; 0 del; 2 mod

8296804: Document HttpClient configuration properties in java.net.http module-info

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11241

From jpai at openjdk.org  Tue Nov 29 11:46:31 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 11:46:31 GMT
Subject: RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed
 once in AssertionError due to selector thread remaining alive [v5]
In-Reply-To: <n6elTxWCdgc4OJkHBvBKYJHu4LerMxFKq24rphYNWUo=.9cde562f-e5c4-4aa3-ab8d-6a1d6e55a7e3@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
 <n6elTxWCdgc4OJkHBvBKYJHu4LerMxFKq24rphYNWUo=.9cde562f-e5c4-4aa3-ab8d-6a1d6e55a7e3@github.com>
Message-ID: <GPqxqEfYKlXLxj4E8Y-SrcVXHwaXHUy-id6bGMejgFw=.4de552f7-c99b-4fdf-b1b8-c0585c613f7a@github.com>

On Mon, 28 Nov 2022 17:57:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - thrown should be thrown
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From ccleary at openjdk.org  Tue Nov 29 11:47:40 2022
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 29 Nov 2022 11:47:40 GMT
Subject: Integrated: 8297030: Reduce Default Keep-Alive Timeout Value for
 httpclient
In-Reply-To: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
References: <e8FGNGb0SP6JBuz1tGvwyhZbSDsx0YLynfANn0RtHG0=.f4ebb38a-d2bb-4996-803a-ab64aa9ea24d@github.com>
Message-ID: <Cl0mNaHd34qKI7U21tkSSK4yAf2XUmFqLLgOJzqDz4c=.cb08a022-1c6c-4dfe-9e1e-2b2e531347a2@github.com>

On Tue, 22 Nov 2022 11:10:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Proposed changes to reduce the default Keep Alive Timeout value in `jdk/internal/net/http/HttpClientImpl.java` from 1200 seconds to 30 seconds. The current default value of 1200s is needlessly high and in remote connections that allow a client to suggest a value, this will mean that idle connections will wait very long before being dropped.
> 
> This value of 30 seconds was chosen by reviewing the current default values for Keep-Alive timeouts in common server implementations and choosing a value that would have the client's default value be lower whenever the value can be set.
> 
> Further discussion on this change can be seen the pull request [8288717: Add a means to close idle connections in HTTP/2 connection pool #10183](https://github.com/openjdk/jdk/pull/10183).

This pull request has now been integrated.

Changeset: 42b60ed2
Author:    Conor Cleary <ccleary at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42b60ed22c02663eb1377d1ce78a559fdbb4348d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8297030: Reduce Default Keep-Alive Timeout Value for httpclient

Reviewed-by: dfuchs, michaelm, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11285

From duke at openjdk.org  Tue Nov 29 11:49:09 2022
From: duke at openjdk.org (Johnny Lim)
Date: Tue, 29 Nov 2022 11:49:09 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException message
 being thrown from HttpURLConnection
Message-ID: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>

This PR removes a duplicate space in `ProtocolException` message.

-------------

Commit messages:
 - Remove duplicate space in ProtocolException message

Changes: https://git.openjdk.org/jdk/pull/11002/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297749
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11002.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11002/head:pull/11002

PR: https://git.openjdk.org/jdk/pull/11002

From jpai at openjdk.org  Tue Nov 29 11:49:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 11:49:10 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection
In-Reply-To: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
Message-ID: <p3yrucmSKya83fwYB6ugUjZBeH8eIL90lVwUPiS7WkI=.62a50745-a2b2-4e2f-bf89-3a177337611d@github.com>

On Sat, 5 Nov 2022 00:01:15 GMT, Johnny Lim <duke at openjdk.org> wrote:

> This PR removes a duplicate space in `ProtocolException` message.

Hello @izeye, for this pull request to be officially reviewed, the process requires a JBS issue to be filed and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297749 to track this change.

Please update the title of this PR to `8297749: Remove duplicate space in the ProtocolException message being thrown from HttpURLConnection` so that the necessary review process gets initiated.

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From duke at openjdk.org  Tue Nov 29 11:49:11 2022
From: duke at openjdk.org (Johnny Lim)
Date: Tue, 29 Nov 2022 11:49:11 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection
In-Reply-To: <p3yrucmSKya83fwYB6ugUjZBeH8eIL90lVwUPiS7WkI=.62a50745-a2b2-4e2f-bf89-3a177337611d@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
 <p3yrucmSKya83fwYB6ugUjZBeH8eIL90lVwUPiS7WkI=.62a50745-a2b2-4e2f-bf89-3a177337611d@github.com>
Message-ID: <5jyA7TCLYdiMQt7xPWDT7f3Ak3M2FbNcmaZURnUzeGA=.126ca2ee-e9ec-483b-8b3d-71935c56ed5a@github.com>

On Tue, 29 Nov 2022 07:21:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR removes a duplicate space in `ProtocolException` message.
>
> Hello @izeye, for this pull request to be officially reviewed, the process requires a JBS issue to be filed and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297749 to track this change.
> 
> Please update the title of this PR to `8297749: Remove duplicate space in the ProtocolException message being thrown from HttpURLConnection` so that the necessary review process gets initiated.

@jaikiran Thanks for the feedback! I updated the title as you suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From dfuchs at openjdk.org  Tue Nov 29 12:38:59 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 12:38:59 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s)
In-Reply-To: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
Message-ID: <f4_Lf9jaqcqI7Ne0MGnTwud07vzaedsScA5y_NS-dtA=.4de7b4f5-de80-4f42-8e27-5c91db5c8be3@github.com>

On Tue, 29 Nov 2022 05:48:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
> 
> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
> 
> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.

src/java.base/share/classes/java/net/HostPortrange.java line 189:

> 187:                 sb.append((char)(c - CASE_DIFF));
> 188:             } else {
> 189:                 final String invalidChar = String.format("\\u%04x", (int) c);

Why not construct the whole message using String.format? It would avoid the string concatenation below...

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From dfuchs at openjdk.org  Tue Nov 29 12:40:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 12:40:24 GMT
Subject: Integrated: 8297424: java/net/httpclient/AsyncExecutorShutdown.java
 fails in AssertionError due to misplaced assert
In-Reply-To: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
References: <4IDMe_5rVhgvXUVGMvWLWYe7gSha5w9vt0DBoDscYcs=.84d2d140-ac16-4dd4-9cf2-0ddc474c9b0f@github.com>
Message-ID: <BEMt78kbSb1Mv-l8EYCDenCmthR6NwXH-AQaYjDHmDw=.9b2f6def-2906-41f8-98e5-ccf7e4dfb681@github.com>

On Wed, 23 Nov 2022 19:38:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `ResponseSubscribers.HttpResponseInputStream` class has an assert that has been observed firing (rarely) when running the `java/net/httpclient/AsyncExecutorShutdown.java` test.
> 
> After a thorough analysis of the code and the log failure I am convinced that the issue is due to a misplaced assert.
> If cancellation happens asynchronously while the subscriber is being subscribed with the lower layers of the stack, the `HttpResponseInputStream` might get closed and the `LAST_LIST` buffer might be offered after `closed == false` has been observed by the `onSubscribed` method, but before the assertion has been checked. The assertion assumes that the queue must be empty, but it might not if `close` has been called and the `LAST_LIST` buffer has been offered.
> 
> Moving the assert from within the synchronized block, to ensure that the observed value of `closed` is consistent with the state of the queue, should fix it. I have tagged the bug as `noreg-hard`, I'm not sure it would be fair to say that `AsyncExecutorShutdown.java` can be used to verify the fix.

This pull request has now been integrated.

Changeset: 5d2772a4
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d2772a43ef6409bf556cefb4eb4242594451674
Stats:     10 lines in 2 files changed: 3 ins; 4 del; 3 mod

8297424: java/net/httpclient/AsyncExecutorShutdown.java fails in AssertionError due to misplaced assert

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11332

From dfuchs at openjdk.org  Tue Nov 29 12:45:35 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 12:45:35 GMT
Subject: Integrated: 8297200: java/net/httpclient/SpecialHeadersTest.java
 failed once in AssertionError due to selector thread remaining alive
In-Reply-To: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
References: <egvNEzzYvPpgN2DvcLbu5sswaoP2AilXTA2GmRXaQeg=.1a093cd4-8363-4cf3-a675-865170732fab@github.com>
Message-ID: <VIf2SdNtkqT2tAfZ1qoDn06oWOUw_3xlhEJb0GvuQCg=.bb373423-4fa7-4a62-893d-9bc9e80b0650@github.com>

On Tue, 22 Nov 2022 17:24:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).

This pull request has now been integrated.

Changeset: d83a07b7
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d83a07b72cfd4dc42c5d4815262fcba05c653bd5
Stats:     103 lines in 4 files changed: 79 ins; 0 del; 24 mod

8297200: java/net/httpclient/SpecialHeadersTest.java failed once in AssertionError due to selector thread remaining alive

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11294

From dfuchs at openjdk.org  Tue Nov 29 12:46:36 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 12:46:36 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection
In-Reply-To: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
Message-ID: <xeOaVn8awDr_9_i0RS7tA73zDfO1ziELyaUnQVWsItI=.7ad3bb0f-4604-45f4-87f1-ead99664f9a4@github.com>

On Sat, 5 Nov 2022 00:01:15 GMT, Johnny Lim <duke at openjdk.org> wrote:

> This PR removes a duplicate space in `ProtocolException` message.

src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 1999:

> 1997:             } while (redirects < maxRedirects);
> 1998: 
> 1999:             throw new ProtocolException("Server redirected too many times ("+ redirects + ")");

There's a missing space between " and + ; In order to avoid long lines which are a pain to review in side diffs I would suggest to reformat and add a newline there, rather than a whitespace.

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From jpai at openjdk.org  Tue Nov 29 12:56:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 12:56:02 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
Message-ID: <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>

> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
> 
> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
> 
> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11407/files
  - new: https://git.openjdk.org/jdk/pull/11407/files/82826ed4..8b9a428d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11407&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11407&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11407/head:pull/11407

PR: https://git.openjdk.org/jdk/pull/11407

From dfuchs at openjdk.org  Tue Nov 29 12:56:04 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 12:56:04 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
 <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
Message-ID: <nD15o9GXRluO0PZf7HvctsrpX_qql7yrBXr21boKIxY=.1eaec33f-2664-4153-82b3-ad7253609eb6@github.com>

On Tue, 29 Nov 2022 12:52:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
>> 
>> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
>> 
>> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From jpai at openjdk.org  Tue Nov 29 12:56:06 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 12:56:06 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <f4_Lf9jaqcqI7Ne0MGnTwud07vzaedsScA5y_NS-dtA=.4de7b4f5-de80-4f42-8e27-5c91db5c8be3@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
 <f4_Lf9jaqcqI7Ne0MGnTwud07vzaedsScA5y_NS-dtA=.4de7b4f5-de80-4f42-8e27-5c91db5c8be3@github.com>
Message-ID: <Euq8CWZop6_621S0gL9HRtCkAVOSpzNeLMHQN3ECY8Y=.6c31b095-3828-4e4b-b08e-3a4ef21ccf56@github.com>

On Tue, 29 Nov 2022 12:35:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comment
>
> src/java.base/share/classes/java/net/HostPortrange.java line 189:
> 
>> 187:                 sb.append((char)(c - CASE_DIFF));
>> 188:             } else {
>> 189:                 final String invalidChar = String.format("\\u%04x", (int) c);
> 
> Why not construct the whole message using String.format? It would avoid the string concatenation below...

That's certainly better. I've now updated the PR to follow that suggestion. The new test continues to pass.

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From jpai at openjdk.org  Tue Nov 29 13:11:55 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 13:11:55 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
 <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
 <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>
Message-ID: <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>

On Fri, 25 Nov 2022 13:23:30 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> Hello @Karm, to officially initiate a review of this change, the review process (backed by bots) requires a JBS issue to be created and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297609 to track this.
>> 
>> Next, you will have to update the title of this PR to `8297609: Add application/wasm MIME type for wasm file extension` to link this PR against that issue. That will then initiate the necessary review process.
>
> @jaikiran Thanks.

Hello @Karm, we have an existing test in the JDK which verifies the expected mime types for some well known extensions. It resides at `test/jdk/java/nio/file/Files/probeContentType/Basic.java`. Could you update that test's main method to include a test for this new mime type that this PR adds?

I suspect it would be as simple as adding this new entry to this array here https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/Files/probeContentType/Basic.java#L189

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From jpai at openjdk.org  Tue Nov 29 13:11:59 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 13:11:59 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
Message-ID: <iwVxl4yad1j-VXtP0MYHtWjODp-EOPz7hEShySw91RQ=.1a4f812c-5c33-4416-a4a8-e1971fd7dde6@github.com>

On Tue, 22 Nov 2022 10:43:42 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
> 
> # How to reproduce
> 
> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
> 
> ## Sources
> 
> `main.c`:
> 
> #include <stdio.h>
> 
> int main() {
>   printf("Hello browser debug console...\n");
> }
> 
> 
> `Server.java`:
> 
> import com.sun.net.httpserver.HttpServer;
> import com.sun.net.httpserver.SimpleFileServer;
> 
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.nio.file.Path;
> 
> import static java.lang.System.exit;
> import static java.lang.System.out;
> 
> public class Server {
>     public static void main(String... args) {
>         if (args.length != 2) {
>             out.println("Usage: java Server <port> <web dir path>");
>             exit(1);
>         }
>         final int port = Integer.parseInt(args[0]);
>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>         final Path root = Path.of(args[1]).toAbsolutePath();
>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>         server.start();
>     }
> }
> 
> ## Build
> 
> $ mkdir out
> $ emcc main.c -s WASM=1 -o out/main.html
> $ ls out/
> main.html  main.js  main.wasm
> 
> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
> 
> ## Execution
> 
> $ java --version
> openjdk 19.0.1 2022-10-18
> $ javac Server.java
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> 
> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
> 
> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
> 
> When I switch to the JDK patched with this patch and run the server again:
> 
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
> 
> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
> 
> Thank you for your time.
> 
> Cheers
> K.

src/java.base/unix/classes/sun/net/www/content-types.properties line 400:

> 398: 
> 399: application/wasm: \
> 400: 	description=WASM File;\

Perhaps the description could be `WebAssembly File;`? Same in the Windows' file.

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From duke at openjdk.org  Tue Nov 29 13:21:19 2022
From: duke at openjdk.org (Johnny Lim)
Date: Tue, 29 Nov 2022 13:21:19 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection [v2]
In-Reply-To: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
Message-ID: <jOpy9JTYHj7uI-0ttqnZcmv5Mj1yd8WKv7b1UbbKVQE=.b0c3563a-40e3-42ab-a7ab-322030dc0398@github.com>

> This PR removes a duplicate space in `ProtocolException` message.

Johnny Lim has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Remove duplicate space in ProtocolException message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11002/files
  - new: https://git.openjdk.org/jdk/pull/11002/files/fc2a719c..6fcca317

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11002&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11002&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11002.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11002/head:pull/11002

PR: https://git.openjdk.org/jdk/pull/11002

From duke at openjdk.org  Tue Nov 29 13:24:49 2022
From: duke at openjdk.org (Johnny Lim)
Date: Tue, 29 Nov 2022 13:24:49 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection [v2]
In-Reply-To: <xeOaVn8awDr_9_i0RS7tA73zDfO1ziELyaUnQVWsItI=.7ad3bb0f-4604-45f4-87f1-ead99664f9a4@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
 <xeOaVn8awDr_9_i0RS7tA73zDfO1ziELyaUnQVWsItI=.7ad3bb0f-4604-45f4-87f1-ead99664f9a4@github.com>
Message-ID: <5LwdCNHZ0uydarbiaZFoJK3BsNAFcsfT14ZDX3PvtXQ=.297455cc-b4c1-43c7-ae3a-28aaf9bff292@github.com>

On Tue, 29 Nov 2022 12:44:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Johnny Lim has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Remove duplicate space in ProtocolException message
>
> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 1999:
> 
>> 1997:             } while (redirects < maxRedirects);
>> 1998: 
>> 1999:             throw new ProtocolException("Server redirected too many times ("+ redirects + ")");
> 
> There's a missing space between " and + ; In order to avoid long lines which are a pain to review in side diffs I would suggest to reformat and add a newline there, rather than a whitespace.

@dfuch Thanks for the feedback! I updated as you suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From dfuchs at openjdk.org  Tue Nov 29 13:58:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 13:58:20 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection [v2]
In-Reply-To: <jOpy9JTYHj7uI-0ttqnZcmv5Mj1yd8WKv7b1UbbKVQE=.b0c3563a-40e3-42ab-a7ab-322030dc0398@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
 <jOpy9JTYHj7uI-0ttqnZcmv5Mj1yd8WKv7b1UbbKVQE=.b0c3563a-40e3-42ab-a7ab-322030dc0398@github.com>
Message-ID: <hlEIAQkMJhFskY7hgrGE98_7Kw4t6170VEw4AkB7G3E=.9ec97052-c309-4c05-ba43-bc5889418154@github.com>

On Tue, 29 Nov 2022 13:21:19 GMT, Johnny Lim <duke at openjdk.org> wrote:

>> This PR removes a duplicate space in `ProtocolException` message.
>
> Johnny Lim has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Remove duplicate space in ProtocolException message

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From alanb at openjdk.org  Tue Nov 29 14:25:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 14:25:53 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <imPDtE3v_kdFiu-MpQbYCrhrZ3dUWEL5mFrIQL9jYNQ=.df5a4f44-64eb-4ded-94a8-967140a84ac6@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From michaelm at openjdk.org  Tue Nov 29 15:13:20 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Nov 2022 15:13:20 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
 <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
Message-ID: <gGrATdkFqdF6SLZljfUHZtKzT1Ldckwf1wg17N7NU7o=.dd7f8bb1-4736-44b8-af38-5305c3db9652@github.com>

On Tue, 29 Nov 2022 12:56:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
>> 
>> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
>> 
>> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

LGTM

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11407

From rriggs at openjdk.org  Tue Nov 29 15:41:25 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Nov 2022 15:41:25 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
 <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
Message-ID: <Ynp9jrCYeqRvDfL2_14WNgDS1e7lVqcDTyaknT7-ydo=.bf55a4d7-f9f6-44a2-8f3e-c8be1cb6d82d@github.com>

On Tue, 29 Nov 2022 12:56:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
>> 
>> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
>> 
>> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From psandoz at openjdk.org  Tue Nov 29 16:21:25 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 29 Nov 2022 16:21:25 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <V3gcPvdGTNp_x6EiidGcs3Lw28BZiT29_JmKI_WKv24=.6570b117-67d4-4890-be6a-7cbcbf58fbe7@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From pminborg at openjdk.org  Tue Nov 29 16:54:53 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 16:54:53 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
Message-ID: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>

This PR proposes a variety of modernisations to the `jdk.sctp` module.

During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 

* Replacing duplicate code segments 
* Making certain fields final 
* Using enhanced switch 
* Using records 
* Fixing typos 
* Marking fields participating in serialisation with `@Serial` 
* Modernizing toString() implementations 
* Using pattern matching 
* Using diamond operators

-------------

Commit messages:
 - Modernize module jdk.sctp

Changes: https://git.openjdk.org/jdk/pull/11418/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297778
  Stats: 609 lines in 31 files changed: 102 ins; 176 del; 331 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From dfuchs at openjdk.org  Tue Nov 29 17:36:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 17:36:24 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
Message-ID: <2SSoAddXzCb4-tqCmvWxNUFNsck7RoWPcbEkPfGo3BM=.52fb387e-f196-46de-a539-f440212b5234@github.com>

On Mon, 28 Nov 2022 14:21:01 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright year and formatting of a comment

Actually, there's one more thing that we probably should do. The API documentation of `HttpResponse.BodySubscribers::ofInputStream` has an `@apiNote` that emphasizes the need to read the stream to exhaustion, or call close, in order to release all resources.
We probably should also add an `@apiNote` to document that the default implementation returned by that method throw `InterruptedIOException` if the thread is interrupted while reading from the stream.

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From dfuchs at openjdk.org  Tue Nov 29 17:46:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 17:46:22 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

It is a bit unusual to use a local class as a holder class (the typical manner is to a have a private static final nested class) but we didn't have local classes until recently - so maybe that's OK. I assume there's only one version of that class and it is static?

src/jdk.sctp/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java line 32:

> 30: public record SctpStdSocketOption<T>(String name,
> 31:                                      Class<T> type,
> 32:                                      int constValue)

This changes the implementation of `toString`, `equals` and `hashCode`. Have you verified that it is OK to do so?

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 33:

> 31: import java.io.FileDescriptor;
> 32: import java.io.IOException;
> 33: import java.util.*;

It would be better to avoid wildcards in regular imports.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From dfuchs at openjdk.org  Tue Nov 29 17:58:52 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 17:58:52 GMT
Subject: RFR: 8297645: Drop the
 test/jdk/java/net/httpclient/reactivestreams-tck-tests/TckDriver.java test
Message-ID: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>

Please find here a fix that drops the HttpClient TckDiriver test. This test has been useful when developing the HTTP client APIs. However, it has become a burden to run this test, which is now the longest running HttpClient test. This change proposes to drop the test from the non regression test suite.

-------------

Commit messages:
 - 8297645

Changes: https://git.openjdk.org/jdk/pull/11420/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297645
  Stats: 10085 lines in 58 files changed: 0 ins; 10085 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11420.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11420/head:pull/11420

PR: https://git.openjdk.org/jdk/pull/11420

From alanb at openjdk.org  Tue Nov 29 18:04:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 18:04:01 GMT
Subject: RFR: 8297645: Drop the
 test/jdk/java/net/httpclient/reactivestreams-tck-tests/TckDriver.java test
In-Reply-To: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
References: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
Message-ID: <GNPAoF-T37uE2Z7QJZYn0Qkm01xJ4tQDBCqN4KvsPSU=.c15b8e44-b448-4bb9-a494-a57a393bfc07@github.com>

On Tue, 29 Nov 2022 17:50:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a fix that drops the HttpClient TckDiriver test. This test has been useful when developing the HTTP client APIs. However, it has become a burden to run this test, which is now the longest running HttpClient test. This change proposes to drop the test from the non regression test suite.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11420

From bpb at openjdk.org  Tue Nov 29 18:08:26 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Nov 2022 18:08:26 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <cvaemJgKtEOadHrbrClGy4eT618IkjsKXGi2NDyWTos=.2e0dc1d1-609b-4d75-aa90-020193c2896d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From alanb at openjdk.org  Tue Nov 29 18:24:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 18:24:30 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <WvWhDAfncSEDBf2I-OBPqcBwr8xtUIZQCGNOd60yJRY=.ab709c05-4df4-44a5-a7c4-27f39ad30d6b@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

The SCTP hasn't had much TLC in some time, maybe JDK 6, so not surprising there is a lot of cleanup/modernization.

You'll need to add a copyright header to sun.nio.ch. sctp.Util. It's a pity there are duplicate copies.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From duke at openjdk.org  Tue Nov 29 19:23:21 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Tue, 29 Nov 2022 19:23:21 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
Message-ID: <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>

> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
> 
> # How to reproduce
> 
> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
> 
> ## Sources
> 
> `main.c`:
> 
> #include <stdio.h>
> 
> int main() {
>   printf("Hello browser debug console...\n");
> }
> 
> 
> `Server.java`:
> 
> import com.sun.net.httpserver.HttpServer;
> import com.sun.net.httpserver.SimpleFileServer;
> 
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.nio.file.Path;
> 
> import static java.lang.System.exit;
> import static java.lang.System.out;
> 
> public class Server {
>     public static void main(String... args) {
>         if (args.length != 2) {
>             out.println("Usage: java Server <port> <web dir path>");
>             exit(1);
>         }
>         final int port = Integer.parseInt(args[0]);
>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>         final Path root = Path.of(args[1]).toAbsolutePath();
>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>         server.start();
>     }
> }
> 
> ## Build
> 
> $ mkdir out
> $ emcc main.c -s WASM=1 -o out/main.html
> $ ls out/
> main.html  main.js  main.wasm
> 
> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
> 
> ## Execution
> 
> $ java --version
> openjdk 19.0.1 2022-10-18
> $ javac Server.java
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> 
> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
> 
> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
> 
> When I switch to the JDK patched with this patch and run the server again:
> 
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
> 
> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
> 
> Thank you for your time.
> 
> Cheers
> K.

Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:

  Adds test for MIME application/wasm

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11284/files
  - new: https://git.openjdk.org/jdk/pull/11284/files/c67e03c5..77a4e79b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11284&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11284&range=00-01

  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11284.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11284/head:pull/11284

PR: https://git.openjdk.org/jdk/pull/11284

From duke at openjdk.org  Tue Nov 29 19:23:23 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Tue, 29 Nov 2022 19:23:23 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
 <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
 <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>
 <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>
Message-ID: <LY39w5psNzLS7z2Cwagf9XVe81xYAepwWWqB17aFCLI=.07557671-2c85-4da6-881b-c90f8d1e501e@github.com>

On Tue, 29 Nov 2022 13:06:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Could you update that test's main method to include a test for this new mime type that this PR adds?

Ack. 

The test fails when I put something random in there and it passes with wasm now:


$ make run-test TEST="jtreg:test/jdk/java/nio/file/Files/probeContentType/Basic.java"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/nio/file/Files/probeContentType/Basic.java
                                                         1     1     0     0   
==============================
TEST SUCCESS

@jaikiran Would you like me to squash those two commits and force push in that branch? I am not really familiar with the JDK project's GitHub flow and I don't want to disturb any bots with messing up the PR commit history.   Thx for advice...

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From rriggs at openjdk.org  Tue Nov 29 19:26:38 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Nov 2022 19:26:38 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

src/jdk.sctp/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 39:

> 37: import com.sun.nio.sctp.SctpSocketOption;
> 38: 
> 39: import static sun.nio.ch.sctp.Util.sctpNotSupported;

Not really a fan of static imports like this; it looks like a local method in the code but is not. 
In this case, the code would be more readable as `Util.sctpNotSupported()`.
This style of creating exceptions to throw is unusual in OpenJDK.

src/jdk.sctp/aix/classes/sun/nio/ch/sctp/Util.java line 1:

> 1: package sun.nio.ch.sctp;

Can this be shared in **share**/classes/sun/nio/sctp/Util.java?

src/jdk.sctp/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 44:

> 42:  * Unimplemented.
> 43:  */
> 44: public class SctpChannelImpl extends SctpChannel {

Going a bit beyond just updating syntax; but that's a different PR...
There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception.  There would less duplication for unsupported platforms.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 722:

> 720: 
> 721:     /**
> 722:      * @throws IllegalArgumentException If the given association is not controlled by this channel

There should be a 1st sentence describing the function; its odd to see only an @throws.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From dfuchs at openjdk.org  Tue Nov 29 19:56:03 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Nov 2022 19:56:03 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
 <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
 <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>
 <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>
Message-ID: <4lzRrE8M3sRyfZBCLrvcv5IztSvUfLg4I7Btkd27Ou4=.6e60fda3-4adb-4512-a08d-0ec7e15fdfff@github.com>

On Tue, 29 Nov 2022 13:06:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @jaikiran Thanks.
>
> Hello @Karm, we have an existing test in the JDK which verifies the expected mime types for some well known extensions. It resides at `test/jdk/java/nio/file/Files/probeContentType/Basic.java`. Could you update that test's main method to include a test for this new mime type that this PR adds?
> 
> I suspect it would be as simple as adding this new entry to this array here https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/Files/probeContentType/Basic.java#L189

> @jaikiran Would you like me to squash those two commits and force push in that branch? I am not really familiar with the JDK project's GitHub flow and I don't want to disturb any bots with messing up the PR commit history. Thx for advice...

Commits will be automatically squashed by the bot when you /integrate - so there's no need to force-push. In fact this is even discouraged as it messes up with feedback made by reviewers on previous iterations of the PR. So please don't force-push :-)

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From duke at openjdk.org  Tue Nov 29 20:03:17 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Tue, 29 Nov 2022 20:03:17 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension
In-Reply-To: <4lzRrE8M3sRyfZBCLrvcv5IztSvUfLg4I7Btkd27Ou4=.6e60fda3-4adb-4512-a08d-0ec7e15fdfff@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <z35myQjByY5l3cOzEzMshJL6LlrsIUJTaLoPUgAxeiw=.2292f5e9-4b34-4450-85b5-ea754b069942@github.com>
 <io07CI4wtiB_4FQzeoTbntWOIrw5VW7Ku6-cmPBfPU8=.7e22e73b-086d-4a60-bb8f-2247f4f5f56e@github.com>
 <yJLbYqQG0BqUExTai0E0H-XBA4pQV1QQD_n8cqaqp94=.99e01cba-f339-4f02-a164-526cb104e414@github.com>
 <QghfbwmDhid-zF9rZ7ysOqyQoaUELneVwS0mZ4Qjlq8=.d232cc86-5699-4b84-b434-02daa5d54efd@github.com>
 <4lzRrE8M3sRyfZBCLrvcv5IztSvUfLg4I7Btkd27Ou4=.6e60fda3-4adb-4512-a08d-0ec7e15fdfff@github.com>
Message-ID: <tHW8l9EuFpO4TqtZwNKZBPGE1VHoVzjwK4G6D-rBHBc=.623f66e1-4976-4d20-9fa1-c32873e3374b@github.com>

On Tue, 29 Nov 2022 19:52:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Commits will be automatically squashed by the bot when you /integrate - so there's no need to force-push. 

Ack. Thanks :)

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From alanb at openjdk.org  Tue Nov 29 20:27:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 20:27:22 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
Message-ID: <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>

On Tue, 29 Nov 2022 19:24:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception. There would less duplication for unsupported platforms.

I think this is accident of history. As I recall, the "unsupported implementation" was Windows only in JDK 6 but it has since been copied. It could be cleaned up.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From duke at openjdk.org  Tue Nov 29 21:09:17 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Tue, 29 Nov 2022 21:09:17 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
Message-ID: <GmT341ZjofvQrPDnzuTYjojRAKQLTi7-_r1b3yEed14=.41dfd2fa-c56b-4d7d-adf7-a189de726fcc@github.com>

On Tue, 29 Nov 2022 19:23:21 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds test for MIME application/wasm

I: Configuring ca-certificates...
W: Failure while configuring base packages.  This will be re-attempted up to five times.
W: See /home/runner/work/jdk/jdk/sysroot/debootstrap/debootstrap.log for details (possibly the package libasound2:riscv64 is at fault)


I'd say unrelated to the PR...?

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From jpai at openjdk.org  Wed Nov 30 00:37:28 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:37:28 GMT
Subject: RFR: 8297645: Drop the
 test/jdk/java/net/httpclient/reactivestreams-tck-tests/TckDriver.java test
In-Reply-To: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
References: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
Message-ID: <ceM8J2zE_IvZ62M02_c0L4MrR8GaRfqBR3tgJKngPYM=.37700ab1-99fa-42f8-a8ff-38142ad695a1@github.com>

On Tue, 29 Nov 2022 17:50:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a fix that drops the HttpClient TckDiriver test. This test has been useful when developing the HTTP client APIs. However, it has become a burden to run this test, which is now the longest running HttpClient test. This change proposes to drop the test from the non regression test suite.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11420

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <yt80pFqXzOAv8ZoCHgjvBBruV1kcdXmPt-xEFPqfrr8=.ad0cd2c4-b730-4362-b031-337991eff415@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: Integrated: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <E09ZXv_6AoFNPWbC2-vUhfflo09LMQMBXc5BoX-Pe7c=.8d7cafee-51cb-4f6d-b927-cef4ef4d06d0@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

This pull request has now been integrated.

Changeset: 0ce18272
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ce182723b8d3a98c71c1b71fa1d3f5a7479fba8
Stats:     20 lines in 19 files changed: 0 ins; 0 del; 20 mod

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: alanb, lancea, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Wed Nov 30 00:48:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:48:09 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection [v2]
In-Reply-To: <jOpy9JTYHj7uI-0ttqnZcmv5Mj1yd8WKv7b1UbbKVQE=.b0c3563a-40e3-42ab-a7ab-322030dc0398@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
 <jOpy9JTYHj7uI-0ttqnZcmv5Mj1yd8WKv7b1UbbKVQE=.b0c3563a-40e3-42ab-a7ab-322030dc0398@github.com>
Message-ID: <xYs7hFrNtVmHC2pN2u44CZpW8ZruXFQwtXlXNsSqEWo=.4332a4ad-05f3-4d99-954a-e8837a5e9ee9@github.com>

On Tue, 29 Nov 2022 13:21:19 GMT, Johnny Lim <duke at openjdk.org> wrote:

>> This PR removes a duplicate space in `ProtocolException` message.
>
> Johnny Lim has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Remove duplicate space in ProtocolException message

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From jpai at openjdk.org  Wed Nov 30 00:48:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:48:10 GMT
Subject: RFR: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection
In-Reply-To: <5jyA7TCLYdiMQt7xPWDT7f3Ak3M2FbNcmaZURnUzeGA=.126ca2ee-e9ec-483b-8b3d-71935c56ed5a@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
 <p3yrucmSKya83fwYB6ugUjZBeH8eIL90lVwUPiS7WkI=.62a50745-a2b2-4e2f-bf89-3a177337611d@github.com>
 <5jyA7TCLYdiMQt7xPWDT7f3Ak3M2FbNcmaZURnUzeGA=.126ca2ee-e9ec-483b-8b3d-71935c56ed5a@github.com>
Message-ID: <7JokJAAYgzU8NZjZQd_02WvfKaPKWOiy4FTHs1jIqq4=.e4e8d06c-7562-41d0-a8c0-03a19c216a1c@github.com>

On Tue, 29 Nov 2022 11:44:25 GMT, Johnny Lim <duke at openjdk.org> wrote:

>> Hello @izeye, for this pull request to be officially reviewed, the process requires a JBS issue to be filed and linked against this PR. I have created https://bugs.openjdk.org/browse/JDK-8297749 to track this change.
>> 
>> Please update the title of this PR to `8297749: Remove duplicate space in the ProtocolException message being thrown from HttpURLConnection` so that the necessary review process gets initiated.
>
> @jaikiran Thanks for the feedback! I updated the title as you suggested.

Thank you @izeye for these changes. I'll run some tests with this change, just to be sure that this doesn't break anything unexpectedly (like any tests that might be relying on this error message). I'll sponsor this once the tests complete.

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From jpai at openjdk.org  Wed Nov 30 00:58:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:58:16 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
Message-ID: <k_X8IpueizChCy57ErtXbE3ky21_TxHuCPWh1Z774Dk=.d7425587-eed6-4a6e-92d9-a2cd02fe0631@github.com>

On Tue, 29 Nov 2022 19:23:21 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds test for MIME application/wasm

Thank you for these changes. These look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11284

From jpai at openjdk.org  Wed Nov 30 00:58:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:58:16 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <GmT341ZjofvQrPDnzuTYjojRAKQLTi7-_r1b3yEed14=.41dfd2fa-c56b-4d7d-adf7-a189de726fcc@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
 <GmT341ZjofvQrPDnzuTYjojRAKQLTi7-_r1b3yEed14=.41dfd2fa-c56b-4d7d-adf7-a189de726fcc@github.com>
Message-ID: <EbyMi3n43b6-3wdm6X-CjMNt_DpFJJQYpA_GN9yD_1E=.aed609ef-40c1-4727-b88c-35641aaef44e@github.com>

On Tue, 29 Nov 2022 21:06:52 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

> ```
> I: Configuring ca-certificates...
> W: Failure while configuring base packages.  This will be re-attempted up to five times.
> W: See /home/runner/work/jdk/jdk/sysroot/debootstrap/debootstrap.log for details (possibly the package libasound2:riscv64 is at fault)
> ```
> 
> I'd say unrelated to the PR...?

Yes, you can ignore that failure. I'll be running these changes internally against various systems to make sure this doesn't show up any (system specific) issues (we have had such issues with this `Basic.java` test because it uses system level file type detector and some systems can return a different value than what the test expects).

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From jpai at openjdk.org  Wed Nov 30 01:12:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 01:12:20 GMT
Subject: RFR: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s) [v2]
In-Reply-To: <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
 <k0ra_T0NuEuT4Js4RwqvaCI3E6r5kLfqPMPqDf_A5MM=.9eca0903-56d2-4c20-96bb-2138d080d622@github.com>
Message-ID: <hq8lfs0AGE3tVAGd8wltnlHphtvUP0ZwSxNgwic4eJc=.a9785389-6c37-4d86-9755-e5bc3d6146dc@github.com>

On Tue, 29 Nov 2022 12:56:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
>> 
>> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
>> 
>> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thank you everyone for the reviews. The tier tests came back fine without any failures, with this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From jpai at openjdk.org  Wed Nov 30 01:14:27 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 01:14:27 GMT
Subject: Integrated: 8297311: Improve exception message thrown by
 java.net.HostPortrange::toLowerCase(String s)
In-Reply-To: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
References: <DlaVolowuARU-pNb-viTBGmArKl-K4lBN0sR60p6o1c=.cd8dfba2-c933-41ed-ac98-a191cf31af44@github.com>
Message-ID: <Mkjj-bbOX4BjPJSJgwKCynqXy9RtSPYKqZ1Ui5iV-KM=.e538f626-891b-408d-8a04-8953b5610cea@github.com>

On Tue, 29 Nov 2022 05:48:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to enhance an exception message in `java.net.HostPortrange::toLowerCase`, as requested in https://bugs.openjdk.org/browse/JDK-8297311?
> 
> The commit here includes (only) the character, which was found to be invalid, in the exception message. The character will be printed out in `\uXXXX` format to take into account any unprintable characters.
> 
> A new test has been introduced to verify that the introduction of this change doesn't introduce any regression and does indeed include the expected exception message.

This pull request has now been integrated.

Changeset: 9ced2ea0
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ced2ea0abdc0646a23873ab8ca443b6ca3e2e0a
Stats:     59 lines in 2 files changed: 58 ins; 0 del; 1 mod

8297311: Improve exception message thrown by java.net.HostPortrange::toLowerCase(String s)

Reviewed-by: dfuchs, michaelm, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/11407

From smarks at openjdk.org  Wed Nov 30 04:07:20 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 30 Nov 2022 04:07:20 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <yl-EhpqgisOsGCpZN4p0QKEWmARfvrF2n3-rFooXPn8=.7ecd8165-a25d-4e1e-b41e-8b307b28810c@github.com>

On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Various changes such as fixing spelling errors, addition of `@Serial`, removing redundant type arguments, using `instanceof` patterns, and using switch expressions seem fine to me. However, I'll defer to the judgment of the maintainers of this code.

If a larger-scale refactoring is done to reduce the redundancy of UOE-throwing for the platforms where SCTP isn't supported, I'd recommend doing it in a separate bug/PR.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java line 66:

> 64:             default -> throw new AssertionError(
> 65:                     "Unknown Association Change Event type: " + intEvent);
> 66:         };

You might consider lining up the arrows of the non-default cases. The default case is quite different so I think it's ok to have it unaligned, in fact that's probably preferable. Similar alignment can be done in a few other places.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 886:

> 884:                     resultContainer.getSendFailed(), attachment);
> 885:             case SHUTDOWN -> absHandler.handleNotification(
> 886:                     resultContainer.getShutdown(), attachment);

Unfortunately since the code in each case is (probably) too long to fit on a line, lining up the arrows doesn't help. I guess what's here is ok. If I were maintaining this code, I'd try to make the names shorter in order for everything to fit on a single line... but that's probably out of scope. Also unfortunately, even though the code in each case has a very similar structure, there is redundancy across the classes that makes unifying the cases difficult. Specifically, resultContainer.type() returns a type, which is switched on to call different getter methods on resultContainer; the return value in turn is passed to different but corresponding overloads of absHandler.handleNotification. It seems to me that there ought to be a better way to structure this. Possibly pass the absHandler to the resultContainer and have it call the appropriate handleNotification() overload depending on what type it is? But that's also probably out of scope for this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From vtewari at openjdk.org  Wed Nov 30 05:21:28 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 30 Nov 2022 05:21:28 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
Message-ID: <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>

On Mon, 28 Nov 2022 14:21:01 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently if a `HttpResonseInputStream` gets interrupted while reading it will just swallow the exception and continue,
>> 
>> This PR changes it to close the stream and throw an IOException, I added a test to cover this which just uses two threads to read the stream then interrupt it.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright year and formatting of a comment

src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 491:

> 489:                     // Throw InterruptedIOException where the initCause is
> 490:                     // set to the caught InterruptedException
> 491:                     throw Utils.toInterruptedIOException(ex);

Don't you think you need to  restores the interrupt status of the thread by invoking the Thread.currentThread().interrupt() method and allowing the caller to detect the interrupt if it needs to ?

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From duke at openjdk.org  Wed Nov 30 06:18:00 2022
From: duke at openjdk.org (Johnny Lim)
Date: Wed, 30 Nov 2022 06:18:00 GMT
Subject: Integrated: 8297749: Remove duplicate space in the ProtocolException
 message being thrown from HttpURLConnection
In-Reply-To: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
References: <szHTef08MLjmJ1mf3-HKGf8P73J0rq6KEd-54W_G0HM=.750e9d59-547f-41aa-b575-f0ae511283a8@github.com>
Message-ID: <uzNgvjdAP17u5enaxgPhcIoKaHKWBbE0SfKCpH02DMI=.72deef99-99cd-4ec9-8a27-ce6ad60474e6@github.com>

On Sat, 5 Nov 2022 00:01:15 GMT, Johnny Lim <duke at openjdk.org> wrote:

> This PR removes a duplicate space in `ProtocolException` message.

This pull request has now been integrated.

Changeset: 5dcaf6cc
Author:    Johnny Lim <izeye at naver.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5dcaf6cc6c3e9d73229ca6c2cc3b90ee37f5723b
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8297749: Remove duplicate space in the ProtocolException message being thrown from HttpURLConnection

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/11002

From pminborg at openjdk.org  Wed Nov 30 08:21:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:21:17 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <v-oAy5bhGxQDLLmJuOc9ShFUTA34sXnWHjPon_D__MI=.dc7b35c8-7799-42e1-aac8-a7df7199fa0c@github.com>

On Tue, 29 Nov 2022 17:44:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It is a bit unusual to use a local class as a holder class (the typical manner is to a have a private static final nested class) but we didn't have local classes until recently - so maybe that's OK. I assume there's only one version of that class and it is static?

As I understand it, there are zero instances of the class as it is only declared. The class only contains a class variable. In a recent Java version, classes that are "effectively static" (my wording) (i.e. does not refernece the outer class) does not hold a reference to the outer class. So, it is not static but in this case, I believe it does not matter because 1) it is never instantiated and 2) if it was indeed instantiated, it is "effectively static".

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 08:28:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:28:23 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <AEVKizNKVaINTSLAF14772wp4ubyf4Kx3N_SzXvYvGg=.a8212316-6464-4bcd-a6c9-0ab344909752@github.com>

On Tue, 29 Nov 2022 17:08:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> src/jdk.sctp/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java line 32:
> 
>> 30: public record SctpStdSocketOption<T>(String name,
>> 31:                                      Class<T> type,
>> 32:                                      int constValue)
> 
> This changes the implementation of `toString`, `equals` and `hashCode`. Have you verified that it is OK to do so?

I agree this might be an issue. Especially `toString` in this case might be problematic. I think the best course of action here would be to revert the changes proposed.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From michaelm at openjdk.org  Wed Nov 30 08:34:19 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 30 Nov 2022 08:34:19 GMT
Subject: RFR: 8297645: Drop the
 test/jdk/java/net/httpclient/reactivestreams-tck-tests/TckDriver.java test
In-Reply-To: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
References: <vRtDL1e9JUsCbx_bc3nD0k2DiNsyZkwHvqgnz8oTnOM=.5901434d-7db6-4c4e-ba3f-d2d20169a27e@github.com>
Message-ID: <GPc1v-Iu9ZdkSIplVrozP-IoU6wtZmkEaiNR7iMx5xQ=.79dbcfb9-069c-4f4d-9975-a30cb7b0c47c@github.com>

On Tue, 29 Nov 2022 17:50:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a fix that drops the HttpClient TckDiriver test. This test has been useful when developing the HTTP client APIs. However, it has become a burden to run this test, which is now the longest running HttpClient test. This change proposes to drop the test from the non regression test suite.

Marked as reviewed by michaelm (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11420

From pminborg at openjdk.org  Wed Nov 30 08:34:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 08:34:20 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <unkIuF6LxUE5TK43b7CF0Dda4eLRSzpXr8oAHBaRZ_w=.716bf4bd-5a05-42a7-952a-7aff5468ee83@github.com>
Message-ID: <i5VucbG7HYDTdoBADPh3cDttGEuv_qdoeKE1Tjo-F1A=.ab895de3-58a4-4372-be3f-c8b7e1b6e7ae@github.com>

On Tue, 29 Nov 2022 17:17:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 33:
> 
>> 31: import java.io.FileDescriptor;
>> 32: import java.io.IOException;
>> 33: import java.util.*;
> 
> It would be better to avoid wildcards in regular imports.

Agreed. I would have to find the settings in my IDE to prevent this automatic "feature".

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From michaelm at openjdk.org  Wed Nov 30 08:43:25 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 30 Nov 2022 08:43:25 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
Message-ID: <7DKKVwS3e6y8-6bzYeW7Uz529C_zcqY9TsAB6Dl9Tws=.c169049a-2bd2-41e4-b18d-14698b19300f@github.com>

On Tue, 29 Nov 2022 19:23:21 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds test for MIME application/wasm

Seems like a reasonable change. I added a comment to the bug report to the effect that there's an existing system property that might be useful here as well. "content.types.user.table"  overrides the location of the file being updated here. We're also going to look into updating that mechanism to load a separate file with additional entries to add to the default file.

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11284

From pminborg at openjdk.org  Wed Nov 30 09:03:26 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:03:26 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp
In-Reply-To: <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <jtlb_PFBXNxlpqUWndIzq90REudtQOGtoxGl3zHF_wg=.90a856b8-5c30-4d8f-b389-09342a478ec0@github.com>
 <9yk8TUxvPGC2gkULFMyTaprQ5WGiaJnaGBsJ4z1WQwM=.d9b3ba36-0219-40a0-80df-b3ff6c0fdb94@github.com>
Message-ID: <TsbLnHkN-WVVtV6hsz56N0ecG8KLeznZrVYU-9vTORY=.047a4d50-ee4a-4367-8539-2c0ff1aa6c6f@github.com>

On Tue, 29 Nov 2022 20:25:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.sctp/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 44:
>> 
>>> 42:  * Unimplemented.
>>> 43:  */
>>> 44: public class SctpChannelImpl extends SctpChannel {
>> 
>> Going a bit beyond just updating syntax; but that's a different PR...
>> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception.  There would less duplication for unsupported platforms.
>
>> There could be more sharing of the unsupported implementation if SctpChannel was not abstract and its method bodies threw the exception. There would less duplication for unsupported platforms.
> 
> I think this is accident of history. As I recall, the "unsupported implementation" was Windows only in JDK 6 but it has since been copied. It could be cleaned up.

Created https://bugs.openjdk.org/browse/JDK-8297822?filter=-2 and will move changes for this to a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:22:00 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:22:00 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v2]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert dedup and align switch cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/297be2af..e8040261

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=00-01

  Stats: 329 lines in 18 files changed: 48 ins; 64 del; 217 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From alanb at openjdk.org  Wed Nov 30 09:36:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 09:36:23 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v2]
In-Reply-To: <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <1M2pNVpv9PXpMylD_DupWO71l5SjoYvRYO0v4MhllWA=.af9cafbd-9e8e-4783-ace0-7ff6b8fe730b@github.com>
Message-ID: <gYCl3kYKQEjgP8n1ai1ItWgBCXqu0dEU52-eL-0_H64=.6f289330-f88d-495a-937b-8aa860766b6c@github.com>

On Wed, 30 Nov 2022 09:22:00 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert dedup and align switch cases

src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java line 37:

> 35:  * @since 1.7
> 36:  */
> 37: public final class SctpStandardSocketOptions {

com.sun.nio.sctp.SctpStandardSocketOptions is a JDK-specific API so technically changing it to final is an API change, although with no consequence as there is no accessible constructor.

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:52:51 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:52:51 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v3]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <nyRxSnxxdNRlssRiGW3K31_E5tAuf3wNA01HF0wZnhQ=.f8b6d9f3-f596-4ef5-b1e0-84be87fff9fd@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert formatting and add javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/e8040261..62058e4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=01-02

  Stats: 49 lines in 10 files changed: 2 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From pminborg at openjdk.org  Wed Nov 30 09:55:54 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 09:55:54 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v4]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <9vVr78KqmMFL_iy27oRp6yb3WLFQ2wSqedR5JtS4HZM=.0e2c1bf4-fe3c-47ec-bf9b-385998d1522c@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert more formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/62058e4b..eafd79ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From dfuchs at openjdk.org  Wed Nov 30 10:42:21 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Nov 2022 10:42:21 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
 <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>
Message-ID: <Z6H5WYuwnd5EYQnEt6rqoGQ1mR2vnl2aiMc1mdTDWg4=.d14d4ee4-bc4e-4b82-9230-54d2bae3c822@github.com>

On Wed, 30 Nov 2022 05:19:22 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright year and formatting of a comment
>
> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 491:
> 
>> 489:                     // Throw InterruptedIOException where the initCause is
>> 490:                     // set to the caught InterruptedException
>> 491:                     throw Utils.toInterruptedIOException(ex);
> 
> Don't you think you need to  restores the interrupt status of the thread by invoking the Thread.currentThread().interrupt() method and allowing the caller to detect the interrupt if it needs to ?

By convention, any method that exits by throwing an InterruptedException clears interrupt status when it does so. Since we're throwing InterruptedIOException here, I don't think we need to set the interrupt flag. But the caller might do so if they want.

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From dfuchs at openjdk.org  Wed Nov 30 11:03:19 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Nov 2022 11:03:19 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
 <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>
Message-ID: <uMVsyPyKrv3QOH0E0JeGJrQN7fdZSpQpyze11cbQrys=.5e1f398a-8ef4-4c6d-aac8-60d6d73fe7e7@github.com>

On Wed, 30 Nov 2022 05:19:22 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright year and formatting of a comment
>
> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 491:
> 
>> 489:                     // Throw InterruptedIOException where the initCause is
>> 490:                     // set to the caught InterruptedException
>> 491:                     throw Utils.toInterruptedIOException(ex);
> 
> Don't you think you need to  restores the interrupt status of the thread by invoking the Thread.currentThread().interrupt() method and allowing the caller to detect the interrupt if it needs to ?

Hmmm... Maybe a better solution would be to throw "ClosedByInterruptException" since we're also closing the input stream. And the specification of  "ClosedByInterruptException"  clearly state that the interrupt status of the thread will be preserved. Good question @vyommani .

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From dfuchs at openjdk.org  Wed Nov 30 12:00:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Nov 2022 12:00:20 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
Message-ID: <4G6KDkbUvjpIlTax7lh-3Aeo9jg785GUAfboRvwpXgo=.78d98716-db44-4fec-9d8f-a56c0d62f3d5@github.com>

On Tue, 29 Nov 2022 19:23:21 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds test for MIME application/wasm

test/jdk/java/nio/file/Files/probeContentType/Basic.java line 190:

> 188:                 new ExType("xlsx", List.of("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet")),
> 189:                 new ExType("7z", List.of("application/x-7z-compressed")),
> 190:                 new ExType("wasm", List.of("application/wasm")),

Could you please also add  8297609 to the `@bug` list on line 25?

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From stsypanov at openjdk.org  Wed Nov 30 12:12:59 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 30 Nov 2022 12:12:59 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v4]
In-Reply-To: <9vVr78KqmMFL_iy27oRp6yb3WLFQ2wSqedR5JtS4HZM=.0e2c1bf4-fe3c-47ec-bf9b-385998d1522c@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
 <9vVr78KqmMFL_iy27oRp6yb3WLFQ2wSqedR5JtS4HZM=.0e2c1bf4-fe3c-47ec-bf9b-385998d1522c@github.com>
Message-ID: <BZULPW06bZFzNBYeYc_86cKB8polzIZksoQMa1Nthac=.e8d75ba7-31d7-446d-9a73-aebb9513e490@github.com>

On Wed, 30 Nov 2022 09:55:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>> 
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
>> 
>> * Replacing duplicate code segments 
>> * Making certain fields final 
>> * Using enhanced switch 
>> * Using records 
>> * Fixing typos 
>> * Marking fields participating in serialisation with `@Serial` 
>> * Modernizing toString() implementations 
>> * Using pattern matching 
>> * Using diamond operators
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert more formatting

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 82:

> 80: 
> 81:     /* IDs of native threads doing send and receive, for signalling */
> 82:     private volatile long receiverThread = 0;

It's not necessary to explicitly initialize volatiles with default values, see https://bugs.openjdk.org/browse/JDK-8272756

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 1084:

> 1082:         IOUtil.load();   /* loads nio & net native libraries */
> 1083:         java.security.AccessController.doPrivileged(
> 1084:             new java.security.PrivilegedAction<>() {

Is it possible to use `import java.security.PrivilegedAction;` instead of fully-qualified name?

-------------

PR: https://git.openjdk.org/jdk/pull/11418

From vtewari at openjdk.org  Wed Nov 30 14:11:28 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 30 Nov 2022 14:11:28 GMT
Subject: RFR: 8294047: HttpResponseInputStream swallows interrupts [v4]
In-Reply-To: <uMVsyPyKrv3QOH0E0JeGJrQN7fdZSpQpyze11cbQrys=.5e1f398a-8ef4-4c6d-aac8-60d6d73fe7e7@github.com>
References: <8Zpyo3xuQEGsS-InxeMUNn54CxPG3axBGPTqinyo8yY=.c482c9ca-ffd0-4f4d-aa9d-3d22c2627574@github.com>
 <oVXlyoRGn1GC8DhXVZ6UkoL9F604ocaOkgc3waJzacE=.25c1e9ae-4ecc-43e9-93f9-bb9bd290f6d5@github.com>
 <mFIkZ0HhSQ3B8WHRSeak3lU0Y6T6zKQufDSrS-1iApI=.d6eb290e-0ee8-4547-930d-ac95be887344@github.com>
 <uMVsyPyKrv3QOH0E0JeGJrQN7fdZSpQpyze11cbQrys=.5e1f398a-8ef4-4c6d-aac8-60d6d73fe7e7@github.com>
Message-ID: <od_suGyzjsqgZIiZ5eGqngMI6rM6Qd_Rs9nLZ5KX32c=.9ce4f49b-b3e6-499a-be28-0f3a51d97fcd@github.com>

On Wed, 30 Nov 2022 11:00:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java line 491:
>> 
>>> 489:                     // Throw InterruptedIOException where the initCause is
>>> 490:                     // set to the caught InterruptedException
>>> 491:                     throw Utils.toInterruptedIOException(ex);
>> 
>> Don't you think you need to  restores the interrupt status of the thread by invoking the Thread.currentThread().interrupt() method and allowing the caller to detect the interrupt if it needs to ?
>
> Hmmm... Maybe a better solution would be to throw "ClosedByInterruptException" since we're also closing the input stream. And the specification of  "ClosedByInterruptException"  clearly state that the interrupt status of the thread will be preserved. Good question @vyommani .

I am not 100% sure but for me the best option is call close() and  just restore the interrupt status let the caller decide how to handle the interrupt.

-------------

PR: https://git.openjdk.org/jdk/pull/11323

From duke at openjdk.org  Wed Nov 30 14:43:44 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Wed, 30 Nov 2022 14:43:44 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v3]
In-Reply-To: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
Message-ID: <BZRh6qdZRDYqset_vrbH4ngGOGr0loRwqwZLVitxvE4=.2a3f0b14-b7ec-4a39-906f-6a45fa4a18df@github.com>

> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
> 
> # How to reproduce
> 
> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
> 
> ## Sources
> 
> `main.c`:
> 
> #include <stdio.h>
> 
> int main() {
>   printf("Hello browser debug console...\n");
> }
> 
> 
> `Server.java`:
> 
> import com.sun.net.httpserver.HttpServer;
> import com.sun.net.httpserver.SimpleFileServer;
> 
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.nio.file.Path;
> 
> import static java.lang.System.exit;
> import static java.lang.System.out;
> 
> public class Server {
>     public static void main(String... args) {
>         if (args.length != 2) {
>             out.println("Usage: java Server <port> <web dir path>");
>             exit(1);
>         }
>         final int port = Integer.parseInt(args[0]);
>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>         final Path root = Path.of(args[1]).toAbsolutePath();
>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>         server.start();
>     }
> }
> 
> ## Build
> 
> $ mkdir out
> $ emcc main.c -s WASM=1 -o out/main.html
> $ ls out/
> main.html  main.js  main.wasm
> 
> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
> 
> ## Execution
> 
> $ java --version
> openjdk 19.0.1 2022-10-18
> $ javac Server.java
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> 
> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
> 
> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
> 
> When I switch to the JDK patched with this patch and run the server again:
> 
> $ java Server 8888 ./out/
> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
> 
> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
> 
> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
> 
> Thank you for your time.
> 
> Cheers
> K.

Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:

  Adds 8297609 to @bug for tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11284/files
  - new: https://git.openjdk.org/jdk/pull/11284/files/77a4e79b..f0455fb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11284&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11284&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11284.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11284/head:pull/11284

PR: https://git.openjdk.org/jdk/pull/11284

From duke at openjdk.org  Wed Nov 30 14:43:47 2022
From: duke at openjdk.org (Michal Karm Babacek)
Date: Wed, 30 Nov 2022 14:43:47 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v2]
In-Reply-To: <4G6KDkbUvjpIlTax7lh-3Aeo9jg785GUAfboRvwpXgo=.78d98716-db44-4fec-9d8f-a56c0d62f3d5@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <KzPG0z3D5ImUug7Bgx0jkuRdUjNavgE8Xi4xXBpRm40=.3596a41f-5ffa-4451-abea-37898d58c80b@github.com>
 <4G6KDkbUvjpIlTax7lh-3Aeo9jg785GUAfboRvwpXgo=.78d98716-db44-4fec-9d8f-a56c0d62f3d5@github.com>
Message-ID: <o7oNh9AFxfzHFoYsX_S4KMoQ5C0kkPKdqL7f16O-F4c=.5ca3efa7-7387-4057-a82d-34feb6fbd017@github.com>

On Wed, 30 Nov 2022 11:57:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds test for MIME application/wasm
>
> test/jdk/java/nio/file/Files/probeContentType/Basic.java line 190:
> 
>> 188:                 new ExType("xlsx", List.of("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet")),
>> 189:                 new ExType("7z", List.of("application/x-7z-compressed")),
>> 190:                 new ExType("wasm", List.of("application/wasm")),
> 
> Could you please also add  8297609 to the `@bug` list on line 25?

@dfuch  Done.

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From dfuchs at openjdk.org  Wed Nov 30 15:02:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Nov 2022 15:02:33 GMT
Subject: RFR: 8297609: Add application/wasm MIME type for wasm file
 extension [v3]
In-Reply-To: <BZRh6qdZRDYqset_vrbH4ngGOGr0loRwqwZLVitxvE4=.2a3f0b14-b7ec-4a39-906f-6a45fa4a18df@github.com>
References: <I7c892bUiUFF1Y6_5uGPU2aZ0igVuy1Ny_8XW9WQkeM=.201faedb-dda0-42b0-b7b5-efd86cddc14c@github.com>
 <BZRh6qdZRDYqset_vrbH4ngGOGr0loRwqwZLVitxvE4=.2a3f0b14-b7ec-4a39-906f-6a45fa4a18df@github.com>
Message-ID: <4NA95u6-zTHWLF5FiKFYVtd_2fsxB6i--TFYdmddPxo=.1ecfabb6-8069-456b-829d-d76febd3f6cf@github.com>

On Wed, 30 Nov 2022 14:43:44 GMT, Michal Karm Babacek <duke at openjdk.org> wrote:

>> This PR adds a missing MIME: application/wasm and unifies the file format on tabs, as that seemed to be the winning side of the tabs/spaces war in this file.
>> 
>> # How to reproduce
>> 
>> You will need to compile a `.c` file to a `.wasm` binary. Use [Emscripten SDK](https://emscripten.org/docs/getting_started/downloads.html) for that or download the prebuilt files from this post, [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip),  if you choose to trust me with your browser...
>> 
>> ## Sources
>> 
>> `main.c`:
>> 
>> #include <stdio.h>
>> 
>> int main() {
>>   printf("Hello browser debug console...\n");
>> }
>> 
>> 
>> `Server.java`:
>> 
>> import com.sun.net.httpserver.HttpServer;
>> import com.sun.net.httpserver.SimpleFileServer;
>> 
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.nio.file.Path;
>> 
>> import static java.lang.System.exit;
>> import static java.lang.System.out;
>> 
>> public class Server {
>>     public static void main(String... args) {
>>         if (args.length != 2) {
>>             out.println("Usage: java Server <port> <web dir path>");
>>             exit(1);
>>         }
>>         final int port = Integer.parseInt(args[0]);
>>         final InetSocketAddress ADDR = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
>>         final Path root = Path.of(args[1]).toAbsolutePath();
>>         final HttpServer server = SimpleFileServer.createFileServer(ADDR, root, SimpleFileServer.OutputLevel.VERBOSE);
>>         out.printf("Starting serving files from %s dir: http://%s:%d\n", root, ADDR.getAddress().getHostAddress(), port);
>>         server.start();
>>     }
>> }
>> 
>> ## Build
>> 
>> $ mkdir out
>> $ emcc main.c -s WASM=1 -o out/main.html
>> $ ls out/
>> main.html  main.js  main.wasm
>> 
>> You can have these files here, built by me:  [out.zip](https://github.com/openjdk/jdk/files/10066496/out.zip)
>> 
>> ## Execution
>> 
>> $ java --version
>> openjdk 19.0.1 2022-10-18
>> $ javac Server.java
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> 
>> When I open my Firefox 106.0.5 (64-bit), I can see that the Java server offers the `.wasm` file with a suboptimal `application/octet-stream` MIME:
>> 
>> ![bad](https://user-images.githubusercontent.com/691097/203292673-dff79256-7286-42b1-9b72-60ff6e9aadd3.png)
>> 
>> When I switch to the JDK patched with this patch and run the server again:
>> 
>> $ java Server 8888 ./out/
>> Starting serving files from /tmp/hello_wasm/./out dir: http://127.0.0.1:8888
>> 
>> I can see that the `.wasm` file is properly served to Firefox as `application/wasm`:
>> 
>> ![good](https://user-images.githubusercontent.com/691097/203293296-77ff4913-b86d-45fe-976e-8cbcde79da36.png)
>> 
>> Thank you for your time.
>> 
>> Cheers
>> K.
>
> Michal Karm Babacek has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds 8297609 to @bug for tests

Thanks. LGTM - as long as Jaikiran's tests come back successful.

-------------

PR: https://git.openjdk.org/jdk/pull/11284

From pminborg at openjdk.org  Wed Nov 30 17:05:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 17:05:17 GMT
Subject: RFR: 8297822: De-duplicate code in module jdk.sctp
Message-ID: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>

This PR proposes merging logic and optimising three classes that exist for aix, maces and windows.

Optimisation will reduce byte code. Below is an example for one of the many methods optimised.

Before:

public void implCloseSelectableChannel() throws java.io.IOException;
  Code:
     0: new           #7                  // class java/lang/UnsupportedOperationException
     3: dup
     4: ldc           #11                 // String SCTP not supported on this platform
     6: invokespecial #13                 // Method java/lang/UnsupportedOperationException."<init>":(Ljava/lang/String;)V
     9: athrow


After:

public void implCloseSelectableChannel() throws java.io.IOException;
  Code:
     0: invokestatic  #16                 // Method sun/nio/ch/sctp/UnsupportedUtil.sctpUnsupported:()Ljava/lang/UnsupportedOperationException;
     3: athrow

-------------

Commit messages:
 - De-duplicate code in module jdk.sctp

Changes: https://git.openjdk.org/jdk/pull/11436/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297822
  Stats: 1226 lines in 13 files changed: 389 ins; 825 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11436.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11436/head:pull/11436

PR: https://git.openjdk.org/jdk/pull/11436

From pminborg at openjdk.org  Wed Nov 30 17:34:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 17:34:50 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <O_4QtLVtXPaRnaLB55n2OJvIrC7nVVtoomPKgGN8lpY=.e65580e4-a7ed-47b1-9e61-590646d0187d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

I've converted this PR to a draft because we want to wait for the PR_20 branch being merged [JEP 434](https://openjdk.org/jeps/434)

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From dfuchs at openjdk.org  Wed Nov 30 17:36:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Nov 2022 17:36:26 GMT
Subject: RFR: 8297822: De-duplicate code in module jdk.sctp
In-Reply-To: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
References: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
Message-ID: <Urwj_pHCzTbeBMa4FNdjD5600pBmqT3pXmBSFAC9_ss=.64dc144f-c8b7-4785-ada8-064938293308@github.com>

On Wed, 30 Nov 2022 16:54:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes merging logic and optimising three classes that exist for aix, maces and windows.
> 
> Optimisation will reduce byte code. Below is an example for one of the many methods optimised.
> 
> Before:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: new           #7                  // class java/lang/UnsupportedOperationException
>      3: dup
>      4: ldc           #11                 // String SCTP not supported on this platform
>      6: invokespecial #13                 // Method java/lang/UnsupportedOperationException."<init>":(Ljava/lang/String;)V
>      9: athrow
> 
> 
> After:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: invokestatic  #16                 // Method sun/nio/ch/sctp/UnsupportedUtil.sctpUnsupported:()Ljava/lang/UnsupportedOperationException;
>      3: athrow

Good to see all the duplication go away.

src/jdk.sctp/share/classes/sun/nio/ch/sctp/UnsupportedUtil.java line 1:

> 1: package sun.nio.ch.sctp;

Still need regular copyright header :-)

-------------

PR: https://git.openjdk.org/jdk/pull/11436

From alanb at openjdk.org  Wed Nov 30 18:15:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 18:15:36 GMT
Subject: RFR: 8297822: De-duplicate code in module jdk.sctp
In-Reply-To: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
References: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
Message-ID: <34bV9vU1oiKTb-l6WjSqUzl7_S6Lfd0kHuv0kR08ePw=.0d1529e6-1923-4523-bc4c-a7b45843c8b2@github.com>

On Wed, 30 Nov 2022 16:54:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes merging logic and optimising three classes that exist for aix, maces and windows.
> 
> Optimisation will reduce byte code. Below is an example for one of the many methods optimised.
> 
> Before:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: new           #7                  // class java/lang/UnsupportedOperationException
>      3: dup
>      4: ldc           #11                 // String SCTP not supported on this platform
>      6: invokespecial #13                 // Method java/lang/UnsupportedOperationException."<init>":(Ljava/lang/String;)V
>      9: athrow
> 
> 
> After:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: invokestatic  #16                 // Method sun/nio/ch/sctp/UnsupportedUtil.sctpUnsupported:()Ljava/lang/UnsupportedOperationException;
>      3: athrow

As the Solaris port is removed then it means the only implementation is on Linux. So one thing to try to is to rename src/jdk.sctp/unix to src/jdk.sctp/linux, src/jdk.sctp/windows/classes/sun/nio/ch/sctp/*  tosrc/jdk.sctp/share/classes/sun/nio/ch/sctp/*  and remove the src/jdk.sctp/macos and src/jdk.sctp/aix tree. If it works then it would avoid needing to have 3 copies of the "unsupported" implementation and avoid include UnsupportedXXX classes in the Linux implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/11436

From pminborg at openjdk.org  Wed Nov 30 18:34:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 18:34:15 GMT
Subject: RFR: 8297778: Modernize and improve module jdk.sctp [v5]
In-Reply-To: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
References: <afHhMDA4_LGE7LFz82RlVcsUNRCZBubbCp6I0_3UyzE=.26488793-0fdb-4bce-9103-e39e844f4fba@github.com>
Message-ID: <oIXfT91J00UzUpIe7UcRVNZ9rM-GQEEWLqXmcE1_0F0=.5262f015-2787-4c04-8348-212d603b9a52@github.com>

> This PR proposes a variety of modernisations to the `jdk.sctp` module.
> 
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several improvement areas were identified including: 
> 
> * Replacing duplicate code segments 
> * Making certain fields final 
> * Using enhanced switch 
> * Using records 
> * Fixing typos 
> * Marking fields participating in serialisation with `@Serial` 
> * Modernizing toString() implementations 
> * Using pattern matching 
> * Using diamond operators

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Minor updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11418/files
  - new: https://git.openjdk.org/jdk/pull/11418/files/eafd79ea..8cbc6edd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11418&range=03-04

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11418/head:pull/11418

PR: https://git.openjdk.org/jdk/pull/11418

From rriggs at openjdk.org  Wed Nov 30 18:45:17 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Nov 2022 18:45:17 GMT
Subject: RFR: 8297822: De-duplicate code in module jdk.sctp
In-Reply-To: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
References: <1wXtTlKD8nlGqC_OjlmMkxDtPh_WeO0PW62CMGO0lQM=.c2e6d4ce-ef19-4e2d-a9a7-1542225c3281@github.com>
Message-ID: <MBuq2JrNBha-WdYday0QWQeSnqyrYdX0celBGE9NyuY=.9e0639e6-dade-48de-8cfc-f085ae63d688@github.com>

On Wed, 30 Nov 2022 16:54:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes merging logic and optimising three classes that exist for aix, maces and windows.
> 
> Optimisation will reduce byte code. Below is an example for one of the many methods optimised.
> 
> Before:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: new           #7                  // class java/lang/UnsupportedOperationException
>      3: dup
>      4: ldc           #11                 // String SCTP not supported on this platform
>      6: invokespecial #13                 // Method java/lang/UnsupportedOperationException."<init>":(Ljava/lang/String;)V
>      9: athrow
> 
> 
> After:
> 
> public void implCloseSelectableChannel() throws java.io.IOException;
>   Code:
>      0: invokestatic  #16                 // Method sun/nio/ch/sctp/UnsupportedUtil.sctpUnsupported:()Ljava/lang/UnsupportedOperationException;
>      3: athrow

src/jdk.sctp/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 2:

> 1: /*
> 2:  * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved.

Please check the copyrights (2022), some look like they went back in time.

-------------

PR: https://git.openjdk.org/jdk/pull/11436