From jjiang at openjdk.java.net  Tue Dec  1 01:53:56 2020
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 1 Dec 2020 01:53:56 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>

On Sat, 21 Nov 2020 11:45:42 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Just a question.
Do we have clear guideline or requirement for using this new lang feature?
We know there are a lot of old switch-case blocks in the existing codes,
including source codes and test codes.

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

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

From pconcannon at openjdk.java.net  Tue Dec  1 12:07:57 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 1 Dec 2020 12:07:57 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v2]
In-Reply-To: <xwCLbC42-nf62CT_UV37yw0N3VgRlJ-YxKC0ho1-RD8=.9407c92e-a189-43ea-ad45-74ec0318ae4c@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <xwCLbC42-nf62CT_UV37yw0N3VgRlJ-YxKC0ho1-RD8=.9407c92e-a189-43ea-ad45-74ec0318ae4c@github.com>
Message-ID: <CnhHotuAcIHz_E7fx7jxGZwCBVkacTgpe37mrieAfCg=.089234a4-3f49-4066-9957-54d9b28c8302@github.com>

On Mon, 30 Nov 2020 13:04:11 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri 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.

src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 74:

> 72: 
> 73:     private String name(int i) {
> 74:         return switch (i + 1) {

Hi Kartik. I think it would improve the readability for each of the switch/case expressions if you tab aligned each of the cases, and place the default case on its own line e.g.

   
        
        return switch (i + 1) {
            case HEADER_TABLE_SIZE      -> "HEADER_TABLE_SIZE";
            case ENABLE_PUSH            -> "ENABLE_PUSH";
            case MAX_CONCURRENT_STREAMS -> "MAX_CONCURRENT_STREAMS";
            case INITIAL_WINDOW_SIZE    -> "INITIAL_WINDOW_SIZE";
            case MAX_FRAME_SIZE         -> "MAX_FRAME_SIZE";
            case MAX_HEADER_LIST_SIZE   -> "MAX_HEADER_LIST_SIZE";

            default -> "unknown parameter";
        };

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

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

From dfuchs at openjdk.java.net  Tue Dec  1 12:40:54 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 1 Dec 2020 12:40:54 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http
In-Reply-To: <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <hCXF_GToaz3J5CFGUgSwqaoM82mUu8LHcizAoJOlAbk=.af520e5a-6e61-4e18-af5a-4f2d1131f94d@github.com>
Message-ID: <kZ4tF8MrzOGPXFmgVitbDUMQFoAp1shdWIs-hmAguqc=.d754b826-7479-48e7-a84f-8ec795aadf41@github.com>

On Tue, 1 Dec 2020 01:51:35 GMT, John Jiang <jjiang at openjdk.org> wrote:

> Do we have clear guideline or requirement for using this new lang feature?
> We know there are a lot of old switch-case blocks in the existing codes,
> including source codes and test codes.

@johnshajiang I don't think we have any global guideline but in this specific case I agree that using switch expressions as proposed is making the code generally more readable, with maybe a few cases where it might not have improved readability as much (for instance I'm not a big fan of line 54 in that file: https://github.com/openjdk/jdk/pull/1364/files#diff-ae0f662913a65511f983a3f0f9a98b708c11906a6f87aa4c96ab6fc7abf5ae9f )

best regards,

-- daniel

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

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

From github.com+54955201+macarte at openjdk.java.net  Tue Dec  1 16:45:07 2020
From: github.com+54955201+macarte at openjdk.java.net (Mat Carter)
Date: Tue, 1 Dec 2020 16:45:07 GMT
Subject: RFR: 8255264: Support for identifying the full range of IPv4
 localhost addresses on Windows
Message-ID: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>

Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler)

This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows

IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to
127.255.255.255 inclusive.

The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change

Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address

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

Commit messages:
 - 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows

Changes: https://git.openjdk.java.net/jdk/pull/1523/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1523&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255264
  Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1523/head:pull/1523

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

From jamie.letual at gmail.com  Tue Dec  1 19:08:38 2020
From: jamie.letual at gmail.com (Jamie Le Tual)
Date: Tue, 1 Dec 2020 14:08:38 -0500
Subject: icmp and raw sockets on linux
In-Reply-To: <e97877b9-4c8b-81f8-933f-3d80a5b9963e@oracle.com>
References: <CADbpLFuTbR2PE5Y+tibOWwAK+BHGLsbt4t6SmA8HP5Renws5tA@mail.gmail.com>
 <c15979a1-9bdc-f3fe-3786-473130f2b32b@oracle.com>
 <CADbpLFvZDLy=enXRZysiEsd4qHRZ7KM7cZgHdryeFtn7vvq_cQ@mail.gmail.com>
 <e97877b9-4c8b-81f8-933f-3d80a5b9963e@oracle.com>
Message-ID: <CADbpLFtBmw3fcCh9nhSbMSywcwZjE0CkqTpDYzFZq3+QJnX0kQ@mail.gmail.com>

Hi Alan,
I received an email this morning saying my OCA had been processed, but that
it would perhaps take a couple of hours before a bot picks it up and I show
up on the OCA signatories page (no idea where that page is though).

I have also updated the patch in my pull request to cover ipv6 as well.

Test cases are forthcoming.


On Sun, 29 Nov 2020 at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 29/11/2020 14:54, Jamie Le Tual wrote:
>
> Although I've only just sent in the pdf form for an ora, I've already
> submitted a pull request, https://github.com/openjdk/jdk/pull/1502
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1502__;!!GqivPVa7Brio!JhGUqeElAhEy9M_c0xBiYFVZQXX0YeHTlOrypbtjph_VrhY7t4LmgPpmxNpSAwLCuA$>
> wherein an attempt is first made to use an IPPROTO_ICMP socket before
> falling back on RAW_SOCK and finally tcp echo.
>
> I suppose now I have to wait until I am able to open an issue in the bug
> tracker so I can associate the pull request to it.
>
> Does anyone know what a unit test for this might look like? To cover the
> use cases the code has to be invoked by both a privileged and unprivileged
> user, and I'm not sure how to go about setting up a unit test.
>
>
> I've created JDK-8257235 [1] to track this. One thing to understand is
> whether there is an equivalent for IPPROTO_ICMPV6. Sorry, I can't look at
> the patch or comment in the PR until the bot confirms that you have signed
> the OCA.
>
> Have you looked at the existing tests in test/jdk/java/net/InetAddress? It
> will be awkward to verify as the behaviour before/after will not be
> observable without looking at the network or system call trace.
>
> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8257235
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201201/5b0a1153/attachment.htm>

From dfuchs at openjdk.java.net  Tue Dec  1 21:27:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 1 Dec 2020 21:27:10 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

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

> 351:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
> 352:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
> 353:  *         ...

Hi Brad,

There's a missing closing parenthesis here on line 352. 

Additionally - the unicode characters in the string above will be substituted by the compiler before the API documentation is generated. I am suspecting that this is not what you want. If you want to see the literal unicode escape in the generated documentation, you will need to employ some tricks. One of them could be to use the unicode escape of \ instead of \ to prevent the compiler from interpreting \uabcd as a unicode escape.

Something like:

 *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
 *     if (unicodeString.equals("\u005cuabcd\u005cuabce\u005cuabcf")) {

would do the trick. Alternatively - this would probably work too:

 *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
 *     {@code if (unicodeString.equals("}{@code uabcd}{@code uabce}{@code uabcf"))} {

I realize none of these alternatives are ideal - maybe someone knows a better trick...

src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 146:

> 144:  *
> 145:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
> 146:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {

Same remark here

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:09 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:09 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
Message-ID: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>

Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.

Full details are available in:

- Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
- CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

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

Commit messages:
 - Code Review Comments 4
 - Code Review Comments #3
 - Code Review Comments #2
 - Code Review Comments
 - Seventh iteration
 - Sixth iteration
 - Fifth iteration
 - Fourth iteration
 - Third iteration
 - Second iteration
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b52f6c05...9e6f0a4f

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
 <IF8CAOxN_Rvsl2ZOSJhkbS-Gn_dl7eg7JX5Py2OXn5w=.dc373c3b-f80c-47ce-a0ce-a0abca052b71@github.com>
Message-ID: <iQOk4zo2TjYeFL-lQjLn7XaC7ULBV3DZkcw9QOHWn-A=.378cffd3-fc2b-4a84-8acb-44b072d6825b@github.com>

On Thu, 26 Nov 2020 10:33:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
>> 
>> Full details are available in:
>> 
>> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
>> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 353:
> 
>> 351:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>> 352:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
>> 353:  *         ...
> 
> Hi Brad,
> 
> There's a missing closing parenthesis here on line 352. 
> 
> Additionally - the unicode characters in the string above will be substituted by the compiler before the API documentation is generated. I am suspecting that this is not what you want. If you want to see the literal unicode escape in the generated documentation, you will need to employ some tricks. One of them could be to use the unicode escape of \ instead of \ to prevent the compiler from interpreting \uabcd as a unicode escape.
> 
> Something like:
> 
>  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>  *     if (unicodeString.equals("\u005cuabcd\u005cuabce\u005cuabcf")) {
> 
> would do the trick. Alternatively - this would probably work too:
> 
>  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>  *     {@code if (unicodeString.equals("}{@code uabcd}{@code uabce}{@code uabcf"))} {
> 
> I realize none of these alternatives are ideal - maybe someone knows a better trick...

I made this change in SSLParameters, and forgot that I had a similar change to make in SSLEngine/SSLSocket.

> src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 146:
> 
>> 144:  *
>> 145:  *     // MEETEI MAYEK LETTERS HUK UN I (Unicode 0xabcd->0xabcf)
>> 146:  *     if (unicodeString.equals("\uabcd\uabce\uabcf") {
> 
> Same remark here

Also fixed using \u005c.

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <T7m8sRkEeHWahPwFEFDe-ukadDcp7kFpNW4uqzED0s4=.4932d4b6-f616-4ba6-9a8a-327366ca5aa0@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

I am not able to see the comment here in github due to the Terms of Use issue flagged by github, but did get email with the issue so I'm hoping/assuming that the terms have been accepted.

For this test, I just took the standard JSSE test template and added the few lines to check for the proper ALPN exchange.

I'm 99% sure that for the JDK testsuite, the default Charset is UTF-8 which will accept ASCII values like this.  If not, there's going to be a lot more problems.  :)

Consulted with the Sustaining Team, they requested that this note not be included, as the versions are not yet known.

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

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

From wetmore at openjdk.java.net  Tue Dec  1 21:27:13 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 1 Dec 2020 21:27:13 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
 <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>
Message-ID: <po-_Vbi2Ng-mabLPoRZv_87XbM-DopXhNG3U_0ENQm4=.a6a0bc89-8650-42e4-9dfb-878223835e18@github.com>

On Thu, 26 Nov 2020 20:26:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
>> 
>> Full details are available in:
>> 
>> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
>> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 341:
> 
>> 339:  * The ApplicationProtocol {@code String} values returned by the methods in
>> 340:  * this class are in the network byte representation sent by the peer and
>> 341:  * may need to be converted to its Unicode format before use.  For example,
> 
> I think there are two possible directions to use the bytes, concerting application ALPN representation to network byte representation, or concerting network bytes to application representation.  The 1st sentence, I may focus on the the network byte representation description.
> 
> "The ApplicationProtocol {@code String} values returned by the methods in this class are in the network byte representation sent by the peer.  If an ALPN value is not encoded in network byte ..., an conversion may be required.  For example, ..."

Discussed with Xuelei, the concern was it wasn't clear that you could compare using byte[] or Strings, and possible byte encodings that might be received.  I believe these have been addressed in the current version.

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

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

From xuelei at openjdk.java.net  Tue Dec  1 21:27:12 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 1 Dec 2020 21:27:12 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <Fab8HTtGSj3t3eGDAFdIvXTkpmnmy7DXpgoN7APjWGs=.b0348486-0165-4fda-b819-845059e641e8@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

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

> 339:  * The ApplicationProtocol {@code String} values returned by the methods in
> 340:  * this class are in the network byte representation sent by the peer and
> 341:  * may need to be converted to its Unicode format before use.  For example,

I think there are two possible directions to use the bytes, concerting application ALPN representation to network byte representation, or concerting network bytes to application representation.  The 1st sentence, I may focus on the the network byte representation description.

"The ApplicationProtocol {@code String} values returned by the methods in this class are in the network byte representation sent by the peer.  If an ALPN value is not encoded in network byte ..., an conversion may be required.  For example, ..."

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

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

From xuelei at openjdk.java.net  Wed Dec  2 02:18:58 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Dec 2020 02:18:58 GMT
Subject: RFR: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <4S5Tvet2ywtZza1zto6XTi62wbHL4kqTbqtvDwK_hbg=.6e71357e-0f59-4895-9cb1-1cb63426b276@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

Marked as reviewed by xuelei (Reviewer).

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

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

From wetmore at openjdk.java.net  Wed Dec  2 04:17:59 2020
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 2 Dec 2020 04:17:59 GMT
Subject: Integrated: 8254631: Better support ALPN byte wire values in SunJSSE
In-Reply-To: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
References: <8x_1P0q2OS9ouxFUblViitAkQG8xZ8l_hVTXxRPtaZY=.727f7491-5cf9-43f7-9947-edbc08d436cf@github.com>
Message-ID: <ZCJq8GDjts0vDcdy2cVetasHRVVFTGQViKy63Fl1v94=.e0aef136-1802-4fa3-9293-d0cf581a0813@github.com>

On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
> 
> Full details are available in:
> 
> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817

This pull request has now been integrated.

Changeset: fe5cccc1
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe5cccc1
Stats:     451 lines in 6 files changed: 440 ins; 1 del; 10 mod

8254631: Better support ALPN byte wire values in SunJSSE

Reviewed-by: xuelei, dfuchs

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 09:26:11 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 09:26:11 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v3]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <AMNvpmPxqHpk9jo5D-Xkr0qErLjYp61j8JRalOA843w=.fe0f0790-8c8f-47ad-b219-f325d58b1f62@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:

  Vertically align statements in switch expressions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/542298e0..7fa11daf

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

  Stats: 74 lines in 14 files changed: 14 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1364/head:pull/1364

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 09:42:09 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 09:42:09 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Kartik Ohri 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:

  Vertically align statements in switch expressions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/7fa11daf..3e667427

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

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

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

From github.com+55101029+jamieletual at openjdk.java.net  Wed Dec  2 13:31:02 2020
From: github.com+55101029+jamieletual at openjdk.java.net (Jamie Le Tual)
Date: Wed, 2 Dec 2020 13:31:02 GMT
Subject: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an
 IPPROTO_ICMP socket type before attempting RAW_SOCK
Message-ID: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>

Users have been able to send ICMP packets without the need for root privileges or the CAP_NET_RAW capability since at least kernel 3.11.

For some time now, if the kernel parameter net.ipv4.ping_group_range included the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then the packet would>
It's important to note that the both the checksum and ident field are overwritten by the kernel when this is done.

Newer distributions are now setting the default value of net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and Ubuntu 20.04 for example) so it can b>

Also of note is the that this is also implemented in MacOS.

This patch proposes attempting to use IPPROTO_ICMP first, and then fall back to attempting a raw socket and ultimately failing over to tcp echo.
This patch also alters the logic for identifying icmp reply packets, since the kernel overwrites id ident field when using the IPPROTO_ICMP protocol.
The method is similar to that used by the ping(8) utility in the iputils package, where we compare data in the icmp_data member of the icmp struct
to identify the packet as our response. The ping utility compares the timeval, whereas this patch proposes to compare both the timeval and the user's pid.

Please not that my OCA has been sent in and is pending.

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

Commit messages:
 - ipv6 working now
 - fixed misplaced parenthesis in ipv6, cleared up manipulation of pid
 - fixed a misplaced parenthesis
 - ipv6 changes for ipproto_icmp socket for isReachable
 - Update Inet4AddressImpl.c
 - Try to use IPPROTO_ICMP socket type first before attempting to use a RAW_SOCK in isReachable

Changes: https://git.openjdk.java.net/jdk/pull/1502/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1502&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257235
  Stats: 58 lines in 2 files changed: 29 ins; 5 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1502/head:pull/1502

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

From robilad at openjdk.java.net  Wed Dec  2 13:34:00 2020
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Wed, 2 Dec 2020 13:34:00 GMT
Subject: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an
 IPPROTO_ICMP socket type before attempting RAW_SOCK
In-Reply-To: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
References: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
Message-ID: <OrYZzmF512t5CuYNDklO8Ox6DeELIhTrEBhAKmF5N0I=.a1811dc2-8a1b-452e-9606-070e4d0a9e12@github.com>

On Sun, 29 Nov 2020 07:54:23 GMT, Jamie Le Tual <github.com+55101029+jamieletual at openjdk.org> wrote:

> Users have been able to send ICMP packets without the need for root privileges or the CAP_NET_RAW capability since at least kernel 3.11.
> 
> For some time now, if the kernel parameter net.ipv4.ping_group_range included the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then the packet would>
> It's important to note that the both the checksum and ident field are overwritten by the kernel when this is done.
> 
> Newer distributions are now setting the default value of net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and Ubuntu 20.04 for example) so it can b>
> 
> Also of note is the that this is also implemented in MacOS.
> 
> This patch proposes attempting to use IPPROTO_ICMP first, and then fall back to attempting a raw socket and ultimately failing over to tcp echo.
> This patch also alters the logic for identifying icmp reply packets, since the kernel overwrites id ident field when using the IPPROTO_ICMP protocol.
> The method is similar to that used by the ping(8) utility in the iputils package, where we compare data in the icmp_data member of the icmp struct
> to identify the packet as our response. The ping utility compares the timeval, whereas this patch proposes to compare both the timeval and the user's pid.
> 
> Please not that my OCA has been sent in and is pending.

Thank you for sending in an OCA for processing, Jamie, your account has now been verified.

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

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

From chegar at openjdk.java.net  Wed Dec  2 16:17:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 2 Dec 2020 16:17:58 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri 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.

I think that the actual source changes look good.

A few notes:
1. there are whitespace issues. jcheck is failing.
2. Please so not force push - just push. Force push messes up prior comments in the thread.

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

Marked as reviewed by chegar (Reviewer).

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

From dfuchs at openjdk.java.net  Wed Dec  2 16:25:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 16:25:59 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri 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.

src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 82:

> 80:             case MAX_HEADER_LIST_SIZE ->    "MAX_HEADER_LIST_SIZE";
> 81:             
> 82:             default -> "unknown parameter";

> Check failure on line 81 in src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java
> openjdk / jcheck
> 
> Whitespace error
> 
> Column 0: trailing whitespace
> ...

WRT to whitespace errors detected by `jcheck`, note that you can fix them by running the script:

make/scripts/normalizer.pl

on this file.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:17 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:17 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:

  Align -> and remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1364/files
  - new: https://git.openjdk.java.net/jdk/pull/1364/files/3e667427..e73ab02b

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

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:18 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:18 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <MibLPU47_Ts4ihU02WU2ujSZfFzS9ap0FPJHRMQN9Fo=.21bbcc3f-4813-40e0-b14b-bb79cbbacb29@github.com>
Message-ID: <I5Dl-JscFeCmHxsOGiaxjSD2da4-GcEu9_OHDCWze98=.3d9835b8-6df8-4e16-9352-eec885be4efa@github.com>

On Wed, 2 Dec 2020 16:15:13 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Kartik Ohri 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.
>
> I think that the actual source changes look good.
> 
> A few notes:
> 1. there are whitespace issues. jcheck is failing.
> 2. Please do not force push - just push. Force push messes up prior comments in the thread.

@ChrisHegarty Thanks for the review. I'll keep in mind not to use force push again.

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

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

From pconcannon at openjdk.java.net  Wed Dec  2 16:34:19 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 2 Dec 2020 16:34:19 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
Message-ID: <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri 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.

src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:

> 117:         while (canContinueParsing(input)) {
> 118:             switch (state) {
> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;

Looks good. Although, I think you can improve it further if you align the lambda operators as well

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:20 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:20 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
Message-ID: <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>

On Wed, 2 Dec 2020 16:26:43 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Kartik Ohri 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.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:
> 
>> 117:         while (canContinueParsing(input)) {
>> 118:             switch (state) {
>> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;
> 
> Looks good. Although, I think you can improve it further if you align the lambda operators as well

Yes right. Just noticed I had missed that. Fixed in latest commit :)

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Wed Dec  2 16:34:21 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Wed, 2 Dec 2020 16:34:21 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <2HBrF1PWvuPhhNNRb2WB2Jw_6d3HeoCLc1UM7c_miCs=.6bd5abb1-e60e-4cb3-99a9-029eba85718e@github.com>
Message-ID: <vZEoCuY6RoxhNj69TO7ovTqg1_J_6xz__iIkd_Lw0II=.f33cdf38-4b69-4d51-ab12-068d0698fa49@github.com>

On Wed, 2 Dec 2020 16:23:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kartik Ohri 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.
>
> src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java line 82:
> 
>> 80:             case MAX_HEADER_LIST_SIZE ->    "MAX_HEADER_LIST_SIZE";
>> 81:             
>> 82:             default -> "unknown parameter";
> 
>> Check failure on line 81 in src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java
>> openjdk / jcheck
>> 
>> Whitespace error
>> 
>> Column 0: trailing whitespace
>> ...
> 
> WRT to whitespace errors detected by `jcheck`, note that you can fix them by running the script:
> 
> make/scripts/normalizer.pl
> 
> on this file.

That's handy. Thanks!

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

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

From dfuchs at openjdk.java.net  Wed Dec  2 16:39:58 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 16:39:58 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
Message-ID: <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>

On Wed, 2 Dec 2020 16:34:17 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi!
>> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
>> Regards,
>> Kartik
>
> Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align -> and remove trailing whitespace

Marked as reviewed by dfuchs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Wed Dec  2 16:40:01 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 2 Dec 2020 16:40:01 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v4]
In-Reply-To: <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <JZYkVEGlc3YPHCr7J3hTAka_E9xda3itk2FyCUkNFQU=.d5a6be29-1c48-4e1f-b4c8-da179628b459@github.com>
 <4jfN-RsC9xt-Wm_Ri8JfFu8AcjDealEpGdnuG2bLkls=.c2839335-ff6d-4272-be67-1aeb98f11ce1@github.com>
 <Hb9Cy3qCRFrOSytrZ6PT1SzQ4T-la5MLyp2Mw4XE6Lk=.300e2833-d7d6-4e8b-89d2-801c59a53812@github.com>
Message-ID: <LwCEPGKqk6aAq2fNJNiVIQDgm1ktaLsv_DoN9ZtApGc=.378c3a12-8b2b-4543-9560-8eeb5de4d843@github.com>

On Wed, 2 Dec 2020 16:28:44 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1HeaderParser.java line 119:
>> 
>>> 117:         while (canContinueParsing(input)) {
>>> 118:             switch (state) {
>>> 119:                 case INITIAL ->                                     state = State.STATUS_LINE;
>> 
>> Looks good. Although, I think you can improve it further if you align the lambda operators as well
>
> Yes right. Just noticed I had missed that. Fixed in latest commit :)

Looks much better, Kartik. Thanks

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

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

From dfuchs at openjdk.java.net  Wed Dec  2 17:05:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 17:05:10 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try
 throwing in GET_BODY"
Message-ID: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>

Hi,

Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
connection will be closed by the test server if the test server receives a RESET from the client
after the stream has been closed.

This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
the debug traces have eventually revealed what was the issue:

DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
TestServer: Unexpected frame on: 24
RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
Http server reader thread shutdown
java.io.IOException: Unexpected frame
at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
Server connection to /127.0.0.1:39830 stopping. 5 streams

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

Commit messages:
 - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"

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

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

From dfuchs at openjdk.java.net  Wed Dec  2 17:21:08 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Dec 2020 17:21:08 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY" [v2]
In-Reply-To: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
Message-ID: <MH0k8ncCKy-rNZpOU0tIWK4TkVZl0s80otpARwOsxyk=.6b5a0f57-46e0-4497-8a6b-3fbcfde865b7@github.com>

> Hi,
> 
> Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
> connection will be closed by the test server if the test server receives a RESET from the client
> after the stream has been closed.
> 
> This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
> the debug traces have eventually revealed what was the issue:
> 
> DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> TestServer: Unexpected frame on: 24
> RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> Http server reader thread shutdown
> java.io.IOException: Unexpected frame
> at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
> at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
> Server connection to /127.0.0.1:39830 stopping. 5 streams

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

  8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
  
  Ammended fix to take into account reset frames received on either server streams
  or client streams.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1567/files
  - new: https://git.openjdk.java.net/jdk/pull/1567/files/559d9923..0d15b660

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec  3 18:31:03 2020
From: github.com+741251+turbanoff at openjdk.java.net (Turbanov Andrey)
Date: Thu, 3 Dec 2020 18:31:03 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
Message-ID: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>

Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`

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

Commit messages:
 - [PATCH] Fix incorrect format string in Http1HeaderParser

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

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

From shade at openjdk.java.net  Thu Dec  3 18:31:03 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 3 Dec 2020 18:31:03 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
Message-ID: <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>

On Sat, 28 Nov 2020 19:42:01 GMT, Turbanov Andrey <github.com+741251+turbanoff at openjdk.org> wrote:

> Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`

Submitted: https://bugs.openjdk.java.net/browse/JDK-8257707 -- rename this PR to "8257707: Fix incorrect format string in Http1HeaderParser" to get it hooked here. Also, merge from master to get Windows builds fixed and re-tested.

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

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

From dfuchs at openjdk.java.net  Thu Dec  3 19:03:58 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 3 Dec 2020 19:03:58 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>
Message-ID: <4KSXFTDE_Kifi7WMK9z05OrdJBVV0W8ttTi3OInBkdo=.ffb6ad0a-33b7-493e-bd60-bac189f1211e@github.com>

On Thu, 3 Dec 2020 17:42:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`
>
> Submitted: https://bugs.openjdk.java.net/browse/JDK-8257707 -- rename this PR to "8257707: Fix incorrect format string in Http1HeaderParser" to get it hooked here. Also, merge from master to get Windows builds fixed and re-tested.

Hi Andrei,

Thanks for finding this. Could you run the HttpClient tests - and if they pass I'll sponsor the changes.

jtreg  -verbose:summary -a -ea -esa -agentvm -conc:4 -ignore:quiet -timeout:2 -jdk:<path to the jdk you just built> test/jdk/java/net/httpclient

Alternatively you can run tier2 tests - which include the HttpClient changes:

make test-tier2

(but that's going to run many more tests)

best regards,

-- daniel

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec  3 20:07:58 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 3 Dec 2020 20:07:58 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <4KSXFTDE_Kifi7WMK9z05OrdJBVV0W8ttTi3OInBkdo=.ffb6ad0a-33b7-493e-bd60-bac189f1211e@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>
 <4KSXFTDE_Kifi7WMK9z05OrdJBVV0W8ttTi3OInBkdo=.ffb6ad0a-33b7-493e-bd60-bac189f1211e@github.com>
Message-ID: <lbblrkPqPwOFED_kjuzEk7KuW9IGGJbjnts2biCep_U=.1e819873-97bb-4f31-a5ec-aed320dda948@github.com>

On Thu, 3 Dec 2020 19:01:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Submitted: https://bugs.openjdk.java.net/browse/JDK-8257707 -- rename this PR to "8257707: Fix incorrect format string in Http1HeaderParser" to get it hooked here. Also, merge from master to get Windows builds fixed and re-tested.
>
> Hi Andrey,
> 
> Thanks for finding this. Could you run the HttpClient tests - and if they pass I'll sponsor the changes.
> 
> jtreg  -verbose:summary -a -ea -esa -agentvm -conc:4 -ignore:quiet -timeout:2 -jdk:<path to the jdk you just built> test/jdk/java/net/httpclient
> 
> Alternatively you can run tier2 tests - which include the HttpClient changes:
> 
> make test-tier2
> 
> (but that's going to run many more tests)
> 
> best regards,
> 
> -- daniel

make test-tier2 fails with error on my machine: :(
user at WORK-PC /cygdrive/f/Projects/official_openjdk
$ make test-tier2
Building target 'test-tier2' in configuration 'windows-x86_64-server-release'
Compiling 127 files for java.compiler
Compiling 10 files for java.instrument
Compiling 18 files for java.datatransfer
Compiling 35 files for java.logging
Compiling 330 files for java.management
Compiling 141 files for java.net.http
Compiling 5 files for java.transaction.xa
Compiling 15 files for java.scripting
Compiling 22 files for java.smartcardio
Compiling 204 files for jdk.internal.vm.ci
Compiling 24 files for jdk.management
Compiling 9 files for jdk.unsupported
Compiling 60 files for jdk.internal.jvmstat
Compiling 131 files for jdk.charsets
Compiling 35 files for jdk.crypto.ec
Compiling 11 files for jdk.crypto.mscapi
Compiling 68 files for jdk.dynalink
Compiling 403 files for jdk.compiler
Compiling 3 files for jdk.internal.ed
Compiling 44 files for jdk.httpserver
Compiling 59 files for jdk.incubator.foreign
Compiling 50 files for jdk.incubator.vector
Compiling 51 files for jdk.internal.opt
Compiling 30 files for jdk.jartool
Compiling 109 files for jdk.internal.le
Compiling 1 files for jdk.jdwp.agent
Compiling 201 files for jdk.jfr
Compiling 4 files for jdk.jsobject
Compiling 8 files for jdk.net
Compiling 1814 files for jdk.localedata
Compiling 2 files for jdk.nio.mapmode
Compiling 25 files for jdk.sctp
Compiling 14 files for jdk.zipfs
Compiling 30 files for java.security.sasl
Compiling 15 files for jdk.attach
Compiling 74 files for jdk.crypto.cryptoki
Compiling 14 files for jdk.management.jfr
Compiling 136 files for jdk.jdeps
Compiling 198 files for java.naming
Compiling 40 files for jdk.jcmd
Compiling 256 files for jdk.jdi
Compiling 131 files for java.rmi
Compiling 82 files for jdk.jlink
Compiling 224 files for java.security.jgss
Compiling 16 files for jdk.naming.dns
Compiling 16 files for java.management.rmi
Compiling 11 files for jdk.jstatd
Compiling 8 files for jdk.naming.rmi
Compiling 31 files for jdk.management.agent
Compiling 30 files for jdk.security.auth
Compiling 16 files for jdk.security.jgss
Compiling 1845 files for java.xml
./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory
make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/f/Projects/official_openjdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/bytecodeInterpreterWithChecks.obj] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'test-tier2' in configuration 'windows-x86_64-server-release' (exit code 2)
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_bytecodeInterpreterWithChecks.obj:
bytecodeInterpreterWithChecks.cpp
./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory

* All command lines available in /cygdrive/f/Projects/official_openjdk/build/windows-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:315: main] ?????? 2
make: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:186: test-tier2] ?????? 2

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

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

From ysuenaga at openjdk.java.net  Fri Dec  4 03:17:00 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 4 Dec 2020 03:17:00 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream() leaks
 when IOE happens
Message-ID: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>

`InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.

I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.


# How to reproduce:

Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.

import java.io.*;
import java.net.*;
import java.net.http.*;

public class Test{

  private static class TestInputStream extends InputStream{

    public TestInputStream(){
      super();
      System.out.println("test c'tor");
    }

    @Override
    public int read() throws IOException{
      System.out.println("read called");
      throw new IOException("test");
    }

    @Override
    public void close() throws IOException{
      System.out.println("close called");
      super.close();
    }

  }

  public static void main(String[] args) throws Exception{
    var http = HttpClient.newHttpClient();
    var request = HttpRequest.newBuilder()
                             .uri(URI.create("http://httpbin.org/post"))
                             .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
                             .build();
    http.send(request, HttpResponse.BodyHandlers.discarding());
    System.out.println("Press any key to exit...");
    System.in.read();
  }
}

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

Commit messages:
 - 8257736: InputStream from BodyPublishers.ofInputStream() leaks when IOE happens

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

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

From ysuenaga at openjdk.java.net  Fri Dec  4 03:17:01 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 4 Dec 2020 03:17:01 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <qD-9Ks9imM3I1yNj_6Eg3O134Jz0GuJ45R2Mm0ieX98=.1bb3e49d-750a-40f8-bc80-0a504e6efc3d@github.com>

On Fri, 4 Dec 2020 00:47:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

Test failure in HotSpot on macOS does not seem to be  caused by this change.

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

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

From shade at openjdk.java.net  Fri Dec  4 06:35:55 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Dec 2020 06:35:55 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <lbblrkPqPwOFED_kjuzEk7KuW9IGGJbjnts2biCep_U=.1e819873-97bb-4f31-a5ec-aed320dda948@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>
 <4KSXFTDE_Kifi7WMK9z05OrdJBVV0W8ttTi3OInBkdo=.ffb6ad0a-33b7-493e-bd60-bac189f1211e@github.com>
 <lbblrkPqPwOFED_kjuzEk7KuW9IGGJbjnts2biCep_U=.1e819873-97bb-4f31-a5ec-aed320dda948@github.com>
Message-ID: <l1Oiq5OP5IGj8JvKxFWrgAjJ162flX07M3rmoXQ5UOA=.c2a3630c-206f-416e-85b9-76b927bd69c8@github.com>

On Thu, 3 Dec 2020 20:05:36 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_objs_bytecodeInterpreterWithChecks.obj:
> bytecodeInterpreterWithChecks.cpp
> ./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory

That's the build failure, actually, and `bytecodeInterpreterWithChecks.cpp` should have been long gone. Run `git clean` on your repo?

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

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

From shade at openjdk.java.net  Fri Dec  4 06:46:55 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Dec 2020 06:46:55 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <l1Oiq5OP5IGj8JvKxFWrgAjJ162flX07M3rmoXQ5UOA=.c2a3630c-206f-416e-85b9-76b927bd69c8@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <CHn3usgN3Y-DfEv3ErmMr8JEJUOkIJmNZuHRRQavaNY=.76d5e425-6d17-4c76-8167-93087ec65bbb@github.com>
 <4KSXFTDE_Kifi7WMK9z05OrdJBVV0W8ttTi3OInBkdo=.ffb6ad0a-33b7-493e-bd60-bac189f1211e@github.com>
 <lbblrkPqPwOFED_kjuzEk7KuW9IGGJbjnts2biCep_U=.1e819873-97bb-4f31-a5ec-aed320dda948@github.com>
 <l1Oiq5OP5IGj8JvKxFWrgAjJ162flX07M3rmoXQ5UOA=.c2a3630c-206f-416e-85b9-76b927bd69c8@github.com>
Message-ID: <ai2I8pWmCbCj7QcD0H1Gvxn4VmeK_almfATWb2xvr9I=.c10bc1a4-9652-447b-a5b8-ec4213cabf16@github.com>

On Fri, 4 Dec 2020 06:33:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> make test-tier2 fails with error on my machine: :(
>> user at WORK-PC /cygdrive/f/Projects/official_openjdk
>> $ make test-tier2
>> Building target 'test-tier2' in configuration 'windows-x86_64-server-release'
>> Compiling 127 files for java.compiler
>> Compiling 10 files for java.instrument
>> Compiling 18 files for java.datatransfer
>> Compiling 35 files for java.logging
>> Compiling 330 files for java.management
>> Compiling 141 files for java.net.http
>> Compiling 5 files for java.transaction.xa
>> Compiling 15 files for java.scripting
>> Compiling 22 files for java.smartcardio
>> Compiling 204 files for jdk.internal.vm.ci
>> Compiling 24 files for jdk.management
>> Compiling 9 files for jdk.unsupported
>> Compiling 60 files for jdk.internal.jvmstat
>> Compiling 131 files for jdk.charsets
>> Compiling 35 files for jdk.crypto.ec
>> Compiling 11 files for jdk.crypto.mscapi
>> Compiling 68 files for jdk.dynalink
>> Compiling 403 files for jdk.compiler
>> Compiling 3 files for jdk.internal.ed
>> Compiling 44 files for jdk.httpserver
>> Compiling 59 files for jdk.incubator.foreign
>> Compiling 50 files for jdk.incubator.vector
>> Compiling 51 files for jdk.internal.opt
>> Compiling 30 files for jdk.jartool
>> Compiling 109 files for jdk.internal.le
>> Compiling 1 files for jdk.jdwp.agent
>> Compiling 201 files for jdk.jfr
>> Compiling 4 files for jdk.jsobject
>> Compiling 8 files for jdk.net
>> Compiling 1814 files for jdk.localedata
>> Compiling 2 files for jdk.nio.mapmode
>> Compiling 25 files for jdk.sctp
>> Compiling 14 files for jdk.zipfs
>> Compiling 30 files for java.security.sasl
>> Compiling 15 files for jdk.attach
>> Compiling 74 files for jdk.crypto.cryptoki
>> Compiling 14 files for jdk.management.jfr
>> Compiling 136 files for jdk.jdeps
>> Compiling 198 files for java.naming
>> Compiling 40 files for jdk.jcmd
>> Compiling 256 files for jdk.jdi
>> Compiling 131 files for java.rmi
>> Compiling 82 files for jdk.jlink
>> Compiling 224 files for java.security.jgss
>> Compiling 16 files for jdk.naming.dns
>> Compiling 16 files for java.management.rmi
>> Compiling 11 files for jdk.jstatd
>> Compiling 8 files for jdk.naming.rmi
>> Compiling 31 files for jdk.management.agent
>> Compiling 30 files for jdk.security.auth
>> Compiling 16 files for jdk.security.jgss
>> Compiling 1845 files for java.xml
>> ./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory
>> make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/f/Projects/official_openjdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/bytecodeInterpreterWithChecks.obj] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> 
>> ERROR: Build failed for target 'test-tier2' in configuration 'windows-x86_64-server-release' (exit code 2)
>> Stopping sjavac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target hotspot_variant-server_libjvm_objs_bytecodeInterpreterWithChecks.obj:
>> bytecodeInterpreterWithChecks.cpp
>> ./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory
>> 
>> * All command lines available in /cygdrive/f/Projects/official_openjdk/build/windows-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> Hint: Try searching the build log for '] Error'.
>> Hint: See doc/building.html#troubleshooting for assistance.
>> 
>> make[1]: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:315: main] ?????? 2
>> make: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:186: test-tier2] ?????? 2
>
>> === Output from failing command(s) repeated here ===
>> * For target hotspot_variant-server_libjvm_objs_bytecodeInterpreterWithChecks.obj:
>> bytecodeInterpreterWithChecks.cpp
>> ./build/windows-x86_64-server-release/hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp(3): fatal error C1083: Cannot open include file: 'interpreter/bytecodeInterpreter.cpp': No such file or directory
> 
> That's the build failure, actually, and `bytecodeInterpreterWithChecks.cpp` should have been long gone. Run `git clean` on your repo?

FWIW, this passes with the patch:

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=java/net/httpclient
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/net/httpclient                  219   219     0     0   
==============================
TEST SUCCESS

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

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

From shade at openjdk.java.net  Fri Dec  4 08:38:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Dec 2020 08:38:59 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
Message-ID: <oc2rO12E9RoSCFHJj9zeo6OPAu8z7FALeMyKJrIe6pw=.e3608e97-9cf1-4f1f-a372-b1bd3d97e024@github.com>

On Sat, 28 Nov 2020 19:42:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`

Looks good to me.

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

Marked as reviewed by shade (Reviewer).

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

From shade at openjdk.java.net  Fri Dec  4 08:49:55 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Dec 2020 08:49:55 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <oc2rO12E9RoSCFHJj9zeo6OPAu8z7FALeMyKJrIe6pw=.e3608e97-9cf1-4f1f-a372-b1bd3d97e024@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <oc2rO12E9RoSCFHJj9zeo6OPAu8z7FALeMyKJrIe6pw=.e3608e97-9cf1-4f1f-a372-b1bd3d97e024@github.com>
Message-ID: <yLc0Q17xTiKlBY44wvkVKjYwzb9nBVQY2hrJ9vf9vzw=.b9d7439c-59a6-4732-b9ff-fbe79a010cd0@github.com>

On Fri, 4 Dec 2020 08:36:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`
>
> Looks good to me.

@dfuch, are you still good with this? Please submit your formal review here :)

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 10:02:52 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 10:02:52 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>

On Fri, 4 Dec 2020 00:47:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

Hi Yasumasa, 

Thanks for filing the issue and providing a fix. 

Before integrating, can you please provide a non regression test that verifies the fix? You can place it in `test/jdk/java/net/httpclient/`; 
Please also make sure that there is no regression in existing tests.

best regards
-- daniel

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 422:

> 420:             } catch (IOException ex) {
> 421:                 need2Read = false;
> 422:                 haveNext = false;

This shouldn't be required - `need2Read`/`haveNext` will be set by `hasNext()`; I'd prefer if we kept the logic there.

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

Changes requested by dfuchs (Reviewer).

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

From dfuchs at openjdk.java.net  Fri Dec  4 10:10:00 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 10:10:00 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <5t8MdH3fSTakQhjti1G_14YeyOtaEJDy5lzRG2e-kmo=.06eb4163-8368-49f2-9809-92bb49ff2b7c@github.com>

On Fri, 4 Dec 2020 00:47:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 426:

> 424:                     is.close();
> 425:                 } catch (IOException ex2) {}
> 426:                 return -1;

} catch (IOException ex2) {}
                return -1;

I wonder if the first exception `ex` should actually be rethrown here instead of returning `-1`. Have you tried to explore this possibility?

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 10:16:55 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 10:16:55 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <yLc0Q17xTiKlBY44wvkVKjYwzb9nBVQY2hrJ9vf9vzw=.b9d7439c-59a6-4732-b9ff-fbe79a010cd0@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <oc2rO12E9RoSCFHJj9zeo6OPAu8z7FALeMyKJrIe6pw=.e3608e97-9cf1-4f1f-a372-b1bd3d97e024@github.com>
 <yLc0Q17xTiKlBY44wvkVKjYwzb9nBVQY2hrJ9vf9vzw=.b9d7439c-59a6-4732-b9ff-fbe79a010cd0@github.com>
Message-ID: <512L74Ac2lMZ--L1Ez5ZbA50u8PCqeJZA5eXRhbw6eo=.b8f1b100-c524-4254-a0f7-3d8cd93e9dc2@github.com>

On Fri, 4 Dec 2020 08:47:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Looks good to me.
>
> @dfuch, are you still good with this? Please submit your formal review here :)

Thanks for running the tests Andrei. I will sponsor.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Dec  4 10:23:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 4 Dec 2020 10:23:12 GMT
Subject: Integrated: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
Message-ID: <eXkMSH-hE9deufR3iXvcKU5qAyPtUbH-8cBtxDgU0AM=.81ef8e1d-2fc4-45ef-bc4a-a0488fd19280@github.com>

On Sat, 28 Nov 2020 19:42:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Incorrect format string was found by IntelliJ IDEA inspection `Java | Probable bugs | Malformed format string`

This pull request has now been integrated.

Changeset: c6f93ec9
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c6f93ec9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8257707: Fix incorrect format string in Http1HeaderParser

Reviewed-by: shade

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Fri Dec  4 11:25:19 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Fri, 4 Dec 2020 11:25:19 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
 <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
Message-ID: <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>

On Wed, 2 Dec 2020 16:35:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kartik Ohri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Align -> and remove trailing whitespace
>
> Marked as reviewed by dfuchs (Reviewer).

@pconcannon, If everything is in order, can you please approve the changes on Github. I'll then issue the integrate command. Thanks.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Dec  4 11:27:14 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 4 Dec 2020 11:27:14 GMT
Subject: RFR: 8257707: Fix incorrect format string in Http1HeaderParser
In-Reply-To: <512L74Ac2lMZ--L1Ez5ZbA50u8PCqeJZA5eXRhbw6eo=.b8f1b100-c524-4254-a0f7-3d8cd93e9dc2@github.com>
References: <2rX0uS_3mJePu2tTug_ki006tViuHDY2lf9ZLjThPL4=.8a3fcf15-62c3-4a12-b40a-689432499e08@github.com>
 <oc2rO12E9RoSCFHJj9zeo6OPAu8z7FALeMyKJrIe6pw=.e3608e97-9cf1-4f1f-a372-b1bd3d97e024@github.com>
 <yLc0Q17xTiKlBY44wvkVKjYwzb9nBVQY2hrJ9vf9vzw=.b9d7439c-59a6-4732-b9ff-fbe79a010cd0@github.com>
 <512L74Ac2lMZ--L1Ez5ZbA50u8PCqeJZA5eXRhbw6eo=.b8f1b100-c524-4254-a0f7-3d8cd93e9dc2@github.com>
Message-ID: <IwR3g5sAO3IMMhN7zwGIBw0Zvq267gs3IThppbm4988=.4f1789cc-65c2-4a05-a08a-bbb433b5614b@github.com>

On Fri, 4 Dec 2020 10:14:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch, are you still good with this? Please submit your formal review here :)
>
> Thanks for running the tests Andrei. I will sponsor.

Few tests failed with `make test-tier2`:
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/jdk:tier2                               3677  3661    16     0 <<
>> jtreg:test/langtools:tier2                           12    10     2     0 <<
>> jtreg:test/jaxp:tier2                               449   444     5     0 <<
==============================
TEST FAILURE

make[1]: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:319: main] ?????? 1
make: *** [/cygdrive/f/Projects/official_openjdk/make/Init.gmk:186: test-tier2] ?????? 2

List of failed tests:
java/io/BufferedInputStream/LargeCopyWithMark.java                                                  Failed. Unexpected exit from test [exit code: 1]
java/io/CharArrayReader/OverflowInRead.java                                                         Failed. Unexpected exit from test [exit code: 1]
java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
java/text/Format/CompactNumberFormat/TestCompactNumber.java                                         Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
java/text/Format/CompactNumberFormat/TestSpecialValues.java                                         Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 2
java/text/Format/NumberFormat/NumberRegression.java                                                 Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Uncaught exception thrown in test method Test4068693
java/text/Format/NumberFormat/NumberRoundTrip.java                                                  Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Uncaught exception thrown in test method TestNumberFormatRoundTrip
javax/sql/testng/test/rowset/cachedrowset/CachedRowSetTests.java                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 2
javax/sql/testng/test/rowset/filteredrowset/FilteredRowSetTests.java                                Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 3
javax/sql/testng/test/rowset/joinrowset/JoinRowSetTests.java                                        Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 3
javax/sql/testng/test/rowset/webrowset/WebRowSetTests.java                                          Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 3
tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS

jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 4
jdk/jshell/UserJdiUserRemoteTest.java                      Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathExpressionTest.java                Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 2
javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFunctionResolverTest.java          Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathTest.java                          Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 2
javax/xml/jaxp/functional/test/astro/AstroTest.java                                      Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 5
javax/xml/jaxp/unittest/transform/TransformerTest.java                                   Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

Looks like they are not related to my changes

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

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

From michaelm at openjdk.java.net  Fri Dec  4 13:28:16 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Dec 2020 13:28:16 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY" [v2]
In-Reply-To: <MH0k8ncCKy-rNZpOU0tIWK4TkVZl0s80otpARwOsxyk=.6b5a0f57-46e0-4497-8a6b-3fbcfde865b7@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
 <MH0k8ncCKy-rNZpOU0tIWK4TkVZl0s80otpARwOsxyk=.6b5a0f57-46e0-4497-8a6b-3fbcfde865b7@github.com>
Message-ID: <tcDeMUjZEIY3iDpfAVsnt6d1u18RWd0XbOlLKRfk8b0=.7084e430-7ca9-438f-aac9-7e6ff760e880@github.com>

On Wed, 2 Dec 2020 17:21:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
>> connection will be closed by the test server if the test server receives a RESET from the client
>> after the stream has been closed.
>> 
>> This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
>> the debug traces have eventually revealed what was the issue:
>> 
>> DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
>> TestServer: Unexpected frame on: 24
>> RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
>> Http server reader thread shutdown
>> java.io.IOException: Unexpected frame
>> at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
>> at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
>> Server connection to /127.0.0.1:39830 stopping. 5 streams
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
>   
>   Ammended fix to take into account reset frames received on either server streams
>   or client streams.

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

> 783:                                 System.err.println("TestServer: received ResetFrame on closed push stream: " + stream);
> 784:                                 System.err.println(frame);
> 785:                             } else {

For clarity, I'd suggest adding static methods for testing if a streamid is client or server.
Otherwise, the change looks fine.

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

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

From pconcannon at openjdk.java.net  Fri Dec  4 14:03:13 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 4 Dec 2020 14:03:13 GMT
Subject: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http
 and java.net.http [v5]
In-Reply-To: <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
 <v_8rHfukHzckN9V9Ca_1RkW4ufZlzFxRhULlhoeQTTs=.6d6786db-aeb8-49e2-b119-55195f9e2ec0@github.com>
 <bVG4BkqyXxqQz-3hd5QOfhuvIFWawL6rWRZAysNr5B4=.f3f8f8dc-fd9c-4913-9850-538720ee7d46@github.com>
 <CMfRNm71zRs86gHF373QBJ5EMxoi-MKZQI_RLOXzQBk=.51cb1b4a-7372-4478-ab86-fef21060d8be@github.com>
Message-ID: <prnolCuQ860auLlfTAjFdKrgCQLIt-bCOp8KnToHMp4=.a5cadb0d-3b23-4017-a98c-a7f97631f8b5@github.com>

On Fri, 4 Dec 2020 11:22:34 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> @pconcannon, If everything is in order, can you please approve the changes on Github. I'll then issue the integrate command. Thanks.

Hi @amCap1712, you will have to /integrate first, and then afterwards I will sponsor

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

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

From ysuenaga at openjdk.java.net  Fri Dec  4 14:35:12 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 4 Dec 2020 14:35:12 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
Message-ID: <OKqpz_Tzpd52UbjSpnuBb0i3FVYHsgGV6c7IA4z-0YE=.f6f585e2-5b78-4701-8692-794c30d4551e@github.com>

On Fri, 4 Dec 2020 09:53:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
>> 
>> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
>> 
>> 
>> # How to reproduce:
>> 
>> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
>> 
>> import java.io.*;
>> import java.net.*;
>> import java.net.http.*;
>> 
>> public class Test{
>> 
>>   private static class TestInputStream extends InputStream{
>> 
>>     public TestInputStream(){
>>       super();
>>       System.out.println("test c'tor");
>>     }
>> 
>>     @Override
>>     public int read() throws IOException{
>>       System.out.println("read called");
>>       throw new IOException("test");
>>     }
>> 
>>     @Override
>>     public void close() throws IOException{
>>       System.out.println("close called");
>>       super.close();
>>     }
>> 
>>   }
>> 
>>   public static void main(String[] args) throws Exception{
>>     var http = HttpClient.newHttpClient();
>>     var request = HttpRequest.newBuilder()
>>                              .uri(URI.create("http://httpbin.org/post"))
>>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>>                              .build();
>>     http.send(request, HttpResponse.BodyHandlers.discarding());
>>     System.out.println("Press any key to exit...");
>>     System.in.read();
>>   }
>> }
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 422:
> 
>> 420:             } catch (IOException ex) {
>> 421:                 need2Read = false;
>> 422:                 haveNext = false;
> 
> This shouldn't be required - `need2Read`/`haveNext` will be set by `hasNext()`; I'd prefer if we kept the logic there.

We can close the stream in `hasNext()`, but we need to move `close()` from `read()`.
`need2Read` and `haveNext` will be set to `false` if `read()` returns -1. However `read()` returns -1 when IOE or EOF happen. Is it ok? I concern to change location of `close()` - it means the change of side-effect.

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 426:
> 
>> 424:                     is.close();
>> 425:                 } catch (IOException ex2) {}
>> 426:                 return -1;
> 
> } catch (IOException ex2) {}
>                 return -1;
> 
> I wonder if the first exception `ex` should actually be rethrown here instead of returning `-1`. Have you tried to explore this possibility?

`read()` is not have IOE as checked exception, and also currently IOE is ignored.
So I ignored IOE at `close()` in this PR to minimize side-effect.

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 15:15:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 15:15:15 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <OKqpz_Tzpd52UbjSpnuBb0i3FVYHsgGV6c7IA4z-0YE=.f6f585e2-5b78-4701-8692-794c30d4551e@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
 <OKqpz_Tzpd52UbjSpnuBb0i3FVYHsgGV6c7IA4z-0YE=.f6f585e2-5b78-4701-8692-794c30d4551e@github.com>
Message-ID: <Qb9Oqp4jCgkRdsYKjVnvAtQLF8g3f2oEGfl_6UVQ3ww=.ecb01968-3c0c-444f-aee2-25f4a8ac5151@github.com>

On Fri, 4 Dec 2020 14:32:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 426:
>> 
>>> 424:                     is.close();
>>> 425:                 } catch (IOException ex2) {}
>>> 426:                 return -1;
>> 
>> } catch (IOException ex2) {}
>>                 return -1;
>> 
>> I wonder if the first exception `ex` should actually be rethrown here instead of returning `-1`. Have you tried to explore this possibility?
>
> `read()` is not have IOE as checked exception, and also currently IOE is ignored.
> So I ignored IOE at `close()` in this PR to minimize side-effect.

Right. But I am not sure that is the right thing to do. If InputStream::read throws then it's likely that the request body will be missing some bytes, so the request should probably be cancelled/aborted at this point - rather than having a truncated body sent to the server.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Fri Dec  4 15:20:15 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Fri, 4 Dec 2020 15:20:15 GMT
Subject: Integrated: JDK-8257401: Use switch expressions in
 jdk.internal.net.http and java.net.http
In-Reply-To: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
References: <xHWbcIHPaG9koG3tg_jicS9jipOFsdhXerPP1AmOmxI=.ff08fd3f-13ec-4aae-b6ab-5866a09c24cb@github.com>
Message-ID: <bGnOZfCLLjEZDzWeaXKn3lPz54SzLLPPBj5q6W3RgYA=.4e84fd83-8d7c-41a8-94b3-eccd28e01ebb@github.com>

On Sat, 21 Nov 2020 11:45:42 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi!
> Kindly review this patch to replace switch statements with switch expressions (where it makes sense) in the http client modules. The rationale is to improve readability of the code.
> Regards,
> Kartik

This pull request has now been integrated.

Changeset: ac549008
Author:    Kartik Ohri <kartikohri13 at gmail.com>
URL:       https://git.openjdk.java.net/jdk/commit/ac549008
Stats:     271 lines in 17 files changed: 2 ins; 124 del; 145 mod

8257401: Use switch expressions in jdk.internal.net.http and java.net.http

Reviewed-by: chegar, dfuchs, pconcannon

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 15:22:11 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 15:22:11 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens
In-Reply-To: <OKqpz_Tzpd52UbjSpnuBb0i3FVYHsgGV6c7IA4z-0YE=.f6f585e2-5b78-4701-8692-794c30d4551e@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
 <OKqpz_Tzpd52UbjSpnuBb0i3FVYHsgGV6c7IA4z-0YE=.f6f585e2-5b78-4701-8692-794c30d4551e@github.com>
Message-ID: <Bm-u9vmdYGaR14jfHqWjz8DaTC0Xoin5q7Gb5J1sEIA=.55a1a178-912a-4947-8375-b3b511539b20@github.com>

On Fri, 4 Dec 2020 14:32:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 422:
>> 
>>> 420:             } catch (IOException ex) {
>>> 421:                 need2Read = false;
>>> 422:                 haveNext = false;
>> 
>> This shouldn't be required - `need2Read`/`haveNext` will be set by `hasNext()`; I'd prefer if we kept the logic there.
>
> We can close the stream in `hasNext()`, but we need to move `close()` from `read()`.
> `need2Read` and `haveNext` will be set to `false` if `read()` returns -1. However `read()` returns -1 when IOE or EOF happen. Is it ok? I concern to change location of `close()` - it means the change of side-effect.

You misunderstand. `read()` should call `close();` when `read` returns `-1`, `hasNext()` will take care of updating `need2Read` and `haveNext`;

But now I'm no longer convinced that returning -1 when an exception occurs in the wrapped `InputStreeam::read` call is the right thing to do.

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 15:52:28 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 15:52:28 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY" [v3]
In-Reply-To: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
Message-ID: <lZIvZ3MjKsfa9_ERS2AADWDf5BXwaVum-YWdAHHZ5hY=.0a62dae9-b039-4af0-826f-4fdb2098509c@github.com>

> Hi,
> 
> Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
> connection will be closed by the test server if the test server receives a RESET from the client
> after the stream has been closed.
> 
> This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
> the debug traces have eventually revealed what was the issue:
> 
> DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> TestServer: Unexpected frame on: 24
> RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> Http server reader thread shutdown
> java.io.IOException: Unexpected frame
> at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
> at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
> Server connection to /127.0.0.1:39830 stopping. 5 streams

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:

 - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
   
   Integrated review comments: added two static methods:
       static boolean isClientStreamId(int streamid);
       static boolean isServerStreamId(int streamid);
 - Merge
 - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
   
   Ammended fix to take into account reset frames received on either server streams
   or client streams.
 - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
   
   Fixes an issue in Http2TestServerConnection - where the connection will be closed by
   the server if the server receives a RESET from the client after the stream has been
   closed on the server side.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1567/files
  - new: https://git.openjdk.java.net/jdk/pull/1567/files/0d15b660..6c6e9b12

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

  Stats: 311 lines in 26 files changed: 194 ins; 41 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1567/head:pull/1567

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

From dfuchs at openjdk.java.net  Fri Dec  4 15:52:29 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 15:52:29 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY" [v2]
In-Reply-To: <tcDeMUjZEIY3iDpfAVsnt6d1u18RWd0XbOlLKRfk8b0=.7084e430-7ca9-438f-aac9-7e6ff760e880@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
 <MH0k8ncCKy-rNZpOU0tIWK4TkVZl0s80otpARwOsxyk=.6b5a0f57-46e0-4497-8a6b-3fbcfde865b7@github.com>
 <tcDeMUjZEIY3iDpfAVsnt6d1u18RWd0XbOlLKRfk8b0=.7084e430-7ca9-438f-aac9-7e6ff760e880@github.com>
Message-ID: <YLwYqz6pw4J9-45s7xsEFJvBIc_eyJr1rcyjr-xGyeU=.8328a7dc-b22a-4772-a31e-cc674f2bf417@github.com>

On Fri, 4 Dec 2020 13:25:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
>>   
>>   Ammended fix to take into account reset frames received on either server streams
>>   or client streams.
>
> test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java line 785:
> 
>> 783:                                 System.err.println("TestServer: received ResetFrame on closed push stream: " + stream);
>> 784:                                 System.err.println(frame);
>> 785:                             } else {
> 
> For clarity, I'd suggest adding static methods for testing if a streamid is client or server.
> Otherwise, the change looks fine.

Thanks Michael. Done!

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 17:47:18 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 17:47:18 GMT
Subject: RFR: 8236413: AbstractConnectTimeout should tolerate both
 NoRouteToHostException and UnresolvedAddressException
Message-ID: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>

The timeout tests extending AbstractConnectTimeout have been relaxed to accept a
ConnectException wrapping NoRouteToHostException.
These test have been observed failing intermittently with ConnectException wrapping
java.nio.channels.UnresolvedAddressException instead - presumably a transient network
failure caused this other exception to be thrown.

The test logic should be relaxed to accept UnresolvedAddressException as possible
cause in ConnectException too.

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

Commit messages:
 - 8236413: AbstractConnectTimeout should tolerate both NoRouteToHostException and UnresolvedAddressException
 - 8236413: AbstractConnectTimeout should tolerate both NoRouteToHostException and UnresolvedAddressException

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Dec  4 19:50:24 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Dec 2020 19:50:24 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer
Message-ID: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>

jaxp.library.SimpleHttpServer
https://bugs.openjdk.java.net/browse/JDK-8212035

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

Commit messages:
 - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with

Changes: https://git.openjdk.java.net/jdk/pull/1632/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8212035
  Stats: 276 lines in 16 files changed: 72 ins; 141 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632

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

From dfuchs at openjdk.java.net  Fri Dec  4 20:51:16 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 20:51:16 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>

On Fri, 4 Dec 2020 19:44:33 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Changes requested by dfuchs (Reviewer).

test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80:

> 78:         creator.buildSignedMultiReleaseJar();
> 79: 
> 80:         server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", "."));

Please add space after comma.

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 95:

> 93:         return _httpserver.getAddress().getPort();
> 94:     }
> 95: 

There are many issues with this class - using "localhost" and binding to the wildcard address among others. 
Having instance variables that are not final but are accessed by potentially multiple threads is another. 
I could also mention not using try-with-resources or the odd _name convention.
It will need to be modernized if you want to put it in jdk.test.lib.net;

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

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

From dfuchs at openjdk.java.net  Fri Dec  4 20:51:17 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Dec 2020 20:51:17 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer
In-Reply-To: <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>
Message-ID: <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com>

On Fri, 4 Dec 2020 20:32:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80:
> 
>> 78:         creator.buildSignedMultiReleaseJar();
>> 79: 
>> 80:         server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", "."));
> 
> Please add space after comma.

I believe the InetAddress parameter should be preserved in order to allow test to specifically bind to the loopback address instead of the wildcard (binding to the wildcard has been a source of test instability in the past).

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

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

From ysuenaga at openjdk.java.net  Sat Dec  5 04:36:35 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 5 Dec 2020 04:36:35 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v2]
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <t2bMTgVkRoge7hCft90qc80UVXX70Olqe8o9VChrNe4=.3015a97f-f9c3-4c1d-b3f1-9da5a966559c@github.com>

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update patch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1614/files
  - new: https://git.openjdk.java.net/jdk/pull/1614/files/b7ef4ed1..7c04e983

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

  Stats: 167 lines in 2 files changed: 146 ins; 15 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1614.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1614/head:pull/1614

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

From ysuenaga at openjdk.java.net  Sat Dec  5 04:54:27 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 5 Dec 2020 04:54:27 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v3]
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <7ZGd-WyY6rP--gRB9FM91i3ZjvTZlHi2mgGw_aEJStM=.09faf307-32d0-4828-bbbc-60134fc5ebc4@github.com>

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Throw UIOE when stream throws IOE

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1614/files
  - new: https://git.openjdk.java.net/jdk/pull/1614/files/7c04e983..d9628c8e

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

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

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

From ysuenaga at openjdk.java.net  Sat Dec  5 04:58:13 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 5 Dec 2020 04:58:13 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v3]
In-Reply-To: <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
Message-ID: <29cfk2L5A9R0Zvf0MqOMdSUjpshYQWnz901o-Bz07Rc=.902fad80-1dc5-40e2-903e-ebaef2f77943@github.com>

On Fri, 4 Dec 2020 09:59:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw UIOE when stream throws IOE
>
> Hi Yasumasa, 
> 
> Thanks for filing the issue and providing a fix. 
> 
> Before integrating, can you please provide a non regression test that verifies the fix? You can place it in `test/jdk/java/net/httpclient/`; 
> Please also make sure that there is no regression in existing tests.
> 
> best regards
> -- daniel

@dfuch Thanks for your comment! I updated PR.

* Close the stream in `StreamIterator::hasNext`
* Throw `UncheckedIOException` whenever IOE happens
* Added testcase for this PR

Could you review again?

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

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

From michaelm at openjdk.java.net  Sat Dec  5 08:16:15 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sat, 5 Dec 2020 08:16:15 GMT
Subject: RFR: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY" [v3]
In-Reply-To: <lZIvZ3MjKsfa9_ERS2AADWDf5BXwaVum-YWdAHHZ5hY=.0a62dae9-b039-4af0-826f-4fdb2098509c@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
 <lZIvZ3MjKsfa9_ERS2AADWDf5BXwaVum-YWdAHHZ5hY=.0a62dae9-b039-4af0-826f-4fdb2098509c@github.com>
Message-ID: <IFkP5eTQLtPrioLjN--UQPdRQiAMdRPlHdbzVPUHPUA=.b3a73698-e297-4595-93a6-1b456cb93267@github.com>

On Fri, 4 Dec 2020 15:52:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
>> connection will be closed by the test server if the test server receives a RESET from the client
>> after the stream has been closed.
>> 
>> This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
>> the debug traces have eventually revealed what was the issue:
>> 
>> DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
>> TestServer: Unexpected frame on: 24
>> RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
>> Http server reader thread shutdown
>> java.io.IOException: Unexpected frame
>> at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
>> at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
>> Server connection to /127.0.0.1:39830 stopping. 5 streams
>
> 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:
> 
>  - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
>    
>    Integrated review comments: added two static methods:
>        static boolean isClientStreamId(int streamid);
>        static boolean isServerStreamId(int streamid);
>  - Merge
>  - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
>    
>    Ammended fix to take into account reset frames received on either server streams
>    or client streams.
>  - 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
>    
>    Fixes an issue in Http2TestServerConnection - where the connection will be closed by
>    the server if the server receives a RESET from the client after the stream has been
>    closed on the server side.

LGTM

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

Marked as reviewed by michaelm (Reviewer).

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

From dfuchs at openjdk.java.net  Mon Dec  7 10:01:17 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 10:01:17 GMT
Subject: Integrated: 8254802: ThrowingPushPromisesAsStringCustom.java fails in
 "try throwing in GET_BODY"
In-Reply-To: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
References: <QybKmhJ7rdbG6V3WaFIF5wHragKPgBKoYZaTlTRSbrM=.6053b5cc-df3b-47fa-a6d8-7a6e2307c620@github.com>
Message-ID: <RBxzy5Kyx9WwWxPsVqO47UCw5nc15MkcN05hNIbXL_U=.5fcbf437-cd47-40dc-9302-bcbb7e2b73c0@github.com>

On Wed, 2 Dec 2020 17:00:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find below a fix that fixes an issue in Http2TestServerConnection - where the 
> connection will be closed by the test server if the test server receives a RESET from the client
> after the stream has been closed.
> 
> This issue has made the ThrowingPushPromisesAsStringCustom test fail from time to time, but
> the debug traces have eventually revealed what was the issue:
> 
> DEBUG: [readLoop] [818ms] FramesDecoder Got frame: RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> TestServer: Unexpected frame on: 24
> RESET: length=4, streamid=24, flags=0 Error: Stream cancelled
> Http server reader thread shutdown
> java.io.IOException: Unexpected frame
> at Http2TestServerConnection.readLoop(Http2TestServerConnection.java:776)
> at Http2TestServerConnection$ConnectionThread.run(Http2TestServerConnection.java:438)
> Server connection to /127.0.0.1:39830 stopping. 5 streams

This pull request has now been integrated.

Changeset: 566d77a2
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/566d77a2
Stats:     20 lines in 1 file changed: 20 ins; 0 del; 0 mod

8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"

Reviewed-by: michaelm

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

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

From ccleary at openjdk.java.net  Mon Dec  7 10:44:26 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 10:44:26 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the condition in
 KeepAliveStreamCleaner
Message-ID: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>

The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).

...
long timeout = TIMEOUT;
    while ((kace = poll()) == null) {
            waiter.await(timeout, TimeUnit.MILLISECONDS); 
...
While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

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

Commit messages:
 - 8255583: Updated copyright notes
 - 8255583: Investigate creating a test to trigger the condition in KeepAliveStreamCleaner

Changes: https://git.openjdk.java.net/jdk/pull/1659/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1659&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255583
  Stats: 49 lines in 2 files changed: 42 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1659.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1659/head:pull/1659

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

From dfuchs at openjdk.java.net  Mon Dec  7 10:58:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 10:58:12 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
Message-ID: <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>

On Mon, 7 Dec 2020 09:52:47 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
> 
> ...
> long timeout = TIMEOUT;
>     while ((kace = poll()) == null) {
>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
> ...
> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @modules java.base/sun.net.www.http

Hi Conor,

Can you add:

@bug 8255124

here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.

best regards,

-- daniel

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:12:18 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:12:18 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
Message-ID: <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>

On Mon, 7 Dec 2020 10:55:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @modules java.base/sun.net.www.http
> 
> Hi Conor,
> 
> Can you add:
> 
> @bug 8255124
> 
> here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.
> 
> best regards,
> 
> -- daniel

Will do Daniel, thanks for pointing that out!

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:12:20 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:12:20 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
 <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>
Message-ID: <Ez4D6jTKawCNmSNcATNWvDG7g3RMwMmUppUhL7egyVU=.472558d8-137b-4f8c-b4c6-439ee4005bac@github.com>

On Mon, 7 Dec 2020 11:08:37 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @modules java.base/sun.net.www.http
>> 
>> Hi Conor,
>> 
>> Can you add:
>> 
>> @bug 8255124
>> 
>> here? [8255124](https://bugs.openjdk.java.net/browse/JDK-8255124) is the issue whose fix this test is verifying.
>> 
>> best regards,
>> 
>> -- daniel
>
> Will do Daniel, thanks for pointing that out!

Should probably add a short summary as well

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:39:30 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:39:30 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v2]
In-Reply-To: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
Message-ID: <iWJE5pZKNPidCRXuwJiqbah2cTzfGKMz9uTSR3RSpMQ=.972f2bf2-a8fd-4336-bbad-9529b0de8f60@github.com>

> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
> 
> ...
> long timeout = TIMEOUT;
>     while ((kace = poll()) == null) {
>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
> ...
> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:

 - 8255583: Added original bug id to bug tag
 - 8255583: Add bug & summary tags to KeepAliveStreamCleanerTestDriver

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1659/files
  - new: https://git.openjdk.java.net/jdk/pull/1659/files/ebbe000e..a6ca8d04

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

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

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

From ccleary at openjdk.java.net  Mon Dec  7 11:39:31 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 11:39:31 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v2]
In-Reply-To: <Ez4D6jTKawCNmSNcATNWvDG7g3RMwMmUppUhL7egyVU=.472558d8-137b-4f8c-b4c6-439ee4005bac@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <fKqb2_XR8FmEUHksQ1tTuDIh0AJqMKlAXJ9MEuJKIuk=.db842350-501e-4177-966e-4caea10086db@github.com>
 <wcSt8JAKvVWTh49gVjsHke6hqJaiVN4Bu7iKI-FSZXA=.dc76a469-e70c-4889-a04e-7715469fca03@github.com>
 <Ez4D6jTKawCNmSNcATNWvDG7g3RMwMmUppUhL7egyVU=.472558d8-137b-4f8c-b4c6-439ee4005bac@github.com>
Message-ID: <x6klaueWByJ5zETpo8qf8NT2_cIjH6C11NgbnJPpcjQ=.3c847e35-1974-4935-af17-640ec1740ab2@github.com>

On Mon, 7 Dec 2020 11:09:47 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Will do Daniel, thanks for pointing that out!
>
> Should probably add a short summary as well

Added bug ids for the original issue which you referred to and for the issue this PR relates to. Will mark as resolved if this is all good

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

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

From dfuchs at openjdk.java.net  Mon Dec  7 14:56:17 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 14:56:17 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v2]
In-Reply-To: <iWJE5pZKNPidCRXuwJiqbah2cTzfGKMz9uTSR3RSpMQ=.972f2bf2-a8fd-4336-bbad-9529b0de8f60@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <iWJE5pZKNPidCRXuwJiqbah2cTzfGKMz9uTSR3RSpMQ=.972f2bf2-a8fd-4336-bbad-9529b0de8f60@github.com>
Message-ID: <1iJsLUG8MiX0cW8Tv2-n8tYOJZ_ZbdQ9B-JkVrljHJA=.a33691f7-fd3f-4ab8-80ef-60e6e3bab29e@github.com>

On Mon, 7 Dec 2020 11:39:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8255583: Added original bug id to bug tag
>  - 8255583: Add bug & summary tags to KeepAliveStreamCleanerTestDriver

test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 27:

> 25:  * @test
> 26:  * @bug 8255124 8255583
> 27:  * @summary Tests that KeepAliveStreamCleaner run does not throw an IllegalMonitorState Exception.

Thanks for the summary!
`@bug` should only list `8255124` ; We typically don't list issues that affect the tests only. We only list those that affect the JDK source code and which can be verified by running the test.

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

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

From pconcannon at openjdk.java.net  Mon Dec  7 15:37:20 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 7 Dec 2020 15:37:20 GMT
Subject: RFR: 8254996: make jdk.net.UnixDomainPrincipal a record class
Message-ID: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>

Hi,

Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?

`jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.

CSR : https://bugs.openjdk.java.net/browse/JDK-8257823

Kind regards,
Patrick

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

Commit messages:
 - 8254996: make jdk.net.UnixDomainPrincipal a record class

Changes: https://git.openjdk.java.net/jdk/pull/1668/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1668&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254996
  Stats: 52 lines in 1 file changed: 3 ins; 45 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1668/head:pull/1668

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

From aefimov at openjdk.java.net  Mon Dec  7 16:32:13 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 7 Dec 2020 16:32:13 GMT
Subject: RFR: 8236413: AbstractConnectTimeout should tolerate both
 NoRouteToHostException and UnresolvedAddressException
In-Reply-To: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
References: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
Message-ID: <T4chJAFQ67pY_hekE4KXnp7cTJzfIsBIGSwgDprK3NU=.70b01865-d3e6-4b10-b3e2-e979a3b0fb01@github.com>

On Fri, 4 Dec 2020 17:41:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The timeout tests extending AbstractConnectTimeout have been relaxed to accept a
> ConnectException wrapping NoRouteToHostException.
> These test have been observed failing intermittently with ConnectException wrapping
> java.nio.channels.UnresolvedAddressException instead - presumably a transient network
> failure caused this other exception to be thrown.
> 
> The test logic should be relaxed to accept UnresolvedAddressException as possible
> cause in ConnectException too.

Hi Daniel,
The changes look good to me ??

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

Marked as reviewed by aefimov (Committer).

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

From dfuchs at openjdk.java.net  Mon Dec  7 16:50:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 16:50:12 GMT
Subject: RFR: 8254996: make jdk.net.UnixDomainPrincipal a record class
In-Reply-To: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
References: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
Message-ID: <0DDoSkyUBtCKU9HbvSVVJSDnlojUvWsCV9E8zjomRG0=.5a05efc4-16c5-4575-8bda-ed9b45bf57d0@github.com>

On Mon, 7 Dec 2020 15:32:54 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?
> 
> `jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
> This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.
> 
> CSR : https://bugs.openjdk.java.net/browse/JDK-8257823
> 
> Kind regards,
> Patrick

That looks fine to me Patrick. First top-level record class in the JDK!

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

Marked as reviewed by dfuchs (Reviewer).

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

From ccleary at openjdk.java.net  Mon Dec  7 17:11:28 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 17:11:28 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v3]
In-Reply-To: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
Message-ID: <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>

> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
> 
> ...
> long timeout = TIMEOUT;
>     while ((kace = poll()) == null) {
>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
> ...
> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

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

  8255583: Removed unnecessary bug id

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1659/files
  - new: https://git.openjdk.java.net/jdk/pull/1659/files/a6ca8d04..785e66ac

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

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

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

From ccleary at openjdk.java.net  Mon Dec  7 17:11:29 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Dec 2020 17:11:29 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v2]
In-Reply-To: <1iJsLUG8MiX0cW8Tv2-n8tYOJZ_ZbdQ9B-JkVrljHJA=.a33691f7-fd3f-4ab8-80ef-60e6e3bab29e@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <iWJE5pZKNPidCRXuwJiqbah2cTzfGKMz9uTSR3RSpMQ=.972f2bf2-a8fd-4336-bbad-9529b0de8f60@github.com>
 <1iJsLUG8MiX0cW8Tv2-n8tYOJZ_ZbdQ9B-JkVrljHJA=.a33691f7-fd3f-4ab8-80ef-60e6e3bab29e@github.com>
Message-ID: <n52b5XzehOvOMagHYHRSSHdh8QfqqG3JOsR9igr8hb8=.657ddb42-7c14-4a2e-9ab9-c069abfc4259@github.com>

On Mon, 7 Dec 2020 14:53:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8255583: Added original bug id to bug tag
>>  - 8255583: Add bug & summary tags to KeepAliveStreamCleanerTestDriver
>
> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8255124 8255583
>> 27:  * @summary Tests that KeepAliveStreamCleaner run does not throw an IllegalMonitorState Exception.
> 
> Thanks for the summary!
> `@bug` should only list `8255124` ; We typically don't list issues that affect the tests only. We only list those that affect the JDK source code and which can be verified by running the test.

Understood, I removed the additional id and now only 8255124 is present.

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

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

From dfuchs at openjdk.java.net  Mon Dec  7 17:28:13 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Dec 2020 17:28:13 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v3]
In-Reply-To: <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
Message-ID: <Elk79z5Pi_-MTY-0CEjqwy3dZdetXA8307_Ygk7qFHs=.2938637b-173c-4d8a-8bc5-e01ddf36f763@github.com>

On Mon, 7 Dec 2020 17:11:28 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255583: Removed unnecessary bug id

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Mon Dec  7 18:20:11 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Dec 2020 18:20:11 GMT
Subject: RFR: 8254996: make jdk.net.UnixDomainPrincipal a record class
In-Reply-To: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
References: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
Message-ID: <NfbjZSrEqnLJUsK2bX07zT1Gh1bVEurIQ5dhk_Ygn9o=.08e25d96-cfe6-4013-9fb1-47f7dabca8fa@github.com>

On Mon, 7 Dec 2020 15:32:54 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?
> 
> `jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
> This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.
> 
> CSR : https://bugs.openjdk.java.net/browse/JDK-8257823
> 
> Kind regards,
> Patrick

Marked as reviewed by michaelm (Reviewer).

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

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

From minqi at openjdk.java.net  Tue Dec  8 05:45:20 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Dec 2020 05:45:20 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <TguKP3F3tuAgdzImLvrt5s35nBTy1w6msEIGYNmWsq8=.0c36bee0-a2d6-48c0-84a8-a60b31e1df28@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision:

 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - 8257805: Add compiler/blackhole tests to tier1
   
   Reviewed-by: kvn
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/dd9ae050...f7958306

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1657/files
  - new: https://git.openjdk.java.net/jdk/pull/1657/files/dd9ae050..f7958306

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

  Stats: 8052 lines in 156 files changed: 4548 ins; 2755 del; 749 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From michaelm at openjdk.java.net  Tue Dec  8 16:20:35 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 8 Dec 2020 16:20:35 GMT
Subject: RFR: 8236413: AbstractConnectTimeout should tolerate both
 NoRouteToHostException and UnresolvedAddressException
In-Reply-To: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
References: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
Message-ID: <Xlud_uxI8vtNW90UhshC-okB_iea_I1zS8scwdx5tbg=.448b33e6-e8aa-42da-9cab-a22631cafc7d@github.com>

On Fri, 4 Dec 2020 17:41:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The timeout tests extending AbstractConnectTimeout have been relaxed to accept a
> ConnectException wrapping NoRouteToHostException.
> These test have been observed failing intermittently with ConnectException wrapping
> java.nio.channels.UnresolvedAddressException instead - presumably a transient network
> failure caused this other exception to be thrown.
> 
> The test logic should be relaxed to accept UnresolvedAddressException as possible
> cause in ConnectException too.

LGTM

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

Marked as reviewed by michaelm (Reviewer).

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

From dfuchs at openjdk.java.net  Tue Dec  8 16:39:29 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 8 Dec 2020 16:39:29 GMT
Subject: Integrated: 8236413: AbstractConnectTimeout should tolerate both
 NoRouteToHostException and UnresolvedAddressException
In-Reply-To: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
References: <O447u94UeFes6rg1vqblt4aZCk6kdyx3titxF8TtSUc=.e5bc7eea-c89d-415b-8f94-51fcd848a0e2@github.com>
Message-ID: <5Aob4KSFPm9sX1d0BkbqGKvLR59mRnOA50I4X6V8OUo=.b3e2ab4e-607b-4abf-9ae9-c21891273aac@github.com>

On Fri, 4 Dec 2020 17:41:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The timeout tests extending AbstractConnectTimeout have been relaxed to accept a
> ConnectException wrapping NoRouteToHostException.
> These test have been observed failing intermittently with ConnectException wrapping
> java.nio.channels.UnresolvedAddressException instead - presumably a transient network
> failure caused this other exception to be thrown.
> 
> The test logic should be relaxed to accept UnresolvedAddressException as possible
> cause in ConnectException too.

This pull request has now been integrated.

Changeset: fab6158c
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fab6158c
Stats:     14 lines in 1 file changed: 7 ins; 0 del; 7 mod

8236413: AbstractConnectTimeout should tolerate both NoRouteToHostException and UnresolvedAddressException

Reviewed-by: aefimov, michaelm

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Dec  8 16:51:05 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 8 Dec 2020 16:51:05 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v2]
In-Reply-To: <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>
 <60CyX-zWhx9EA7xs7Kt9D0ut7hF6c3DhHUn2UaAonho=.2fee02bd-42eb-4ca5-86c6-3b200b944663@github.com>
Message-ID: <4sZNfZX8UVXkdTDIIHWbR9qlNbXwEbcYHvLLJ4MBKSg=.00fd3ac4-6310-4f47-8159-be9b00eeeb89@github.com>

On Fri, 4 Dec 2020 20:48:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java line 80:
>> 
>>> 78:         creator.buildSignedMultiReleaseJar();
>>> 79: 
>>> 80:         server = new SimpleHttpServer(TESTCONTEXT,System.getProperty("user.dir", "."));
>> 
>> Please add space after comma.
>
> I believe the InetAddress parameter should be preserved in order to allow test to specifically bind to the loopback address instead of the wildcard (binding to the wildcard has been a source of test instability in the past).

Thanks. Review comments are fixed in next patch

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Dec  8 16:51:02 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 8 Dec 2020 16:51:02 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v2]
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <g3duzWw2PCGZMo9S0iYCi2UEL5iF6P5foOAS2x7rogU=.95e7bf57-d0eb-46c3-97af-df69843ca5f2@github.com>

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1632/files
  - new: https://git.openjdk.java.net/jdk/pull/1632/files/f48a3f7a..71fc7e9f

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

  Stats: 145 lines in 3 files changed: 26 ins; 33 del; 86 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Dec  8 16:51:09 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 8 Dec 2020 16:51:09 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v2]
In-Reply-To: <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <eyB7MldM3CF8jhCAEDV5noqoEmXazz8ZQid2NuqjMGQ=.5bf26b42-64cb-402f-ba8f-05a983a2fbc8@github.com>
Message-ID: <JCqDRZQew6YdniAhiZpY2N7TktJPwPJXYUnGXQ8e-d0=.b46eb00f-4892-4771-b815-1d09627e59d7@github.com>

On Fri, 4 Dec 2020 20:45:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/lib/jdk/test/lib/net/SimpleHttpServer.java line 95:
> 
>> 93:         return _httpserver.getAddress().getPort();
>> 94:     }
>> 95: 
> 
> There are many issues with this class - using "localhost" and binding to the wildcard address among others. 
> Having instance variables that are not final but are accessed by potentially multiple threads is another. 
> I could also mention not using try-with-resources or the odd _name convention.
> It will need to be modernized if you want to put it in jdk.test.lib.net;

Thanks. Now this class is modernized in next patch.

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

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

From Matthew.Carter at microsoft.com  Tue Dec  8 17:46:51 2020
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Tue, 8 Dec 2020 17:46:51 +0000
Subject: RFR: 8255264: Support for identifying the full range of IPv4
 localhost addresses on Windows
In-Reply-To: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>
References: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>
Message-ID: <BY5PR00MB0660E24113B8BF13C644EFF08ACD9@BY5PR00MB0660.namprd00.prod.outlook.com>

Have an RFR needing a sponsor and review - this is related to Nikola's prior work on JDK-8250521: Configure initial RTO to use minimal retry for loopback connections on Windows

Thanks in advance
Mat Carter

Sent from Outlook


From: net-dev <net-dev-retn at openjdk.java.net> on behalf of Mat Carter <github.com+54955201+macarte at openjdk.java.net>
Sent: Tuesday, December 1, 2020 8:45 AM
To: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows 
?
Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler)

This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows

IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to
127.255.255.255 inclusive.

The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change

Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address

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

Commit messages:
?- 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows

Changes: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523%2Ffiles&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E6vGW2cv%2F8xbbwQ7LXAHnNJlCMz%2FDYuE2mf7Cb4XL%2F8%3D&amp;reserved=0
?Webrev: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebrevs.openjdk.java.net%2F%3Frepo%3Djdk%26pr%3D1523%26range%3D00&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3zrfHSmoebfb6frkKY2hiPvFmE2fwfWD0JTSKP0GySU%3D&amp;reserved=0
? Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8255264&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nARpDuRflecA48G4BuWoDTXLE1eq9oM%2BExoEnnaPfEM%3D&amp;reserved=0
? Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod
? Patch: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523.diff&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Sij9ITYHDondJDDG2SGfxMCuu84rDAncUWPiKQP3YdY%3D&amp;reserved=0
? Fetch: git fetch https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EL%2BrIjy0g%2FQtORAa2bSNQQvJJ%2Fv9vB%2FJjReuUy5e798%3D&amp;reserved=0 pull/1523/head:pull/1523

PR: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523&amp;data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tDt7IKZIie43WPEiWvVEiqoGBvIg6erjxbqLw%2BqUzAg%3D&amp;reserved=0

From chegar at openjdk.java.net  Wed Dec  9 12:11:38 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 9 Dec 2020 12:11:38 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v3]
In-Reply-To: <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
Message-ID: <BbMAXsQrolujlLuE4nJj5vi-E7Bs59zMxRCNiI-bOqA=.f7034ad3-3d25-4037-bcc9-71f860c14510@github.com>

On Mon, 7 Dec 2020 17:11:28 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255583: Removed unnecessary bug id

Marked as reviewed by chegar (Reviewer).

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

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

From michaelm at openjdk.java.net  Wed Dec  9 12:35:35 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 9 Dec 2020 12:35:35 GMT
Subject: RFR: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner [v3]
In-Reply-To: <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
 <x786fqcjNPO4zslrTGKykiwP8XX-i1tJKGMgqbsDa6w=.1c96d4dd-e0e1-4cb9-baad-3fdf26e8b0df@github.com>
Message-ID: <TG3Ql6hPii_Ao3R_LNdpgQMZwBfyyGeLMniVBeFMC0Q=.18d147a7-d0fe-466e-b9c6-adb8df42fc78@github.com>

On Mon, 7 Dec 2020 17:11:28 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
>> 
>> ...
>> long timeout = TIMEOUT;
>>     while ((kace = poll()) == null) {
>>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
>> ...
>> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255583: Removed unnecessary bug id

LGTM

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

Marked as reviewed by michaelm (Reviewer).

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

From pconcannon at openjdk.java.net  Wed Dec  9 15:21:55 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 9 Dec 2020 15:21:55 GMT
Subject: RFR: 8254996: make jdk.net.UnixDomainPrincipal a record class [v2]
In-Reply-To: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
References: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
Message-ID: <cP3Uy0xLH75qOfkCRP9hO6OwOTPrgi0JKwNqNn1I_uI=.55468a0e-1460-4057-96de-878a67a20bae@github.com>

> Hi,
> 
> Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?
> 
> `jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
> This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.
> 
> CSR : https://bugs.openjdk.java.net/browse/JDK-8257823
> 
> Kind regards,
> Patrick

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

 - Merge remote-tracking branch 'origin/master' into JDK-8254996
 - 8254996: make jdk.net.UnixDomainPrincipal a record class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1668/files
  - new: https://git.openjdk.java.net/jdk/pull/1668/files/7dace76c..2adf1455

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

  Stats: 11962 lines in 365 files changed: 6562 ins; 3982 del; 1418 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1668/head:pull/1668

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

From dfuchs at openjdk.java.net  Wed Dec  9 15:41:44 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Dec 2020 15:41:44 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information
Message-ID: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>

Hi, 

Please find here a changeset that fixes the infrequent (but annoying) test failures
caused by unexpected ConnectionException "Connection timed out: no further information"
which have been observed to occur on some platforms.

Tests are updated to allow the test server to handle requests concurrently.
PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
early with ConnectionException and the connection timeout has not expired.

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

Commit messages:
 - 8256459: java/net/httpclient/ManyRequests.java and java/net/httpclient/LineBodyHandlerTest.java fail infrequently with java.net.ConnectException: Connection timed out: no further information

Changes: https://git.openjdk.java.net/jdk/pull/1716/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1716&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256459
  Stats: 163 lines in 4 files changed: 121 ins; 8 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1716.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1716/head:pull/1716

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

From pconcannon at openjdk.java.net  Wed Dec  9 17:02:50 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 9 Dec 2020 17:02:50 GMT
Subject: RFR: 8254996: make jdk.net.UnixDomainPrincipal a record class [v3]
In-Reply-To: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
References: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
Message-ID: <l9Qqun2DKILwE1Y7HL31J02oeVBR6t57TF4QwyQA5EU=.86eebaa7-43e2-448b-932a-7d574081d711@github.com>

> Hi,
> 
> Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?
> 
> `jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
> This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.
> 
> CSR : https://bugs.openjdk.java.net/browse/JDK-8257823
> 
> Kind regards,
> Patrick

Patrick Concannon 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 remote-tracking branch 'origin/master' into JDK-8254996
 - Merge remote-tracking branch 'origin/master' into JDK-8254996
 - 8254996: make jdk.net.UnixDomainPrincipal a record class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1668/files
  - new: https://git.openjdk.java.net/jdk/pull/1668/files/2adf1455..b00569d7

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

  Stats: 132 lines in 7 files changed: 125 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1668.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1668/head:pull/1668

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

From pconcannon at openjdk.java.net  Wed Dec  9 17:06:35 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 9 Dec 2020 17:06:35 GMT
Subject: Integrated: 8254996: make jdk.net.UnixDomainPrincipal a record class
In-Reply-To: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
References: <S5W4Y62fp8BUD88pj4wcIYp1NhyGNq-nufsovcePZ3c=.81056879-6526-47ad-8cd9-1fa7806416fa@github.com>
Message-ID: <aOBG0GFg3ZIczd6Vs0aHT3t-1Yx137PMy8aW5M0gI0Q=.e138c1d5-9a04-4150-85ca-f2766933259b@github.com>

On Mon, 7 Dec 2020 15:32:54 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for JDK-8254996: 'make jdk.net.UnixDomainPrincipal a record class'?
> 
> `jdk.net.UnixDomainPrincipal` is a simple immutable data class that requires boilerplate methods for access. However, these methods and fields are susceptible to trivial mistakes and add to the verbosity of the class. 
> This fix replaces the data class with a record class, a new type in JDK 16, making the code more concise and easier to maintain. This code is binary compatible with the original. For the generated API doc change, please refer to the specdiff attached to the CSR.
> 
> CSR : https://bugs.openjdk.java.net/browse/JDK-8257823
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 6dd06add
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6dd06add
Stats:     52 lines in 1 file changed: 3 ins; 45 del; 4 mod

8254996: make jdk.net.UnixDomainPrincipal a record class

Reviewed-by: dfuchs, michaelm

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

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

From chegar at openjdk.java.net  Wed Dec  9 17:25:41 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 9 Dec 2020 17:25:41 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information
In-Reply-To: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
Message-ID: <L2DWqGApi2kiabvO2p0kxV2T5r8sc2c3O4MFQzWfKA8=.fe22b5d8-ae86-4b75-a4a3-d7ad7c3a1c5b@github.com>

On Wed, 9 Dec 2020 15:37:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a changeset that fixes the infrequent (but annoying) test failures
> caused by unexpected ConnectionException "Connection timed out: no further information"
> which have been observed to occur on some platforms.
> 
> Tests are updated to allow the test server to handle requests concurrently.
> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
> early with ConnectionException and the connection timeout has not expired.

src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 205:

> 203:         }
> 204:         return cf.handle((r,t) -> checkRetryConnect(r, t,exchange))
> 205:                 .thenCompose(Function.identity());

So this changes behaviour so that a single subsequent additional TCP connection may be tried for all cases where the connection fails AND there is remaining connection deadline. Ok.

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

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

From chegar at openjdk.java.net  Wed Dec  9 18:26:45 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 9 Dec 2020 18:26:45 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information
In-Reply-To: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
Message-ID: <xFbaOi-u09iOiVAFYD3JI8D5jc1nWNm7d8mBIZQ-m_4=.117374cc-9421-4a24-ac72-ff8c473325b9@github.com>

On Wed, 9 Dec 2020 15:37:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a changeset that fixes the infrequent (but annoying) test failures
> caused by unexpected ConnectionException "Connection timed out: no further information"
> which have been observed to occur on some platforms.
> 
> Tests are updated to allow the test server to handle requests concurrently.
> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
> early with ConnectionException and the connection timeout has not expired.

Marked as reviewed by chegar (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed Dec  9 18:26:51 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Dec 2020 18:26:51 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information
In-Reply-To: <L2DWqGApi2kiabvO2p0kxV2T5r8sc2c3O4MFQzWfKA8=.fe22b5d8-ae86-4b75-a4a3-d7ad7c3a1c5b@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
 <L2DWqGApi2kiabvO2p0kxV2T5r8sc2c3O4MFQzWfKA8=.fe22b5d8-ae86-4b75-a4a3-d7ad7c3a1c5b@github.com>
Message-ID: <rfGmESvTlXiD6vOqfA1aMWxZQfHqLfNwAP-jPSkMZJs=.0684f359-c32c-4fe8-a200-0027a1e50719@github.com>

On Wed, 9 Dec 2020 17:23:19 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi, 
>> 
>> Please find here a changeset that fixes the infrequent (but annoying) test failures
>> caused by unexpected ConnectionException "Connection timed out: no further information"
>> which have been observed to occur on some platforms.
>> 
>> Tests are updated to allow the test server to handle requests concurrently.
>> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
>> early with ConnectionException and the connection timeout has not expired.
>
> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 205:
> 
>> 203:         }
>> 204:         return cf.handle((r,t) -> checkRetryConnect(r, t,exchange))
>> 205:                 .thenCompose(Function.identity());
> 
> So this changes behaviour so that a single subsequent additional TCP connection may be tried for all cases where the connection fails AND there is remaining connection deadline. Ok.

Yes - I didn't want to depend on the exception message - and there's no way to distinguish with the exception type (it's raw `ConnectionException`). It will however happen *only* when the `ConnectionException` is thrown by `SocketChannel::finishConnect`.

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

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

From jamie.letual at gmail.com  Wed Dec  9 18:35:42 2020
From: jamie.letual at gmail.com (Jamie Le Tual)
Date: Wed, 9 Dec 2020 13:35:42 -0500
Subject: icmp and raw sockets on linux
In-Reply-To: <CADbpLFtBmw3fcCh9nhSbMSywcwZjE0CkqTpDYzFZq3+QJnX0kQ@mail.gmail.com>
References: <CADbpLFuTbR2PE5Y+tibOWwAK+BHGLsbt4t6SmA8HP5Renws5tA@mail.gmail.com>
 <c15979a1-9bdc-f3fe-3786-473130f2b32b@oracle.com>
 <CADbpLFvZDLy=enXRZysiEsd4qHRZ7KM7cZgHdryeFtn7vvq_cQ@mail.gmail.com>
 <e97877b9-4c8b-81f8-933f-3d80a5b9963e@oracle.com>
 <CADbpLFtBmw3fcCh9nhSbMSywcwZjE0CkqTpDYzFZq3+QJnX0kQ@mail.gmail.com>
Message-ID: <CADbpLFuSDWQ8KpdopMZCBMugGi0qkGoJBFNaJY0D1PfS-Hj6uA@mail.gmail.com>

I'm wondering what the process is for the pull request I submitted, I guess
I need a reviewer or a sponsor?


On Tue, 1 Dec 2020 at 14:08, Jamie Le Tual <jamie.letual at gmail.com> wrote:

> Hi Alan,
> I received an email this morning saying my OCA had been processed, but
> that it would perhaps take a couple of hours before a bot picks it up and I
> show up on the OCA signatories page (no idea where that page is though).
>
> I have also updated the patch in my pull request to cover ipv6 as well.
>
> Test cases are forthcoming.
>
>
> On Sun, 29 Nov 2020 at 11:35, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 29/11/2020 14:54, Jamie Le Tual wrote:
>>
>> Although I've only just sent in the pdf form for an ora, I've already
>> submitted a pull request, https://github.com/openjdk/jdk/pull/1502
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1502__;!!GqivPVa7Brio!JhGUqeElAhEy9M_c0xBiYFVZQXX0YeHTlOrypbtjph_VrhY7t4LmgPpmxNpSAwLCuA$>
>> wherein an attempt is first made to use an IPPROTO_ICMP socket before
>> falling back on RAW_SOCK and finally tcp echo.
>>
>> I suppose now I have to wait until I am able to open an issue in the bug
>> tracker so I can associate the pull request to it.
>>
>> Does anyone know what a unit test for this might look like? To cover the
>> use cases the code has to be invoked by both a privileged and unprivileged
>> user, and I'm not sure how to go about setting up a unit test.
>>
>>
>> I've created JDK-8257235 [1] to track this. One thing to understand is
>> whether there is an equivalent for IPPROTO_ICMPV6. Sorry, I can't look at
>> the patch or comment in the PR until the bot confirms that you have signed
>> the OCA.
>>
>> Have you looked at the existing tests in test/jdk/java/net/InetAddress?
>> It will be awkward to verify as the behaviour before/after will not be
>> observable without looking at the network or system call trace.
>>
>> -Alan
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8257235
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201209/46d427f4/attachment.htm>

From dfuchs at openjdk.java.net  Wed Dec  9 18:50:50 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Dec 2020 18:50:50 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information [v2]
In-Reply-To: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
Message-ID: <4DQp0Jn9auqpK47tlxvbTyi4JqS6uDpH1eWLxAjAWRo=.972c4ef1-68ae-4582-aa90-62e58399591d@github.com>

> Hi, 
> 
> Please find here a changeset that fixes the infrequent (but annoying) test failures
> caused by unexpected ConnectionException "Connection timed out: no further information"
> which have been observed to occur on some platforms.
> 
> Tests are updated to allow the test server to handle requests concurrently.
> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
> early with ConnectionException and the connection timeout has not expired.

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

  8256459: java/net/httpclient/ManyRequests.java and java/net/httpclient/LineBodyHandlerTest.java fail infrequently with java.net.ConnectException: Connection timed out: no further information
  
  Connect will not be retried if retry connect is disabled
  JBS issue label noreg-self removed and bug id added to tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1716/files
  - new: https://git.openjdk.java.net/jdk/pull/1716/files/617c1f5a..090b390f

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

  Stats: 12 lines in 5 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1716.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1716/head:pull/1716

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

From dfuchs at openjdk.java.net  Wed Dec  9 18:55:37 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Dec 2020 18:55:37 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information [v2]
In-Reply-To: <L2DWqGApi2kiabvO2p0kxV2T5r8sc2c3O4MFQzWfKA8=.fe22b5d8-ae86-4b75-a4a3-d7ad7c3a1c5b@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
 <L2DWqGApi2kiabvO2p0kxV2T5r8sc2c3O4MFQzWfKA8=.fe22b5d8-ae86-4b75-a4a3-d7ad7c3a1c5b@github.com>
Message-ID: <FkNJyDIt_pJf_SNbK5B28O9WU5mDBJdeKK1KlSHGt1E=.8c372aa8-3e47-4ddb-aa6f-5997ca48377f@github.com>

On Wed, 9 Dec 2020 17:23:19 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8256459: java/net/httpclient/ManyRequests.java and java/net/httpclient/LineBodyHandlerTest.java fail infrequently with java.net.ConnectException: Connection timed out: no further information
>>   
>>   Connect will not be retried if retry connect is disabled
>>   JBS issue label noreg-self removed and bug id added to tests
>
> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 205:
> 
>> 203:         }
>> 204:         return cf.handle((r,t) -> checkRetryConnect(r, t,exchange))
>> 205:                 .thenCompose(Function.identity());
> 
> So this changes behaviour so that a single subsequent additional TCP connection may be tried for all cases where the connection fails AND there is remaining connection deadline. Ok.

@ChrisHegarty I have modified the logic to not retry if `jdk.httpclient.disableRetryConnect` was specified. By default that property is not specified and so we will retry once, but if an application has specifically opted for not retrying on ConnectException then we will not retry.

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

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

From chegar at openjdk.java.net  Wed Dec  9 19:20:42 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 9 Dec 2020 19:20:42 GMT
Subject: RFR: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information [v2]
In-Reply-To: <4DQp0Jn9auqpK47tlxvbTyi4JqS6uDpH1eWLxAjAWRo=.972c4ef1-68ae-4582-aa90-62e58399591d@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
 <4DQp0Jn9auqpK47tlxvbTyi4JqS6uDpH1eWLxAjAWRo=.972c4ef1-68ae-4582-aa90-62e58399591d@github.com>
Message-ID: <pyrI5a1edLOJH61uF18o5RSjRuVwa3H1TvP42NsZklw=.2fc36b51-0f78-4109-a59a-acb29082558c@github.com>

On Wed, 9 Dec 2020 18:50:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi, 
>> 
>> Please find here a changeset that fixes the infrequent (but annoying) test failures
>> caused by unexpected ConnectionException "Connection timed out: no further information"
>> which have been observed to occur on some platforms.
>> 
>> Tests are updated to allow the test server to handle requests concurrently.
>> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
>> early with ConnectionException and the connection timeout has not expired.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256459: java/net/httpclient/ManyRequests.java and java/net/httpclient/LineBodyHandlerTest.java fail infrequently with java.net.ConnectException: Connection timed out: no further information
>   
>   Connect will not be retried if retry connect is disabled
>   JBS issue label noreg-self removed and bug id added to tests

Marked as reviewed by chegar (Reviewer).

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

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

From chegar at openjdk.java.net  Thu Dec 10 09:37:38 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 10 Dec 2020 09:37:38 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v3]
In-Reply-To: <7ZGd-WyY6rP--gRB9FM91i3ZjvTZlHi2mgGw_aEJStM=.09faf307-32d0-4828-bbbc-60134fc5ebc4@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <7ZGd-WyY6rP--gRB9FM91i3ZjvTZlHi2mgGw_aEJStM=.09faf307-32d0-4828-bbbc-60134fc5ebc4@github.com>
Message-ID: <fvl-M3j6gDfRC9XtGYSlK4eu-Y3QIa3BJxzkb7wUrGQ=.389bbcd0-1899-47b8-8dee-106a9dfb9c73@github.com>

On Sat, 5 Dec 2020 04:54:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
>> 
>> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
>> 
>> 
>> # How to reproduce:
>> 
>> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
>> 
>> import java.io.*;
>> import java.net.*;
>> import java.net.http.*;
>> 
>> public class Test{
>> 
>>   private static class TestInputStream extends InputStream{
>> 
>>     public TestInputStream(){
>>       super();
>>       System.out.println("test c'tor");
>>     }
>> 
>>     @Override
>>     public int read() throws IOException{
>>       System.out.println("read called");
>>       throw new IOException("test");
>>     }
>> 
>>     @Override
>>     public void close() throws IOException{
>>       System.out.println("close called");
>>       super.close();
>>     }
>> 
>>   }
>> 
>>   public static void main(String[] args) throws Exception{
>>     var http = HttpClient.newHttpClient();
>>     var request = HttpRequest.newBuilder()
>>                              .uri(URI.create("http://httpbin.org/post"))
>>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>>                              .build();
>>     http.send(request, HttpResponse.BodyHandlers.discarding());
>>     System.out.println("Press any key to exit...");
>>     System.in.read();
>>   }
>> }
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw UIOE when stream throws IOE

test/jdk/java/net/httpclient/StreamCloseTest.java line 37:

> 35:  * @compile ../../../com/sun/net/httpserver/FileServerHandler.java
> 36:  * @build jdk.test.lib.net.SimpleSSLContext
> 37:  * @build LightWeightHttpServer

It would be preferable to avoid the use of LightWeightHttpServer in this test. The server-side seems trivial enough to implement locally in the test.

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

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

From dfuchs at openjdk.java.net  Thu Dec 10 10:12:35 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Dec 2020 10:12:35 GMT
Subject: Integrated: 8256459: java/net/httpclient/ManyRequests.java and
 java/net/httpclient/LineBodyHandlerTest.java fail infrequently with
 java.net.ConnectException: Connection timed out: no further information
In-Reply-To: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
References: <4yzbcrjUQ-gekvIcguTfu-FIq5F9f9EThXE364jFSvA=.5b069ec4-cb9d-4a20-9c1b-7170a1398e5c@github.com>
Message-ID: <ak_hnQppF-YI75djFnbgKCFyEh-g-cFT9YMjbdR_LMI=.0bef89f5-07a9-40b8-8ac6-608b657a854f@github.com>

On Wed, 9 Dec 2020 15:37:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, 
> 
> Please find here a changeset that fixes the infrequent (but annoying) test failures
> caused by unexpected ConnectionException "Connection timed out: no further information"
> which have been observed to occur on some platforms.
> 
> Tests are updated to allow the test server to handle requests concurrently.
> PlainHttpConnection is updated to retry connection once if chan::finishConnect fails
> early with ConnectionException and the connection timeout has not expired.

This pull request has now been integrated.

Changeset: 4a839e95
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a839e95
Stats:     172 lines in 6 files changed: 124 ins; 8 del; 40 mod

8256459: java/net/httpclient/ManyRequests.java and java/net/httpclient/LineBodyHandlerTest.java fail infrequently with java.net.ConnectException: Connection timed out: no further information

Reviewed-by: chegar

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

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

From dfuchs at openjdk.java.net  Thu Dec 10 10:16:40 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Dec 2020 10:16:40 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v3]
In-Reply-To: <fvl-M3j6gDfRC9XtGYSlK4eu-Y3QIa3BJxzkb7wUrGQ=.389bbcd0-1899-47b8-8dee-106a9dfb9c73@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <7ZGd-WyY6rP--gRB9FM91i3ZjvTZlHi2mgGw_aEJStM=.09faf307-32d0-4828-bbbc-60134fc5ebc4@github.com>
 <fvl-M3j6gDfRC9XtGYSlK4eu-Y3QIa3BJxzkb7wUrGQ=.389bbcd0-1899-47b8-8dee-106a9dfb9c73@github.com>
Message-ID: <5uQS6lck-36b72kOUs67YHYKN3Q3swEUqzAx4Z8BO7M=.67453311-7947-49cf-9ba1-86ccafbd620c@github.com>

On Thu, 10 Dec 2020 09:35:05 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw UIOE when stream throws IOE
>
> test/jdk/java/net/httpclient/StreamCloseTest.java line 37:
> 
>> 35:  * @compile ../../../com/sun/net/httpserver/FileServerHandler.java
>> 36:  * @build jdk.test.lib.net.SimpleSSLContext
>> 37:  * @build LightWeightHttpServer
> 
> It would be preferable to avoid the use of LightWeightHttpServer in this test. The server-side seems trivial enough to implement locally in the test.

I agree with Chris. In addition it will make it possible to check that the server either doesn't receive the request, or get an exception when it tries to read the body bytes.

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

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

From ysuenaga at openjdk.java.net  Fri Dec 11 02:17:13 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 11 Dec 2020 02:17:13 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v4]
In-Reply-To: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
Message-ID: <D8-8x8nLGt3RGjrDkEAy8hu9kZZQTp6hYaAkVIq1rKQ=.87568ddb-b9df-4ac8-8774-1dc8e9b9953c@github.com>

> `InputStream` from `BodyPublishers.ofInputStream()` is usually closed when the stream reaches EOF. However IOE handler returns without closing.
> 
> I confirmed this problem in `BodyPublishers.ofInputStream()`, but I think `BodyPublishers.ofFile()`has same problem because it also use `StreamIterator`as well as `ofInputStream()`.
> 
> 
> # How to reproduce:
> 
> Following code (Test.java) attempts to post body from `TestInputStream` which throws IOE in `read()`. "close called" is shown on the console if `close()` is called.
> 
> import java.io.*;
> import java.net.*;
> import java.net.http.*;
> 
> public class Test{
> 
>   private static class TestInputStream extends InputStream{
> 
>     public TestInputStream(){
>       super();
>       System.out.println("test c'tor");
>     }
> 
>     @Override
>     public int read() throws IOException{
>       System.out.println("read called");
>       throw new IOException("test");
>     }
> 
>     @Override
>     public void close() throws IOException{
>       System.out.println("close called");
>       super.close();
>     }
> 
>   }
> 
>   public static void main(String[] args) throws Exception{
>     var http = HttpClient.newHttpClient();
>     var request = HttpRequest.newBuilder()
>                              .uri(URI.create("http://httpbin.org/post"))
>                              .POST(HttpRequest.BodyPublishers.ofInputStream(() -> new TestInputStream()))
>                              .build();
>     http.send(request, HttpResponse.BodyHandlers.discarding());
>     System.out.println("Press any key to exit...");
>     System.in.read();
>   }
> }

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1614/files
  - new: https://git.openjdk.java.net/jdk/pull/1614/files/d9628c8e..95badebc

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

  Stats: 53 lines in 1 file changed: 35 ins; 9 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1614.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1614/head:pull/1614

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

From ysuenaga at openjdk.java.net  Fri Dec 11 02:22:55 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 11 Dec 2020 02:22:55 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v3]
In-Reply-To: <5uQS6lck-36b72kOUs67YHYKN3Q3swEUqzAx4Z8BO7M=.67453311-7947-49cf-9ba1-86ccafbd620c@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <7ZGd-WyY6rP--gRB9FM91i3ZjvTZlHi2mgGw_aEJStM=.09faf307-32d0-4828-bbbc-60134fc5ebc4@github.com>
 <fvl-M3j6gDfRC9XtGYSlK4eu-Y3QIa3BJxzkb7wUrGQ=.389bbcd0-1899-47b8-8dee-106a9dfb9c73@github.com>
 <5uQS6lck-36b72kOUs67YHYKN3Q3swEUqzAx4Z8BO7M=.67453311-7947-49cf-9ba1-86ccafbd620c@github.com>
Message-ID: <3_QpJEqOapNlISpq3vEA6axP2riJ0npbpSatoLLWSqA=.35eb2452-3019-45bd-956b-d2e93c1be91b@github.com>

On Thu, 10 Dec 2020 10:13:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/StreamCloseTest.java line 37:
>> 
>>> 35:  * @compile ../../../com/sun/net/httpserver/FileServerHandler.java
>>> 36:  * @build jdk.test.lib.net.SimpleSSLContext
>>> 37:  * @build LightWeightHttpServer
>> 
>> It would be preferable to avoid the use of LightWeightHttpServer in this test. The server-side seems trivial enough to implement locally in the test.
>
> I agree with Chris. In addition it will make it possible to check that the server either doesn't receive the request, or get an exception when it tries to read the body bytes.

I updated testcase not to use `LightWeightHttpServer`.

This test is for `HttpClient`, and HTTP server might work in undefined behavior if the error happens in client side (I guess it would be handled as an error in most case). So this test does not check request headers/body from the client.

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

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

From minqi at openjdk.java.net  Fri Dec 11 05:17:33 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 05:17:33 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <mBghLCvd_6OOPgNdUHyl6QGPV9V_C30p2ILwh4bwIac=.4c28be41-fc69-432a-aa39-5f2ccb9820fc@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Added test case; Fixed an nmt issue caused by bitmap region not released after archive loading failed; Unmap bitmap after archive failure. Fixed reserved region name for adding reserved region.
 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/29a09c89...0421943d

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

Changes: https://git.openjdk.java.net/jdk/pull/1657/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=04
  Stats: 8183 lines in 159 files changed: 4666 ins; 2763 del; 754 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:56 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:56 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
 <vtqmULMCnP8KBSPw6V_NFKvYVQzd9nAT9Y4V-N3j9Zs=.3c935956-78ef-491f-b209-eca535b8ca40@github.com>
 <sAqnH0sEch5UPQIwaz0vgcwVE9P_8WS-FSBmH7VU4IQ=.d6161796-38fa-4267-a62d-4dbb82689af4@github.com>
 <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
Message-ID: <gxcE4bVzUGSQ_clecIjrse_78xNKil4-urgXqWbJmhU=.cadaa2df-7141-45a0-8d2e-e0d15d36f00c@github.com>

On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
> Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks

This branch has many conflicts, something wrong since push-02, closed this PR and will send a single patch in new PR.

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

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:57 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:57 GMT
Subject: Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region"
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <9Hu8Jqsqm4gG7-yV0AZIZvnOh72CmunbbQhdT-LnjBA=.da14a187-fb1b-4190-9e4b-d06896ad7202@github.com>

On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.java.net  Fri Dec 11 08:10:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Dec 2020 08:10:00 GMT
Subject: RFR: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref) [v2]
In-Reply-To: <5M77MEUJ1maHc4HF-c51D-ujj1UdlHU1gy8hIZQ_HhU=.65c5273a-6d20-499d-a4d9-f35aa5e38767@github.com>
References: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
 <wD6tW7t9ifYdjZLzY-kKryCoyHlCxS-YUffbG-TQzO0=.e0fa3e83-22df-46e2-87b2-ac5683feefa1@github.com>
 <5M77MEUJ1maHc4HF-c51D-ujj1UdlHU1gy8hIZQ_HhU=.65c5273a-6d20-499d-a4d9-f35aa5e38767@github.com>
Message-ID: <ZDaq1_86Cen1VL6TC17J1qIFjFWnsnGGa8YYPYes7OM=.2426da33-d22f-4280-b80f-6287a1a9ff22@github.com>

On Fri, 27 Nov 2020 09:59:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into url
>>  - 8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)
>
> Marked as reviewed by dfuchs (Reviewer).

I think Daniel is going to sponsor this.

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

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

From dfuchs at openjdk.java.net  Fri Dec 11 13:17:57 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Dec 2020 13:17:57 GMT
Subject: RFR: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref) [v2]
In-Reply-To: <ZDaq1_86Cen1VL6TC17J1qIFjFWnsnGGa8YYPYes7OM=.2426da33-d22f-4280-b80f-6287a1a9ff22@github.com>
References: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
 <wD6tW7t9ifYdjZLzY-kKryCoyHlCxS-YUffbG-TQzO0=.e0fa3e83-22df-46e2-87b2-ac5683feefa1@github.com>
 <5M77MEUJ1maHc4HF-c51D-ujj1UdlHU1gy8hIZQ_HhU=.65c5273a-6d20-499d-a4d9-f35aa5e38767@github.com>
 <ZDaq1_86Cen1VL6TC17J1qIFjFWnsnGGa8YYPYes7OM=.2426da33-d22f-4280-b80f-6287a1a9ff22@github.com>
Message-ID: <EIrVT_XqPDP0lF_gqvEjY4eL16Koqx9-uKYnq_a1bEg=.80b42cd3-823f-4dc1-ad22-d3db2936c72b@github.com>

On Fri, 11 Dec 2020 08:06:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Marked as reviewed by dfuchs (Reviewer).
>
> I think Daniel is going to sponsor this.

Sorry - I lost track of this - thanks of reminding me. I will sponsor later today.

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

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

From daniel.fuchs at oracle.com  Fri Dec 11 13:18:59 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 11 Dec 2020 13:18:59 +0000
Subject: icmp and raw sockets on linux
In-Reply-To: <CADbpLFuSDWQ8KpdopMZCBMugGi0qkGoJBFNaJY0D1PfS-Hj6uA@mail.gmail.com>
References: <CADbpLFuTbR2PE5Y+tibOWwAK+BHGLsbt4t6SmA8HP5Renws5tA@mail.gmail.com>
 <c15979a1-9bdc-f3fe-3786-473130f2b32b@oracle.com>
 <CADbpLFvZDLy=enXRZysiEsd4qHRZ7KM7cZgHdryeFtn7vvq_cQ@mail.gmail.com>
 <e97877b9-4c8b-81f8-933f-3d80a5b9963e@oracle.com>
 <CADbpLFtBmw3fcCh9nhSbMSywcwZjE0CkqTpDYzFZq3+QJnX0kQ@mail.gmail.com>
 <CADbpLFuSDWQ8KpdopMZCBMugGi0qkGoJBFNaJY0D1PfS-Hj6uA@mail.gmail.com>
Message-ID: <c202340d-7914-6507-53b1-911150e460d7@oracle.com>

I Jamie,

Yes - you will need at least one Reviewer and then a sponsor.
 From the brief glance I had at your patch it looked reasonable.
Let me have a deeper look.

best regards,

-- daniel

On 09/12/2020 18:35, Jamie Le Tual wrote:
> I'm wondering what the process is for the pull request I submitted, I 
> guess I need a reviewer or a sponsor?
> 
> 
> On Tue, 1 Dec 2020 at 14:08, Jamie Le Tual <jamie.letual at gmail.com 
> <mailto:jamie.letual at gmail.com>> wrote:
> 
>     Hi Alan,
>     I received an email this morning saying my OCA had been processed,
>     but that it would perhaps take a couple of hours before a bot picks
>     it up and I show up on the OCA signatories page (no idea where that
>     page is though).
> 
>     I have also updated the patch in my pull request to cover ipv6 as well.
> 
>     Test cases are forthcoming.
> 
> 
>     On Sun, 29 Nov 2020 at 11:35, Alan Bateman <Alan.Bateman at oracle.com
>     <mailto:Alan.Bateman at oracle.com>> wrote:
> 
>         On 29/11/2020 14:54, Jamie Le Tual wrote:
>>         Although?I've only just sent in the pdf form for an ora, I've
>>         already submitted a pull request,
>>         https://github.com/openjdk/jdk/pull/1502
>>         <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1502__;!!GqivPVa7Brio!JhGUqeElAhEy9M_c0xBiYFVZQXX0YeHTlOrypbtjph_VrhY7t4LmgPpmxNpSAwLCuA$>
>>         wherein an attempt?is first made to use an IPPROTO_ICMP socket
>>         before falling back on RAW_SOCK and finally tcp echo.
>>
>>         I suppose now I have to wait until I am able to open an issue
>>         in the bug tracker so I can associate the pull request to it.
>>
>>         Does anyone know what a unit test for this might look like? To
>>         cover the use cases the code has to be invoked by both a
>>         privileged?and unprivileged user, and I'm not sure how to go
>>         about setting up a unit test.
> 
>         I've created JDK-8257235 [1] to track this. One thing to
>         understand is whether there is an equivalent for IPPROTO_ICMPV6.
>         Sorry, I can't look at the patch or comment in the PR until the
>         bot confirms that you have signed the OCA.
> 
>         Have you looked at the existing tests in
>         test/jdk/java/net/InetAddress? It will be awkward to verify as
>         the behaviour before/after will not be observable without
>         looking at the network or system call trace.
> 
>         -Alan
> 
>         [1] https://bugs.openjdk.java.net/browse/JDK-8257235
>         <https://bugs.openjdk.java.net/browse/JDK-8257235>
> 


From ccleary at openjdk.java.net  Fri Dec 11 16:09:58 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 11 Dec 2020 16:09:58 GMT
Subject: Integrated: 8255583: Investigate creating a test to trigger the
 condition in KeepAliveStreamCleaner
In-Reply-To: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
References: <vmLWgysPizZbjYlmx9klRZ8HbY5wv-UXIRB8ouOIx08=.81536d06-654d-4f1a-ab08-8dea84bc89dc@github.com>
Message-ID: <ZDSv0R1AwKWw-rCeHZpD0xrBuGck77Pqjygqn2h7eag=.10412811-da61-48aa-ab9a-abc3d45b5974@github.com>

On Mon, 7 Dec 2020 09:52:47 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen to fail with an IllegalMonitorStateException. This failure was caused by the use of `wait()` in a non synchronized block. This failure was mitigated through use of `await()` instead as is shown below (code can be viewed on L119 in src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java).
> 
> ...
> long timeout = TIMEOUT;
>     while ((kace = poll()) == null) {
>             waiter.await(timeout, TimeUnit.MILLISECONDS); 
> ...
> While the code throwing the exception was fixed, a regression test was not made. So this patch adds a simple white-box test which calls the KeepAliveStreamCleaner's run method. `waiter.wait()` should always fail if not used in a synchronized block or method, so the test verifies that it is not used.

This pull request has now been integrated.

Changeset: f9c9bf03
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f9c9bf03
Stats:     70 lines in 2 files changed: 70 ins; 0 del; 0 mod

8255583: Investigate creating a test to trigger the condition in KeepAliveStreamCleaner

Reviewed-by: dfuchs, chegar, michaelm

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

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

From dfuchs at openjdk.java.net  Fri Dec 11 16:43:00 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Dec 2020 16:43:00 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v2]
In-Reply-To: <g3duzWw2PCGZMo9S0iYCi2UEL5iF6P5foOAS2x7rogU=.95e7bf57-d0eb-46c3-97af-df69843ca5f2@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <g3duzWw2PCGZMo9S0iYCi2UEL5iF6P5foOAS2x7rogU=.95e7bf57-d0eb-46c3-97af-df69843ca5f2@github.com>
Message-ID: <G0UCJD7rh_kKcymT_B3KsYszmHILwi1fTTSA2xaj41k=.d5adc757-9744-4e59-a99a-f580d15fa584@github.com>

On Tue, 8 Dec 2020 16:51:02 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Changes requested by dfuchs (Reviewer).

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 63:

> 61:         httpServer = HttpServer.create();
> 62:         //let the server use wild card address
> 63:         inetAddress = null;

can this constructor simply call `this(null, context, docRoot)`

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 83:

> 81:         //let the server use wild card address
> 82:         inetAddress = null;
> 83:     }

Ideally, all constructors should all delegate to a single constructor that would do all the assignments. Maybe investigate a constructor that takes an InetSocketAddress (that would contain both InetAddress and port)

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 94:

> 92:         httpServer.setExecutor(executor);
> 93:         httpServer.start();
> 94:         address = "http://localhost:" + httpServer.getAddress().getPort();

It might be a better idea to use the URIBuilder here rather than relying on the local machine configuration to resolve "localhost";

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Dec 11 21:01:18 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 11 Dec 2020 21:01:18 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v3]
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <cTMcanZpLY96Q5sAVxV4suGm81F8mMmmT_clGLK6n80=.6afdbc09-04c6-4ce9-958a-7e73dae2d3e4@github.com>

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemnted the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1632/files
  - new: https://git.openjdk.java.net/jdk/pull/1632/files/71fc7e9f..54529720

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

  Stats: 81 lines in 4 files changed: 11 ins; 28 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Dec 11 21:06:00 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 11 Dec 2020 21:06:00 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v2]
In-Reply-To: <G0UCJD7rh_kKcymT_B3KsYszmHILwi1fTTSA2xaj41k=.d5adc757-9744-4e59-a99a-f580d15fa584@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <g3duzWw2PCGZMo9S0iYCi2UEL5iF6P5foOAS2x7rogU=.95e7bf57-d0eb-46c3-97af-df69843ca5f2@github.com>
 <G0UCJD7rh_kKcymT_B3KsYszmHILwi1fTTSA2xaj41k=.d5adc757-9744-4e59-a99a-f580d15fa584@github.com>
Message-ID: <i09ORxQLS4t5ER_eJYz82HLykx1ZIyavcuhkp5SKya8=.125e9f37-d2d8-43ec-8f96-d983dca5310d@github.com>

On Tue, 8 Dec 2020 18:01:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/lib/jdk/test/lib/net/SimpleHttpServer.java line 83:
> 
>> 81:         //let the server use wild card address
>> 82:         inetAddress = null;
>> 83:     }
> 
> Ideally, all constructors should all delegate to a single constructor that would do all the assignments. Maybe investigate a constructor that takes an InetSocketAddress (that would contain both InetAddress and port)

Now Constructor takes InetSocketAddress as parameter, so now no need of multiple constructors. Thanks for the advice.

> test/lib/jdk/test/lib/net/SimpleHttpServer.java line 63:
> 
>> 61:         httpServer = HttpServer.create();
>> 62:         //let the server use wild card address
>> 63:         inetAddress = null;
> 
> can this constructor simply call `this(null, context, docRoot)`

Now Constructor takes InetSocketAddress as parameter, so now no need of multiple constructors. Thanks for the advice.

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Dec 11 21:23:12 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 11 Dec 2020 21:23:12 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v4]
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <vAuKxzljzOE-k8Zy-7Mo5q7d6x28f-kBjoGoBLTVqa4=.df5e12ea-1d94-4bdd-b401-636a29b577b4@github.com>

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
 - Implemnted the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1632/files
  - new: https://git.openjdk.java.net/jdk/pull/1632/files/54529720..6f6a3c62

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 14 13:06:55 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 14 Dec 2020 13:06:55 GMT
Subject: Integrated: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref)
In-Reply-To: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
References: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
Message-ID: <mrNYBHEXYwE0hp9wRk2bXrQK5sWbYWblBd3pNSmKwBU=.6a64e24f-d8c5-4e21-9888-fcdb7add25fd@github.com>

On Wed, 21 Oct 2020 06:52:42 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hello, while working with `java.net.URL` I've found unused package-private method `URL.set(String protocol, String host, int port, String file, String ref)` which can be safely removed from JDK. Testing: tier1, tier2
> 
> Could someone crate an issue for tracking of this simple change?

This pull request has now been integrated.

Changeset: 15481041
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15481041
Stats:     33 lines in 1 file changed: 0 ins; 33 del; 0 mod

8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.java.net  Mon Dec 14 19:47:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 14 Dec 2020 19:47:59 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v4]
In-Reply-To: <vAuKxzljzOE-k8Zy-7Mo5q7d6x28f-kBjoGoBLTVqa4=.df5e12ea-1d94-4bdd-b401-636a29b577b4@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <vAuKxzljzOE-k8Zy-7Mo5q7d6x28f-kBjoGoBLTVqa4=.df5e12ea-1d94-4bdd-b401-636a29b577b4@github.com>
Message-ID: <z270dyBaAFWuk0CliW046OPZ1_VhdokjZd6uHnsBrwo=.e8f131fa-c799-4f4b-a6b7-797b441147f5@github.com>

On Fri, 11 Dec 2020 21:23:12 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
>  - Implemnted the review comments.

Changes requested by dfuchs (Reviewer).

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 105:

> 103:                     Path fPath;
> 104:                     try {
> 105:                         fPath = Paths.get(docRoot, path);

Hi Mahendra,

I am not comfortable with this. You cannot just concatenate a file system path with a URI path in the general case (think windows file system). I would suggest to transform docRoot into a root URI using `Path.of(docRoot).toURI().normalize()` - then you can probably concatenate the string representation of this root URI with the *raw path* extracted from the request URI, normalize that again (to remove potential double slashes) and convert that back into a Path using Path.of(URI). 
Some additional conditions might need to be asserted:
 - `t.getRequestURI().getRawPath()` should either be empty or start with `"/"` (and even that may be a bit lax)
 - the resulting URI you obtain (after normalization and before converting back to Path) should either be equal to the root URI or start with the root URI.
`(rootURI.toString().equals(uri.toString()) || uri.toString().startsWith(rootUri.toString() + "/") )`

best regards,

-- daniel

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

I believe this changes is useful and still actual:
1. improve code to make it easier to read.
2. performance should be improved a bit too

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof
 check in java.base
Message-ID: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>

8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.base

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

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

From smarks at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
Message-ID: <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>

On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> I believe this changes is useful and still actual:
> 1. improve code to make it easier to read.
> 2. performance should be improved a bit too

I?ll see if I can get somebody to take a look at this.

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

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

From chegar at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
Message-ID: <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>

On Sat, 31 Oct 2020 19:37:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I believe this changes is useful and still actual:
>> 1. improve code to make it easier to read.
>> 2. performance should be improved a bit too
>
> I?ll see if I can get somebody to take a look at this.

This seems like a reasonable change, which improves readability.

My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -2191,8 +2191,8 @@ public class File
      *          {@code false} otherwise
      */
     public boolean equals(Object obj) {
-        if ((obj != null) && (obj instanceof File)) {
-            return compareTo((File)obj) == 0;
+        if (obj instanceof File file) {
+            return compareTo(file) == 0;
         }
         return false;
     }

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
 <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
Message-ID: <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>

On Mon, 2 Nov 2020 09:15:31 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> I?ll see if I can get somebody to take a look at this.
>
> This seems like a reasonable change, which improves readability.
> 
> My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -2191,8 +2191,8 @@ public class File
>       *          {@code false} otherwise
>       */
>      public boolean equals(Object obj) {
> -        if ((obj != null) && (obj instanceof File)) {
> -            return compareTo((File)obj) == 0;
> +        if (obj instanceof File file) {
> +            return compareTo(file) == 0;
>          }
>          return false;
>      }

Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448

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

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

From aefimov at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
 <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
 <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>
Message-ID: <CUAgVMeEaogYo63HvIEQ8toOHSTHrirp-dG8jPXzLf0=.3e82b0b1-e38f-44e5-9ee4-75faee04ac24@github.com>

On Wed, 2 Dec 2020 20:15:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This seems like a reasonable change, which improves readability.
>> 
>> My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:
>> 
>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -2191,8 +2191,8 @@ public class File
>>       *          {@code false} otherwise
>>       */
>>      public boolean equals(Object obj) {
>> -        if ((obj != null) && (obj instanceof File)) {
>> -            return compareTo((File)obj) == 0;
>> +        if (obj instanceof File file) {
>> +            return compareTo(file) == 0;
>>          }
>>          return false;
>>      }
>
> Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448

Hi @turbanoff,

I've logged a JBS issue for tracking this change:
https://bugs.openjdk.java.net/browse/JDK-8258422

JEP 394 is finalized now, so I guess you could follow-up Chris suggestion to remove the explicit casts.

After the fix is properly reviewed and marked as ready for the integration (you'll need to issue `/integrate` command), once it is done I would happily `/sponsor` the change.

With Best Regards,
Aleksei

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 19:52:31 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 19:52:31 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v2]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

 - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
   use instanceof pattern matching
 - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/f09bbd24..603cd364

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

  Stats: 784681 lines in 7664 files changed: 596718 ins; 128884 del; 59079 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

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

From alanb at openjdk.java.net  Wed Dec 16 07:16:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 07:16:00 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v2]
In-Reply-To: <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>
Message-ID: <_LvzyyCLPoXsNJNNlU_qBmje3U5RvwKifXod1bN5Yc8=.b11b4f6e-16e0-4f92-a052-b55dc2fecb33@github.com>

On Tue, 15 Dec 2020 19:52:31 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>    use instanceof pattern matching
>  - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 803:

> 801:         if (obj instanceof WindowsPath path) {
> 802:             return compareTo(path) == 0;
> 803:         }

Can you do the same in UnixPath?

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

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

From bmarwell at apache.org  Wed Dec 16 08:09:08 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Wed, 16 Dec 2020 09:09:08 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a socket
Message-ID: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>

Hello everyone,

I would like to bring up the enhancement JDK-8257080[1] on this mailing
list.

tl;dr symptoms:
Java will use the first IP address from DNS and will fail to connect when
the target host is offline, even when the other IPs would have worked. This
is also true for the more recent Socket implementations from Java 14
onwards..

Proposed resolution:
Implementation similar to python. Late(r) DNS resolution when the socket is
being opened (i.e. a target port is known), then iterate over IP addresses
returned by DNS and try a socket_open.

Workarounds:
None. It is not possible to write an agent which alters java.net classes,
as they are protected.

I would like to bring this issue to your attention. I reported it using my
work mail at oracle?s bug tracker, but I think other applications might
suffer from this as well.

Best regards,
Ben

[1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8257080
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201216/b824029e/attachment.htm>

From Alan.Bateman at oracle.com  Wed Dec 16 08:41:44 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Dec 2020 08:41:44 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
Message-ID: <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>

On 16/12/2020 08:09, Benjamin Marwell wrote:
> Hello everyone,
>
> I would like to bring up the enhancement JDK-8257080[1] on this 
> mailing list.
>
> tl;dr symptoms:
> Java will use the first IP address from DNS and will fail to connect 
> when the target host is offline, even when the other IPs would have 
> worked. This is also true for the more recent Socket implementations 
> from Java 14 onwards..
>
> Proposed resolution:
> Implementation similar to python. Late(r) DNS resolution when the 
> socket is being opened (i.e. a target port is known), then iterate 
> over IP addresses returned by DNS and try a socket_open.
>
I can't tell if your proposal is focused on the Socket constructors that 
take a hostname or more generally changing all APIs that connect to a 
SocketAddress to support connecting to an isUnresolved 
InetSocketAddress. There is merit into exploring this, as is exploring 
new APIs. Experience with Python and other run-times would be useful. I 
could imagine prototypes that range from a simple API that iterates 
through the IP address to implementations of the Happy Eyeballs RFC and 
other algorithms to improve the user experience when a connection is 
slow to establish. There is synergy between such exploration and other 
efforts, including the ongoing work to add a service provider interface 
for name resolution that will open the door to improved APIs for user 
facing applications.

-Alan

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 09:20:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 09:20:09 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  use instanceof pattern matching in UnixPath too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/603cd364..0d2ac405

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

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

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

From chegar at openjdk.java.net  Wed Dec 16 09:47:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 16 Dec 2020 09:47:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
Message-ID: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>

On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   use instanceof pattern matching in UnixPath too

Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.

src/java.base/share/classes/java/net/InetSocketAddress.java line 414:

> 412:         if (!(obj instanceof InetSocketAddress))
> 413:             return false;
> 414:         return holder.equals(((InetSocketAddress) obj).holder);

If we restructure this a little we can get:

    public final boolean equals(Object obj) {
        if (obj instanceof InetSocketAddress that)
            return holder.equals(that.holder);
        return false;
    }

src/java.base/share/classes/java/net/InetSocketAddress.java line 124:

> 122:             if (!(obj instanceof InetSocketAddressHolder))
> 123:                 return false;
> 124:             InetSocketAddressHolder that = (InetSocketAddressHolder)obj;

If we restructure this a little we can take advantage of flow scoping, e.g.

 public final boolean equals(Object obj) {
            if (!(obj instanceof InetSocketAddressHolder that))
                return false;
            boolean sameIP;
            if (addr != null)
                sameIP = addr.equals(that.addr);
            else if (hostname != null)
                sameIP = (that.addr == null) &&
                    hostname.equalsIgnoreCase(that.hostname);
            else
                sameIP = (that.addr == null) && (that.hostname == null);
            return sameIP && (port == that.port);
        }

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

Changes requested by chegar (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 10:32:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 10:32:12 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  take advantage of "flow scoping" to eliminate casts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/0d2ac405..f5727ca9

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

  Stats: 42 lines in 12 files changed: 1 ins; 10 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

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

From Alan.Bateman at oracle.com  Wed Dec 16 12:49:23 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Dec 2020 12:49:23 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
Message-ID: <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>

On 16/12/2020 09:04, Benjamin Marwell wrote:
> Hi Alan,
>
> > I can't tell if your proposal is focused on the Socket constructors
> > that take a hostname or more generally changing all APIs that
> > connect to a SocketAddress to support connecting to an
> > isUnresolved InetSocketAddress
>
> Way before we even get to sockets. I am talking about InetAddress.
> It?s resolving logic is resolve()[0]. That?s it. But an InetAddress 
> does not carry any
> port information and thus should not resolve in my opinion.
>
> ---
>
> I think I would start looking in java/net/AbstractPlainSocketImpl.java.
> These are the relevant lines: 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java#L149-L164 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java*L149-L164__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeSYGhb8tw$>
>
> For the new implementation these lines seem pretty relevant:
> https://github.com/openjdk/jdk/blob/51d5164ca2b4801c14466e8d1420ecf27cb7615f/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L560-L562 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/51d5164ca2b4801c14466e8d1420ecf27cb7615f/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java*L560-L562__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeQy8PBhSg$>
> That is where I would probably add the for loop.
>
> Here is python?s implementation as a reference:
> https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/socket.py#L707-L719 
> <https://urldefense.com/v3/__https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/socket.py*L707-L719__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeTvZM9G2A$>
>
> By the way, any changes would solve a few other issues as well:
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8201428 
> <https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8201428__;!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeQkc7Ex1w$>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780 
> <https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780__;!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeSpuxbIvA$>
>

If I read your mail correctly, I think what you are proposing is to 
change the existing APIs to allow an unresolved InetSocketAddress to be 
specified, is that right? I suspect this approach will have a lot of 
implications for methods that are called after the socket is created as 
it would require re-creating the underlying socket when a connect 
attempt fails (the socket may have been explicitly bound or socket 
options were set). There are issues with the semantics of the timeout 
parameter. It might not be possible to even do this with APIs such as 
SocketChannel when the channel is configured non-blocking.

If the starting point is the Socket constructor that takes a host name 
and port then it might be easier because that can do the lookup and 
cycle through the addresses and/or overlap the connection attempts.

If you have cycles to do experiments and report back then it would be 
useful. I assume the attractiveness of changing the existing APIs is so 
that existing usages, e.g. HTTP protocol handler, could use it without 
changing to a new APIs. Maybe changing existing vs. new API could be 
part of your investigation? I think it would also be useful to know if a 
simple iteration through the addresses is sufficient for more cases or 
whether something close to Happy Eyeballs would be needed. There have 
been a few discussions here over the years on the latter as it is hard 
to get right and there may be a case of having support for that in the APIs.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201216/66f3bac7/attachment.htm>

From bmarwell at apache.org  Wed Dec 16 13:40:22 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Wed, 16 Dec 2020 14:40:22 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
Message-ID: <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>

On 16.12.20 13:49, Alan Bateman wrote:
> On 16/12/2020 09:04, Benjamin Marwell wrote:
>> Hi Alan,
>>
>> > I can't tell if your proposal is focused on the Socket constructors
>> > that take a hostname or more generally changing all APIs that
>> > connect to a SocketAddress to support connecting to an
>> > isUnresolved InetSocketAddress
>>
>> Way before we even get to sockets. I am talking about InetAddress.
>> It?s resolving logic is resolve()[0]. That?s it. But an InetAddress 
>> does not carry any
>> port information and thus should not resolve in my opinion.
>>
>> ---
>>
>> I think I would start looking in java/net/AbstractPlainSocketImpl.java.
>> These are the relevant lines: 
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java#L149-L164 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java*L149-L164__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeSYGhb8tw$> 
>>
>>
>> For the new implementation these lines seem pretty relevant:
>> https://github.com/openjdk/jdk/blob/51d5164ca2b4801c14466e8d1420ecf27cb7615f/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L560-L562 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/51d5164ca2b4801c14466e8d1420ecf27cb7615f/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java*L560-L562__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeQy8PBhSg$> 
>>
>> That is where I would probably add the for loop.
>>
>> Here is python?s implementation as a reference:
>> https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/socket.py#L707-L719 
>> <https://urldefense.com/v3/__https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/socket.py*L707-L719__;Iw!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeTvZM9G2A$> 
>>
>>
>> By the way, any changes would solve a few other issues as well:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8201428 
>> <https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8201428__;!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeQkc7Ex1w$> 
>>
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780 
>> <https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780__;!!GqivPVa7Brio!IQGo98vib-LqfZaVN1Y7MJ51_ZRRrljY_n6IM-btaxHD3suFHe77kiBgTeSpuxbIvA$> 
>>
>>
> 
> If I read your mail correctly, I think what you are proposing is to 
> change the existing APIs to allow an unresolved InetSocketAddress to be 
> specified, is that right? I suspect this approach will have a lot of 
> implications for methods that are called after the socket is created as 
> it would require re-creating the underlying socket when a connect 
> attempt fails (the socket may have been explicitly bound or socket 
> options were set). There are issues with the semantics of the timeout 
> parameter. It might not be possible to even do this with APIs such as 
> SocketChannel when the channel is configured non-blocking.
> 
> If the starting point is the Socket constructor that takes a host name 
> and port then it might be easier because that can do the lookup and 
> cycle through the addresses and/or overlap the connection attempts.
> 
> If you have cycles to do experiments and report back then it would be 
> useful. I assume the attractiveness of changing the existing APIs is so 
> that existing usages, e.g. HTTP protocol handler, could use it without 
> changing to a new APIs. Maybe changing existing vs. new API could be 
> part of your investigation? I think it would also be useful to know if a 
> simple iteration through the addresses is sufficient for more cases or 
> whether something close to Happy Eyeballs would be needed. There have 
> been a few discussions here over the years on the latter as it is hard 
> to get right and there may be a case of having support for that in the 
> APIs.
> 
> -Alan
> 
> 
> 

Huh? the APIs have already been changed which is why the issues above 
exist. There is no workaround anymore.

It is true that I did not take into account that other methods would 
rely on this. The biggest issue I see (easily) is the connect timeout.
It must either be distributed along all connection attempts or per 
connection attempt ? both would change semantics.

I just looked up Happy Eyeballs, and this comes very close to
what I mean. I like that it implies DNS-RR.

Lets see if I (or anyone else) can come up with a sample implementation.

Thanks,
Ben


From Alan.Bateman at oracle.com  Wed Dec 16 15:12:34 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Dec 2020 15:12:34 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
Message-ID: <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>

On 16/12/2020 13:40, Benjamin Marwell wrote:
>
> Huh? the APIs have already been changed which is why the issues above 
> exist. There is no workaround anymore.

Can you expand on this as it's not clear what you mean by "the APIs have 
already changed"? The code that you referenced are implementation 
classes, not exposed.

-Alan.

From bmarwell at apache.org  Wed Dec 16 15:21:50 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Wed, 16 Dec 2020 16:21:50 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
Message-ID: <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>

On 16.12.20 16:12, Alan Bateman wrote:
> On 16/12/2020 13:40, Benjamin Marwell wrote:
>>
>> Huh? the APIs have already been changed which is why the issues above 
>> exist. There is no workaround anymore.
> 
> Can you expand on this as it's not clear what you mean by "the APIs have 
> already changed"? The code that you referenced are implementation 
> classes, not exposed.
> 
> -Alan.

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780

Granted, it is an SPI. But it seemed to have been used.


From Alan.Bateman at oracle.com  Wed Dec 16 15:42:16 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Dec 2020 15:42:16 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
Message-ID: <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>

On 16/12/2020 15:21, Benjamin Marwell wrote:
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780
>
> Granted, it is an SPI. But it seemed to have been used.
>

Aleksej Efimov is working on an InetAddress SPI, I'm sure there will be 
a draft JEP at some point. It has the potential to complement the 
exploration that we discussing here.

-Alan

From aleksej.efimov at oracle.com  Wed Dec 16 16:53:02 2020
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 16 Dec 2020 16:53:02 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
Message-ID: <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>

Hi Benjamin,

As Alan stated I'm working on adding an SPI [1] which will provide a 
possibility to alter how host names and IP addresses are resolved by JDK 
platform.
I believe it would be possible to use this mechanism for addressing 
issue described in JDK-8257080.

Best Regards,
Aleksei

[1] WIP jdk-sandbox branch: 
https://github.com/openjdk/jdk-sandbox/tree/JDK-8244202-nspi-stream-branch


On 16/12/2020 15:42, Alan Bateman wrote:
> On 16/12/2020 15:21, Benjamin Marwell wrote:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780
>>
>> Granted, it is an SPI. But it seemed to have been used.
>>
>
> Aleksej Efimov is working on an InetAddress SPI, I'm sure there will 
> be a draft JEP at some point. It has the potential to complement the 
> exploration that we discussing here.
>
> -Alan


From aefimov at openjdk.java.net  Wed Dec 16 18:29:56 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Dec 2020 18:29:56 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
Message-ID: <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>

On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   use instanceof pattern matching in UnixPath too
>
> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.

Hi Andrey,

Could you, please, also take a look at `java.net.Socket`:
java/net/Socket.java:        if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress)))
java/net/Socket.java-            throw new IllegalArgumentException("Unsupported address type");
And `HttpURLConnection`:
    sun/net/www/protocol/http/HttpURLConnection.java:                    if (a != null && c instanceof HttpURLConnection) {
    sun/net/www/protocol/http/HttpURLConnection.java-                        ((HttpURLConnection)c).setAuthenticator(a);
The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "`

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 19:22:01 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 19:22:01 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
 <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>
Message-ID: <PsCRfKfKNe5DhzumlSgAd_iFi0Zh1lcd45OoG3ztd28=.2f611fd2-ee81-4709-865d-40022a86659d@github.com>

On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.
>
> Hi Andrey,
> 
> Could you, please, also take a look at `java.net.Socket`:
> java/net/Socket.java:        if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress)))
> java/net/Socket.java-            throw new IllegalArgumentException("Unsupported address type");
> And `HttpURLConnection`:
>     sun/net/www/protocol/http/HttpURLConnection.java:                    if (a != null && c instanceof HttpURLConnection) {
>     sun/net/www/protocol/http/HttpURLConnection.java-                        ((HttpURLConnection)c).setAuthenticator(a);
> The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "`

@AlekseiEfimov in both cases removing `null` check will change semantic of the code. Comparison is not redundant.

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

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

From ecki at zusammenkunft.net  Wed Dec 16 19:32:33 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 16 Dec 2020 19:32:33 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>,
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
Message-ID: <AM0PR03MB4145C72C06A70DD788F2F150FFC50@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

A ?happy eyeballs? implementation, not only for Multiple IPv4 addresses but also for IPV6/IPv4 Mixed would be a good thing, however since this

a) adds additional connection Timeouts or decreases connection deadlines
b) potentially is stateful

I think it?s not a good idea to enable it for all connections. A new method to specify a policy (and allow a new default policy) would probably be better.

I don?t think doing that in the resolving alone would work, since there is also a question of parallelity and a endpoint specific state.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Aleks Efimov <aleksej.efimov at oracle.com>
Gesendet: Wednesday, December 16, 2020 5:53:02 PM
An: Benjamin Marwell <bmarwell at apache.org>
Cc: Alan Bateman <Alan.Bateman at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Betreff: Re: [JDK-8257080] Java does not try all DNS results when opening a socket

Hi Benjamin,

As Alan stated I'm working on adding an SPI [1] which will provide a
possibility to alter how host names and IP addresses are resolved by JDK
platform.
I believe it would be possible to use this mechanism for addressing
issue described in JDK-8257080.

Best Regards,
Aleksei

[1] WIP jdk-sandbox branch:
https://github.com/openjdk/jdk-sandbox/tree/JDK-8244202-nspi-stream-branch


On 16/12/2020 15:42, Alan Bateman wrote:
> On 16/12/2020 15:21, Benjamin Marwell wrote:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780
>>
>> Granted, it is an SPI. But it seemed to have been used.
>>
>
> Aleksej Efimov is working on an InetAddress SPI, I'm sure there will
> be a draft JEP at some point. It has the potential to complement the
> exploration that we discussing here.
>
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201216/b6353087/attachment-0001.htm>

From simone.bordet at gmail.com  Wed Dec 16 19:59:34 2020
From: simone.bordet at gmail.com (Simone Bordet)
Date: Wed, 16 Dec 2020 20:59:34 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
Message-ID: <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>

Hi,

On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>
> Hi Benjamin,
>
> As Alan stated I'm working on adding an SPI [1] which will provide a
> possibility to alter how host names and IP addresses are resolved by JDK
> platform.
> I believe it would be possible to use this mechanism for addressing
> issue described in JDK-8257080.

Is it hopefully going to be non-blocking?

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From chegar at openjdk.java.net  Thu Dec 17 09:51:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 17 Dec 2020 09:51:58 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <8e6vsmTl1qRfnmuLSFn30Yy9ck2SJVcBjdR_flRzB60=.65cd22bb-6d0e-400b-a919-d9634c0f988a@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

Looks good to me.

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

Marked as reviewed by chegar (Reviewer).

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

From alanb at openjdk.java.net  Thu Dec 17 10:33:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Dec 2020 10:33:00 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:

> 100:      */
> 101:     public boolean equals(Object other) {
> 102:         if (this == other) {

It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 11:37:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 11:37:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
Message-ID: <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>

On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   take advantage of "flow scoping" to eliminate casts
>
> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:
> 
>> 100:      */
>> 101:     public boolean equals(Object other) {
>> 102:         if (this == other) {
> 
> It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.

Actually, I'm not sure if `oth` is better name for variable than `other1`.
I would say they have the same rank :)

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

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

From aefimov at openjdk.java.net  Thu Dec 17 13:18:59 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 17 Dec 2020 13:18:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

Thank you for checking `HttpURLConnection` and `Socket`.
The latest version looks good to me.

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

Marked as reviewed by aefimov (Committer).

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

From dfuchs at openjdk.java.net  Thu Dec 17 13:34:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 13:34:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
 <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
Message-ID: <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>

On Thu, 17 Dec 2020 11:35:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:
>> 
>>> 100:      */
>>> 101:     public boolean equals(Object other) {
>>> 102:         if (this == other) {
>> 
>> It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.
>
> Actually, I'm not sure if `oth` is better name for variable than `other1`.
> I would say they have the same rank :)

I believe Alan is suggesting to do:

    /**
     * Compares the equality of two <code>Signal</code> objects.
     *
     * @param obj the object to compare with.
     * @return whether two <code>Signal</code> objects are equal.
     */
    public boolean equals(Object obj) {
        if (this == obj) {

this leaves the variable name `other` free for later use inside the method.

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

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

From alanb at openjdk.java.net  Thu Dec 17 13:38:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Dec 2020 13:38:57 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
 <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
 <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>
Message-ID: <QDrICqJdKtCEC0VU02zOE-eFS7zMuTG8yg-qQU2ZNPc=.467a1222-ec6f-4365-bf84-5576e0801d6d@github.com>

On Thu, 17 Dec 2020 13:32:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Actually, I'm not sure if `oth` is better name for variable than `other1`.
>> I would say they have the same rank :)
>
> I believe Alan is suggesting to do:
> 
>     /**
>      * Compares the equality of two <code>Signal</code> objects.
>      *
>      * @param obj the object to compare with.
>      * @return whether two <code>Signal</code> objects are equal.
>      */
>     public boolean equals(Object obj) {
>         if (this == obj) {
> 
> this leaves the variable name `other` free for later use inside the method.

> Actually, I'm not sure if `oth` is better name for variable than `other1`.
> I would say they have the same rank :)

Sorry, I should have been clearer, the comment was about equals(Object other). If you rename "other" then it will avoid "other1"

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

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

From daniel.fuchs at oracle.com  Thu Dec 17 13:45:30 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 17 Dec 2020 13:45:30 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
Message-ID: <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>

Hi Simone,

We are investigating introducing a Service Provider interface
which would allow an application to replace the default
built-in implementation that blocks inside the kernel.

There is no plan to introduce any public asynchronous API to perform
address resolution at this point. With the advent of Loom and
virtual threads I'm not sure there would be much motivation for
that anyway.

best regards,

-- daniel

On 16/12/2020 19:59, Simone Bordet wrote:
> Hi,
> 
> On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>>
>> Hi Benjamin,
>>
>> As Alan stated I'm working on adding an SPI [1] which will provide a
>> possibility to alter how host names and IP addresses are resolved by JDK
>> platform.
>> I believe it would be possible to use this mechanism for addressing
>> issue described in JDK-8257080.
> 
> Is it hopefully going to be non-blocking?
> 


From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 14:01:14 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 14:01:14 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v5]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/f5727ca9..314217ec

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

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

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

From dfuchs at openjdk.java.net  Thu Dec 17 14:22:04 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 14:22:04 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v5]
In-Reply-To: <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>
Message-ID: <2d3umOCXurFwL9NlMzsBZbyN9U2o1p2VUisHHPzfaxU=.71d60783-f578-4111-a250-3b9820fc8d5a@github.com>

On Thu, 17 Dec 2020 14:01:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base

src/java.base/share/classes/jdk/internal/misc/Signal.java line 101:

> 99:      * @return whether two <code>Signal</code> objects are equal.
> 100:      */
> 101:     public boolean equals(Object oth) {

I'd  suggest to replace `oth` with `obj` and fix the `@param` clause in the method javadoc.

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

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

From chris.hegarty at oracle.com  Thu Dec 17 14:39:07 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 17 Dec 2020 14:39:07 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
Message-ID: <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>

Looping in a prior relevant issue in JIRA: 

https://bugs.openjdk.java.net/browse/JDK-8170568 - 
Improve address selection for network clients

-Chris.

> On 17 Dec 2020, at 13:45, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Simone,
> 
> We are investigating introducing a Service Provider interface
> which would allow an application to replace the default
> built-in implementation that blocks inside the kernel.
> 
> There is no plan to introduce any public asynchronous API to perform
> address resolution at this point. With the advent of Loom and
> virtual threads I'm not sure there would be much motivation for
> that anyway.
> 
> best regards,
> 
> -- daniel
> 
> On 16/12/2020 19:59, Simone Bordet wrote:
>> Hi,
>> On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>>> 
>>> Hi Benjamin,
>>> 
>>> As Alan stated I'm working on adding an SPI [1] which will provide a
>>> possibility to alter how host names and IP addresses are resolved by JDK
>>> platform.
>>> I believe it would be possible to use this mechanism for addressing
>>> issue described in JDK-8257080.
>> Is it hopefully going to be non-blocking?
> 


From dfuchs at openjdk.java.net  Thu Dec 17 14:57:05 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 14:57:05 GMT
Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitely shutdown
 its default executor when stopping.
Message-ID: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>

Hi,

Please find an almost trivial fix for:
8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default executor when stopping.

The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself.

best regards,

-- daniel

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

Commit messages:
 - 8258582: HttpClient: the HttpClient doesn't explicitely shutdown its default executor when stopping.

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

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Thu Dec 17 16:24:10 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 17 Dec 2020 16:24:10 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v5]
In-Reply-To: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
Message-ID: <d3NOZ3YLWa3vpsHMVKs2vpP44OOV7UxZHDu9vVSg5lU=.d9ce4973-5a72-4454-8380-d931fdc7290e@github.com>

> jaxp.library.SimpleHttpServer
> https://bugs.openjdk.java.net/browse/JDK-8212035

Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Implemented the Review comments.
 - Implemented the review comments
 - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
 - Implemnted the review comments.
 - Implemnted the review comments.
 - Implemented the review comments.
 - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with
   jaxp.library.SimpleHttpServer
   https://bugs.openjdk.java.net/browse/JDK-8212035

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

Changes: https://git.openjdk.java.net/jdk/pull/1632/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1632&range=04
  Stats: 650 lines in 17 files changed: 226 ins; 321 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1632.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1632/head:pull/1632

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

From github.com+34924738+mahendrachhipa at openjdk.java.net  Thu Dec 17 16:24:11 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 17 Dec 2020 16:24:11 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v4]
In-Reply-To: <z270dyBaAFWuk0CliW046OPZ1_VhdokjZd6uHnsBrwo=.e8f131fa-c799-4f4b-a6b7-797b441147f5@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <vAuKxzljzOE-k8Zy-7Mo5q7d6x28f-kBjoGoBLTVqa4=.df5e12ea-1d94-4bdd-b401-636a29b577b4@github.com>
 <z270dyBaAFWuk0CliW046OPZ1_VhdokjZd6uHnsBrwo=.e8f131fa-c799-4f4b-a6b7-797b441147f5@github.com>
Message-ID: <ENU6B5a8H-0c_j3Lxi3JTBNLe_AnWmSIwHjwCzRISHI=.a4888330-1407-4c05-84ec-aa6fbc3df145@github.com>

On Mon, 14 Dec 2020 19:44:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
>>  - Implemnted the review comments.
>
> test/lib/jdk/test/lib/net/SimpleHttpServer.java line 105:
> 
>> 103:                     Path fPath;
>> 104:                     try {
>> 105:                         fPath = Paths.get(docRoot, path);
> 
> Hi Mahendra,
> 
> I am not comfortable with this. You cannot just concatenate a file system path with a URI path in the general case (think windows file system). I would suggest to transform docRoot into a root URI using `Path.of(docRoot).toURI().normalize()` - then you can probably concatenate the string representation of this root URI with the *raw path* extracted from the request URI, normalize that again (to remove potential double slashes) and convert that back into a Path using Path.of(URI). 
> Some additional conditions might need to be asserted:
>  - `t.getRequestURI().getRawPath()` should either be empty or start with `"/"` (and even that may be a bit lax)
>  - the resulting URI you obtain (after normalization and before converting back to Path) should either be equal to the root URI or start with the root URI.
> `(rootURI.toString().equals(uri.toString()) || uri.toString().startsWith(rootUri.toString() + "/") )`
> 
> best regards,
> 
> -- daniel

Thanks Daniel. I have implemented the review comments.

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

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

From chegar at openjdk.java.net  Thu Dec 17 16:34:57 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 17 Dec 2020 16:34:57 GMT
Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitly
 shutdown its default executor when stopping.
In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
Message-ID: <-42zDyZeRKIT4P4Ut3JaTRkZnPngH7b91YS8EVl8kKU=.0e579ae7-9e9c-4f39-8731-db6c5d417847@github.com>

On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping.
> 
> The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself.
> 
> best regards,
> 
> -- daniel

Marked as reviewed by chegar (Reviewer).

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

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

From dfuchs at openjdk.java.net  Thu Dec 17 17:15:03 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 17:15:03 GMT
Subject: RFR: JDK-8212035 : merge jdk.test.lib.util.SimpleHttpServer with
 jaxp.library.SimpleHttpServer [v5]
In-Reply-To: <d3NOZ3YLWa3vpsHMVKs2vpP44OOV7UxZHDu9vVSg5lU=.d9ce4973-5a72-4454-8380-d931fdc7290e@github.com>
References: <DdIKNdGhdAkDMbQxCDlH1uAczdD0O9aceWq9zOX-G3c=.fca3bbe5-1f91-44b1-83cd-9bc7c1e7d340@github.com>
 <d3NOZ3YLWa3vpsHMVKs2vpP44OOV7UxZHDu9vVSg5lU=.d9ce4973-5a72-4454-8380-d931fdc7290e@github.com>
Message-ID: <qquVebkCxO-oUib4haG_ii5iJNgsQI7z5ZRFJXdJvm0=.5154532b-c3a7-4c14-9282-434926cff0b8@github.com>

On Thu, 17 Dec 2020 16:24:10 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

>> jaxp.library.SimpleHttpServer
>> https://bugs.openjdk.java.net/browse/JDK-8212035
>
> Mahendra Chhipa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Implemented the Review comments.
>  - Implemented the review comments
>  - Merge branch 'JDK-8212035' of https://github.com/mahendrachhipa/jdk into JDK-8212035
>  - Implemnted the review comments.
>  - Implemnted the review comments.
>  - Implemented the review comments.
>  - JDK-8212035 merge jdk.test.lib.util.SimpleHttpServer with
>    jaxp.library.SimpleHttpServer
>    https://bugs.openjdk.java.net/browse/JDK-8212035

test/lib/jdk/test/lib/net/SimpleHttpServer.java line 104:

> 102:                     try {
> 103:                         uri = URI.create(rootUri.getRawPath() + path).normalize();
> 104:                         fPath = Path.of(uri.getRawPath());

This is wrong. It should be `fpath = Path.of(uri);`. See https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/nio/file/Path.html#of(java.net.URI)

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

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

From paul.sandoz at oracle.com  Thu Dec 17 17:31:49 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 17 Dec 2020 09:31:49 -0800
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
Message-ID: <BE8BF6F9-DF88-485A-8F02-6BEA93C0D050@oracle.com>



> On Dec 16, 2020, at 1:47 AM, Chris Hegarty <chegar at openjdk.java.net> wrote:
> 
> On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:
> 
>>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>> 
>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>  use instanceof pattern matching in UnixPath too
> 
> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.
> 
> src/java.base/share/classes/java/net/InetSocketAddress.java line 414:
> 
>> 412:         if (!(obj instanceof InetSocketAddress))
>> 413:             return false;
>> 414:         return holder.equals(((InetSocketAddress) obj).holder);
> 
> If we restructure this a little we can get:
> 
>    public final boolean equals(Object obj) {
>        if (obj instanceof InetSocketAddress that)
>            return holder.equals(that.holder);
>        return false;
>    }
> 

It?s also possible to use a ternary expression as in:

   return (obj instanceof InetSocketAddress that) ? holder.equals(that.holder) : false;

Not suggesting you have to do that here. More for information purposes for those that might not know.

Paul.

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 17:43:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 17:43:10 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v6]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <PyqNIExdkDwF_ElHCJYwRAvlKyt6TCR5xTfL6oii51Y=.c324d43b-882e-4cb0-8595-6ec948f40d43@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  rename 'other' -> 'oth', 'other1' -> 'other'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/314217ec..fe303a2c

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 17:47:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 17:47:12 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v7]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <bCsOnCfmSL_uteM5YbAiDKGxiQKIp9-AGryuANQbo8E=.b1fe9041-ddee-4b32-8e00-0ada4c7b5995@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  rename 'oth' -> 'obj'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/fe303a2c..5949f9a8

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

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

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

From michaelm at openjdk.java.net  Thu Dec 17 18:01:59 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 17 Dec 2020 18:01:59 GMT
Subject: RFR: 8258582: HttpClient: the HttpClient doesn't explicitly
 shutdown its default executor when stopping.
In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
Message-ID: <ZLMaODZ6JbHZ2wfmNC5NVk3i1YS3z0AUf4DxvlMcyIE=.ec939f0b-b558-426f-80b8-338f02200611@github.com>

On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping.
> 
> The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself.
> 
> best regards,
> 
> -- daniel

Marked as reviewed by michaelm (Reviewer).

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

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

From dfuchs at openjdk.java.net  Thu Dec 17 22:36:55 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 22:36:55 GMT
Subject: Integrated: 8258582: HttpClient: the HttpClient doesn't explicitly
 shutdown its default executor when stopping.
In-Reply-To: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
References: <3G5sXLsAjfoM_oM-PnM1ab1DIQWWZQad--6HZamJ4OA=.5b801757-ba4d-4e93-9390-4dd2e6cd495c@github.com>
Message-ID: <oyC9rjlTkUppwrx62LqEh4mHIm3hiT0QDsHcCcPPdsY=.9b948b2e-fb64-4573-9cfd-e798f43ebd0b@github.com>

On Thu, 17 Dec 2020 14:51:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find an almost trivial fix for:
> 8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping.
> 
> The HttpClient should shutdown his executor when stopping, when the executor was created by the HttpClient itself.
> 
> best regards,
> 
> -- daniel

This pull request has now been integrated.

Changeset: 3f77a600
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f77a600
Stats:     16 lines in 2 files changed: 16 ins; 0 del; 0 mod

8258582: HttpClient: the HttpClient doesn't explicitly shutdown its default executor when stopping.

Reviewed-by: chegar, michaelm

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

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

From ysuenaga at openjdk.java.net  Fri Dec 18 08:11:00 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 18 Dec 2020 08:11:00 GMT
Subject: RFR: 8257736: InputStream from BodyPublishers.ofInputStream()
 leaks when IOE happens [v4]
In-Reply-To: <29cfk2L5A9R0Zvf0MqOMdSUjpshYQWnz901o-Bz07Rc=.902fad80-1dc5-40e2-903e-ebaef2f77943@github.com>
References: <BUTq1p0JZ5NTeKt_uHy6hVcsh6b5280qypoi2WY0ZIo=.5975d1f2-4bae-4582-b4ff-70655e68b5a6@github.com>
 <o5XXes8lBNcQL0kkVGe96Dx8rlU_uo3jPugHP1QgVo4=.756f71e9-48a0-49c7-a437-06c854043b1c@github.com>
 <29cfk2L5A9R0Zvf0MqOMdSUjpshYQWnz901o-Bz07Rc=.902fad80-1dc5-40e2-903e-ebaef2f77943@github.com>
Message-ID: <ylLgP8v6E2nK8DY-ZXpG1T5I7CsURdQKaWB7fW09doE=.9b88ac70-60d9-4e6d-b30b-251c14263210@github.com>

On Sat, 5 Dec 2020 04:55:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Hi Yasumasa, 
>> 
>> Thanks for filing the issue and providing a fix. 
>> 
>> Before integrating, can you please provide a non regression test that verifies the fix? You can place it in `test/jdk/java/net/httpclient/`; 
>> Please also make sure that there is no regression in existing tests.
>> 
>> best regards
>> -- daniel
>
> @dfuch Thanks for your comment! I updated PR.
> 
> * Close the stream in `StreamIterator::hasNext`
> * Throw `UncheckedIOException` whenever IOE happens
> * Added testcase for this PR
> 
> Could you review again?

@ChrisHegarty @dfuch could you review new change? It updates a testcase.

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

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

From bmarwell at apache.org  Fri Dec 18 09:23:04 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Fri, 18 Dec 2020 10:23:04 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <AM0PR03MB4145C72C06A70DD788F2F150FFC50@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <AM0PR03MB4145C72C06A70DD788F2F150FFC50@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <CAKZnr+y4Uy=sGt1PoX6NoEYvVGRuYb+uGkLSE74iRSOqiPsPcQ@mail.gmail.com>

Sounds good to me, but ? to be honest ? a simpler solution would be enough
for now, at least for me. I actually need something which works on Java 8.

I also want to share an excerpt from an RFC:


RFC 1123

2.3  Applications on Multihomed hosts
? Application protocol implementations **SHOULD** be prepared
to try multiple addresses from the list until success is obtained.  ?

SRC: https://tools.ietf.org/html/rfc1123

Java sadly does not implement this.

Am Mi., 16. Dez. 2020 um 20:33 Uhr schrieb Bernd Eckenfels <
ecki at zusammenkunft.net>:

> Hello,
>
> A ?happy eyeballs? implementation, not only for Multiple IPv4 addresses
> but also for IPV6/IPv4 Mixed would be a good thing, however since this
>
> a) adds additional connection Timeouts or decreases connection deadlines
> b) potentially is stateful
>
> I think it?s not a good idea to enable it for all connections. A new
> method to specify a policy (and allow a new default policy) would probably
> be better.
>
> I don?t think doing that in the resolving alone would work, since there is
> also a question of parallelity and a endpoint specific state.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ------------------------------
> *Von:* net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Aleks
> Efimov <aleksej.efimov at oracle.com>
> *Gesendet:* Wednesday, December 16, 2020 5:53:02 PM
> *An:* Benjamin Marwell <bmarwell at apache.org>
> *Cc:* Alan Bateman <Alan.Bateman at oracle.com>; OpenJDK Network Dev list <
> net-dev at openjdk.java.net>
> *Betreff:* Re: [JDK-8257080] Java does not try all DNS results when
> opening a socket
>
> Hi Benjamin,
>
> As Alan stated I'm working on adding an SPI [1] which will provide a
> possibility to alter how host names and IP addresses are resolved by JDK
> platform.
> I believe it would be possible to use this mechanism for addressing
> issue described in JDK-8257080.
>
> Best Regards,
> Aleksei
>
> [1] WIP jdk-sandbox branch:
> https://github.com/openjdk/jdk-sandbox/tree/JDK-8244202-nspi-stream-branch
>
>
> On 16/12/2020 15:42, Alan Bateman wrote:
> > On 16/12/2020 15:21, Benjamin Marwell wrote:
> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8192780
> >>
> >> Granted, it is an SPI. But it seemed to have been used.
> >>
> >
> > Aleksej Efimov is working on an InetAddress SPI, I'm sure there will
> > be a draft JEP at some point. It has the potential to complement the
> > exploration that we discussing here.
> >
> > -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201218/9cd7e575/attachment-0001.htm>

From Alan.Bateman at oracle.com  Fri Dec 18 10:21:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Dec 2020 10:21:10 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+y4Uy=sGt1PoX6NoEYvVGRuYb+uGkLSE74iRSOqiPsPcQ@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <AM0PR03MB4145C72C06A70DD788F2F150FFC50@AM0PR03MB4145.eurprd03.prod.outlook.com>
 <CAKZnr+y4Uy=sGt1PoX6NoEYvVGRuYb+uGkLSE74iRSOqiPsPcQ@mail.gmail.com>
Message-ID: <63682fca-17b1-4ef7-b0df-7a4e9787a58e@oracle.com>

On 18/12/2020 09:23, Benjamin Marwell wrote:
> Sounds good to me, but ? to be?honest ? a simpler solution would be 
> enough for now, at least for me. I actually need something which works 
> on Java 8.
>
> I also want to share an excerpt from an RFC:
>
>
> RFC 1123
>
> 2.3 ?Applications on Multihomed hosts
> ? Application protocol implementations **SHOULD** be prepared
> to try multiple addresses from the list until success is obtained. ??
>
> SRC: https://tools.ietf.org/html/rfc1123 
> <https://tools.ietf.org/html/rfc1123>
>
> Java sadly does not implement this.
>
True although a library or application using the Socket or SocketChannel 
APIs can cycle through the addresses too. I think there is general 
agreement here that having some support for this in the Java platform 
would be useful but I think it will require exploration and prototypes 
in order to see what new APIs and specification changes will be required 
to support it.

-Alan

From Alan.Bateman at oracle.com  Fri Dec 18 10:35:50 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Dec 2020 10:35:50 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+xaSSNnf-iriPXN5SOkuss+CV1rQb-kPTV2b--MZSbuWw@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <AM0PR03MB4145C72C06A70DD788F2F150FFC50@AM0PR03MB4145.eurprd03.prod.outlook.com>
 <CAKZnr+y4Uy=sGt1PoX6NoEYvVGRuYb+uGkLSE74iRSOqiPsPcQ@mail.gmail.com>
 <63682fca-17b1-4ef7-b0df-7a4e9787a58e@oracle.com>
 <CAKZnr+xaSSNnf-iriPXN5SOkuss+CV1rQb-kPTV2b--MZSbuWw@mail.gmail.com>
Message-ID: <0c22b54b-9708-fd44-23ca-2320c825038a@oracle.com>

On 18/12/2020 10:28, Benjamin Marwell wrote:
> Hi Alan,
>
> I am using the LDAP connector from the JDK (javax.naming.directory.*) 
> [1].
> As far as I know there is no way to configure this.
>
> [1]: 
> https://docs.oracle.com/javase/jndi/tutorial/ldap/security/ldap.html 
> <https://docs.oracle.com/javase/jndi/tutorial/ldap/security/ldap.html>
>
Are you looking for javax.naming.spi.LdapDnsProvider?

-Alan

From chegar at openjdk.java.net  Fri Dec 18 16:59:03 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 18 Dec 2020 16:59:03 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
Message-ID: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>

Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 

... 
Generating REFERENCE_API javadoc for 21 modules 

            if (delegate instanceof ExecutorService service) { 
                                                    ^ 
  (use --enable-preview to enable pattern matching in instanceof) 
1 error 
make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
make[2]: *** [docs-reference-api-javadoc] Error 2 
make[2]: *** Waiting for unfinished jobs....

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

Commit messages:
 - avoid instanceof pattern match

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

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

From rriggs at openjdk.java.net  Fri Dec 18 17:05:55 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 18 Dec 2020 17:05:55 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <kPcIV7km0355OhLuckA178JzUFg-vVqJn1u3TtmfCZY=.ff1581ba-08fb-414f-b433-1a126dbf9550@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Marked as reviewed by rriggs (Reviewer).

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

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

From dcubed at openjdk.java.net  Fri Dec 18 17:05:56 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Dec 2020 17:05:56 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <byU59iyJAP_bZBSDbNqYB6CKTwntsfverRNux4ayQJI=.6c080aa6-4993-4f43-95ee-34f680b771eb@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From bpb at openjdk.java.net  Fri Dec 18 17:05:57 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 18 Dec 2020 17:05:57 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <_pVqU3XwoKW06W0NxNX5fT5mIlCKyjPhvIW7MyKZReI=.d2563869-41d7-4978-86d5-1a2fb68033d1@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Marked as reviewed by bpb (Reviewer).

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

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

From jjg at openjdk.java.net  Fri Dec 18 17:20:52 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 18 Dec 2020 17:20:52 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <MsFevDeEqUuzByLJXlej4MYuP-EgrFS2zu1TDSOhPcM=.b31cdbfb-767c-4344-850a-6c8a5619098f@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Marked as reviewed by jjg (Reviewer).

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

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

From dfuchs at openjdk.java.net  Fri Dec 18 17:47:56 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 18 Dec 2020 17:47:56 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <YyFvhokoEoxJz4KIHQw-gxg0LgpYbaDLmoJAkaowZPs=.99a72450-c643-4123-b698-4209daf9f493@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Marked as reviewed by dfuchs (Reviewer).

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

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

From aefimov at openjdk.java.net  Fri Dec 18 19:06:57 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 18 Dec 2020 19:06:57 GMT
Subject: RFR: 8258696: Temporarily revert use of pattern match instanceof
 until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <Aqg23gQ1rZlgTk6ssDos59ckIKEf5LsLFRkHv4PJOwg=.3d1abbfd-8bf5-4e68-bf25-a3b45ef32a47@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

Marked as reviewed by aefimov (Committer).

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

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

From chegar at openjdk.java.net  Fri Dec 18 19:52:57 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 18 Dec 2020 19:52:57 GMT
Subject: Integrated: 8258696: Temporarily revert use of pattern match
 instanceof until docs-reference is fixed
In-Reply-To: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
References: <0idKG1hpSewLbLkyftFPtYhwWQpdSp-kbfra7EcwpA0=.5e6fb842-36c8-447a-bfe7-3273bc3c2d59@github.com>
Message-ID: <85mGj5m9OEJLTag__9qepsZMcrmcSOA4lT8yQHYGzcc=.111c1c1c-d654-4601-b7b0-4a02b8b31b64@github.com>

On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Temporarily revert use of pattern match instanceof construct until docs-reference is fixed, see JDK-8258657. 
> 
> ... 
> Generating REFERENCE_API javadoc for 21 modules 
> 
>             if (delegate instanceof ExecutorService service) { 
>                                                     ^ 
>   (use --enable-preview to enable pattern matching in instanceof) 
> 1 error 
> make[3]: *** [/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker] Error 1 
> Docs.gmk:472: recipe for target '/Users/chhegar/git/open/build/macosx-x64/support/docs/_javadoc_REFERENCE_API_exec.marker' failed 
> make/Main.gmk:485: recipe for target 'docs-reference-api-javadoc' failed 
> make[2]: *** [docs-reference-api-javadoc] Error 2 
> make[2]: *** Waiting for unfinished jobs....

This pull request has now been integrated.

Changeset: be41468c
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be41468c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8258696: Temporarily revert use of pattern match instanceof until docs-reference is fixed

Reviewed-by: rriggs, dcubed, bpb, jjg, dfuchs, aefimov

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

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

From chegar at openjdk.java.net  Sat Dec 19 10:31:55 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Sat, 19 Dec 2020 10:31:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
Message-ID: <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>

On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   take advantage of "flow scoping" to eliminate casts
>
> Thank you for checking `HttpURLConnection` and `Socket`.
> The latest version looks good to me.

This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.

[1]: https://bugs.openjdk.java.net/browse/JDK-8258657

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:10:02 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:10:02 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
Message-ID: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>

8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Commit messages:
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

Changes: https://git.openjdk.java.net/jdk/pull/1853/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8080272
  Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:46:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:46:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v2]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <hY6bq5j7bf8POwY5aKS87ncspu7iRgBq-8N8PZsW6Os=.e4ecc2ff-a299-4221-92be-6f98756c933e@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in JrtPath. They compiled with java 8 language level

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455

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

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

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

From alanb at openjdk.java.net  Sun Dec 20 19:45:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:45:54 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.

We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.

One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:09:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:09:12 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v3]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oNRktI1p1Z3VLqIBLK6yPqk-mDMFmh8EzMrRuHmtp8w=.cdd1f3fe-c7ba-4e83-8220-da2e2582004f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in ASM
  use Files.copy in sjavac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471

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

  Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:15:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:15:09 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v4]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <F5_oGJSwGgKTiBxBuzIa3DietHA6DAukNrG1tKXMwzQ=.89920e48-6c93-4ea9-b383-63dc9ba58fa9@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in MLet too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:22:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:22:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v5]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <vAvbxQL52sRM-zF5IuAEfbLXaj-8xfux8XNvlDyQTno=.f1389529-1b8c-4d5a-a335-bea8d182586f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in Win32PrintJob too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:25:52 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:25:52 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
Message-ID: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>

On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

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

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

From prr at openjdk.java.net  Sun Dec 20 20:36:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 20:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
Message-ID: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>

On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.
>> 
>> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.
>> 
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
> 
> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

So these changes are all over the place which means no one person knows how to test all of it.
Have you run the sound, swing tests, and the  printing tests on unix and windows ?
For printing for sure you'll need to do some manual testing.

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

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

From serb at openjdk.java.net  Sun Dec 20 22:50:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 20 Dec 2020 22:50:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
Message-ID: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race <prr at openjdk.org> wrote:

>>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>> 
>> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.
>
> So these changes are all over the place which means no one person knows how to test all of it.
> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
> For printing for sure you'll need to do some manual testing.

I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:52:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:52:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v6]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <egekHLmTMOf1zvpBGHF6ho4g2MWS1mY0c_g4elVAGUs=.ba8b3b7f-7b6a-4f4a-95f1-bdc73c7b74db@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov 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:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711

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

  Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:58:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:58:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
Message-ID: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>

On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So these changes are all over the place which means no one person knows how to test all of it.
>> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
>> For printing for sure you'll need to do some manual testing.
>
> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

I've extracted changes in java.desktop into separate PR #1856
Reverted this changes from current PR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 08:19:08 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 08:19:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov 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:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3

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

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

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

From alanb at openjdk.java.net  Mon Dec 21 08:36:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Dec 2020 08:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
 <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com>

On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.
>
> I've extracted changes in java.desktop into separate PR #1856
> Reverted this changes from current PR.

Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:16:11 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:16:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in Apache Santuario

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817

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

  Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 09:47:59 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 09:47:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main`

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:

> 2457:                 byte[] bytes = in.readAllBytes();
> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
> 2459:                         new ByteArrayInputStream(bytes));

Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:53:57 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:53:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
Message-ID: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>

On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
> 
>> 2457:                 byte[] bytes = in.readAllBytes();
>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>> 2459:                         new ByteArrayInputStream(bytes));
> 
> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

Looks like it was done intentionally by original author of the code.
Check comment above:

                // Read the full stream before feeding to X509Factory,
                // otherwise, keytool -gencrl | keytool -printcrl
                // might not work properly, since -gencrl is slow
                // and there's no data in the pipe at the beginning.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 10:06:01 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 10:06:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
 <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
Message-ID: <m7_aUO_Qf7tKkUNuihCnh8Lh83xzYp3AOANwFucPBsE=.201f4482-bd10-4936-b58c-9148b3dd18d3@github.com>

On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>> 
>>> 2457:                 byte[] bytes = in.readAllBytes();
>>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>>> 2459:                         new ByteArrayInputStream(bytes));
>> 
>> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?
>
> Looks like it was done intentionally by original author of the code.
> Check comment above:
> 
>                 // Read the full stream before feeding to X509Factory,
>                 // otherwise, keytool -gencrl | keytool -printcrl
>                 // might not work properly, since -gencrl is slow
>                 // and there's no data in the pipe at the beginning.

Let's keep it then

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

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

From alanb at openjdk.java.net  Tue Dec 22 14:10:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 22 Dec 2020 14:10:54 GMT
Subject: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an
 IPPROTO_ICMP socket type before attempting RAW_SOCK
In-Reply-To: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
References: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
Message-ID: <zIooGnZutgHzNpXmNnIKfOQORMBolJW5qhye0ceFHO8=.7745cf66-0e75-40b0-b325-603189c5a1fe@github.com>

On Sun, 29 Nov 2020 07:54:23 GMT, Jamie Le Tual <github.com+55101029+jamieletual at openjdk.org> wrote:

> Users have been able to send ICMP packets without the need for root privileges or the CAP_NET_RAW capability since at least kernel 3.11.
> 
> For some time now, if the kernel parameter net.ipv4.ping_group_range included the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then the packet would>
> It's important to note that the both the checksum and ident field are overwritten by the kernel when this is done.
> 
> Newer distributions are now setting the default value of net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and Ubuntu 20.04 for example) so it can b>
> 
> Also of note is the that this is also implemented in MacOS.
> 
> This patch proposes attempting to use IPPROTO_ICMP first, and then fall back to attempting a raw socket and ultimately failing over to tcp echo.
> This patch also alters the logic for identifying icmp reply packets, since the kernel overwrites id ident field when using the IPPROTO_ICMP protocol.
> The method is similar to that used by the ping(8) utility in the iputils package, where we compare data in the icmp_data member of the icmp struct
> to identify the packet as our response. The ping utility compares the timeval, whereas this patch proposes to compare both the timeval and the user's pid.
> 
> Please not that my OCA has been sent in and is pending.

Adding support for SOCK_DGRAM/IPPROTO_ICMP(6) is good and I think is mostly okay. The comments and the formatting is messy in several places and should be cleaned up before the patch is sponsored.

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

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

From chris.hegarty at oracle.com  Tue Dec 22 17:27:18 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 22 Dec 2020 17:27:18 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
Message-ID: <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>

I believe that 8170568 [1] better describes the issue being discussed
here. So, unless there are any objections, I will close 8257080 as a
duplicate of 8170568.

---

There was some renewed interest in this area back in mid 2019, when we
touched on it (and several other issues) relating to IPv6 [2] (yes, I
know that this is not an IPv6-only specific issue).

This is not a new issue, but unfortunately not much progress has been
made in this area (beyond some embedded or mobile platforms doing their
own thing). I remember discussing this with some folks while at the 80th
IETF meeting in Prague, in 2011. Specifically at the time, I prototyped
an implementation of Happy Eyeballs [3] at the java.net.Socket level. If
memory serves me correct, there were some not-so-straightforward
specification issues that would need to worked out, especially relating
to exceptions and failures (I don't have the details to hand).

Things have moved on a lot since then, for example I see no reason why 
the Java HTTP Client, that uses non-blocking NIO socket channels, could
not do it's own multi-connect thing. This is clearly unrelated to
whatever, if anything, is done for java.net.Socket.connect(String,int).

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8170568
[2] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012371.html
[3] https://tools.ietf.org/html/rfc6555


> On 17 Dec 2020, at 14:39, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Looping in a prior relevant issue in JIRA: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8170568 - 
> Improve address selection for network clients
> 
> -Chris.
> 
>> On 17 Dec 2020, at 13:45, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> 
>> Hi Simone,
>> 
>> We are investigating introducing a Service Provider interface
>> which would allow an application to replace the default
>> built-in implementation that blocks inside the kernel.
>> 
>> There is no plan to introduce any public asynchronous API to perform
>> address resolution at this point. With the advent of Loom and
>> virtual threads I'm not sure there would be much motivation for
>> that anyway.
>> 
>> best regards,
>> 
>> -- daniel
>> 
>> On 16/12/2020 19:59, Simone Bordet wrote:
>>> Hi,
>>> On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>>>> 
>>>> Hi Benjamin,
>>>> 
>>>> As Alan stated I'm working on adding an SPI [1] which will provide a
>>>> possibility to alter how host names and IP addresses are resolved by JDK
>>>> platform.
>>>> I believe it would be possible to use this mechanism for addressing
>>>> issue described in JDK-8257080.
>>> Is it hopefully going to be non-blocking?
>> 
> 


From bmarwell at apache.org  Tue Dec 22 17:32:57 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Tue, 22 Dec 2020 18:32:57 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
 <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
Message-ID: <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>

> unless there are any objections, I will close 8257080

No objection from me.

> Things have moved on a lot since then, for example I see no reason why
> the Java HTTP Client, that uses non-blocking NIO socket channels, could
> not do it's own multi-connect thing.

Well, I am stuck with Java 8 and if any LDAP server goes down, all
java applications will, too.
Python, .NET, etc. are not affected.
In Java 8 there is no way around it. The next LTS is Java 11 which does ont
include
the Ldap DNS class you mentioned.

As the java.net classes are all not modifiable using a agent or such,
this is still a quite unpleasant situation. Which is why I raised
this issue in the first place.

- Ben

Am Di., 22. Dez. 2020 um 18:28 Uhr schrieb Chris Hegarty <
chris.hegarty at oracle.com>:

> I believe that 8170568 [1] better describes the issue being discussed
> here. So, unless there are any objections, I will close 8257080 as a
> duplicate of 8170568.
>
> ---
>
> There was some renewed interest in this area back in mid 2019, when we
> touched on it (and several other issues) relating to IPv6 [2] (yes, I
> know that this is not an IPv6-only specific issue).
>
> This is not a new issue, but unfortunately not much progress has been
> made in this area (beyond some embedded or mobile platforms doing their
> own thing). I remember discussing this with some folks while at the 80th
> IETF meeting in Prague, in 2011. Specifically at the time, I prototyped
> an implementation of Happy Eyeballs [3] at the java.net.Socket level. If
> memory serves me correct, there were some not-so-straightforward
> specification issues that would need to worked out, especially relating
> to exceptions and failures (I don't have the details to hand).
>
> Things have moved on a lot since then, for example I see no reason why
> the Java HTTP Client, that uses non-blocking NIO socket channels, could
> not do it's own multi-connect thing. This is clearly unrelated to
> whatever, if anything, is done for java.net.Socket.connect(String,int).
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8170568
> [2] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012371.html
> [3] https://tools.ietf.org/html/rfc6555
>
>
> > On 17 Dec 2020, at 14:39, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
> >
> > Looping in a prior relevant issue in JIRA:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8170568 -
> > Improve address selection for network clients
> >
> > -Chris.
> >
> >> On 17 Dec 2020, at 13:45, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> >>
> >> Hi Simone,
> >>
> >> We are investigating introducing a Service Provider interface
> >> which would allow an application to replace the default
> >> built-in implementation that blocks inside the kernel.
> >>
> >> There is no plan to introduce any public asynchronous API to perform
> >> address resolution at this point. With the advent of Loom and
> >> virtual threads I'm not sure there would be much motivation for
> >> that anyway.
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 16/12/2020 19:59, Simone Bordet wrote:
> >>> Hi,
> >>> On Wed, Dec 16, 2020 at 5:55 PM Aleks Efimov <
> aleksej.efimov at oracle.com> wrote:
> >>>>
> >>>> Hi Benjamin,
> >>>>
> >>>> As Alan stated I'm working on adding an SPI [1] which will provide a
> >>>> possibility to alter how host names and IP addresses are resolved by
> JDK
> >>>> platform.
> >>>> I believe it would be possible to use this mechanism for addressing
> >>>> issue described in JDK-8257080.
> >>> Is it hopefully going to be non-blocking?
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201222/b60c2e24/attachment.htm>

From github.com+55101029+jamieletual at openjdk.java.net  Wed Dec 23 14:06:12 2020
From: github.com+55101029+jamieletual at openjdk.java.net (Jamie Le Tual)
Date: Wed, 23 Dec 2020 14:06:12 GMT
Subject: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an
 IPPROTO_ICMP socket type before attempting RAW_SOCK [v2]
In-Reply-To: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
References: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
Message-ID: <_aIlrnl8HP1iZoer0B-icI24d3C5SFe4-DJqZuiUgCE=.ad267744-e605-4793-8355-28eb315aa251@github.com>

> Users have been able to send ICMP packets without the need for root privileges or the CAP_NET_RAW capability since at least kernel 3.11.
> 
> For some time now, if the kernel parameter net.ipv4.ping_group_range included the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then the packet would>
> It's important to note that the both the checksum and ident field are overwritten by the kernel when this is done.
> 
> Newer distributions are now setting the default value of net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and Ubuntu 20.04 for example) so it can b>
> 
> Also of note is the that this is also implemented in MacOS.
> 
> This patch proposes attempting to use IPPROTO_ICMP first, and then fall back to attempting a raw socket and ultimately failing over to tcp echo.
> This patch also alters the logic for identifying icmp reply packets, since the kernel overwrites id ident field when using the IPPROTO_ICMP protocol.
> The method is similar to that used by the ping(8) utility in the iputils package, where we compare data in the icmp_data member of the icmp struct
> to identify the packet as our response. The ping utility compares the timeval, whereas this patch proposes to compare both the timeval and the user's pid.

Jamie Le Tual has updated the pull request incrementally with one additional commit since the last revision:

  Fixed formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1502/files
  - new: https://git.openjdk.java.net/jdk/pull/1502/files/923e3489..1c8a555f

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

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

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

From github.com+55101029+jamieletual at openjdk.java.net  Wed Dec 23 14:09:57 2020
From: github.com+55101029+jamieletual at openjdk.java.net (Jamie Le Tual)
Date: Wed, 23 Dec 2020 14:09:57 GMT
Subject: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an
 IPPROTO_ICMP socket type before attempting RAW_SOCK [v2]
In-Reply-To: <zIooGnZutgHzNpXmNnIKfOQORMBolJW5qhye0ceFHO8=.7745cf66-0e75-40b0-b325-603189c5a1fe@github.com>
References: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
 <zIooGnZutgHzNpXmNnIKfOQORMBolJW5qhye0ceFHO8=.7745cf66-0e75-40b0-b325-603189c5a1fe@github.com>
Message-ID: <cIiLOyTv1B1uJ_g7FwmthiRvi0KIk15SP0xOeQL1jOc=.0cab25a7-bb34-4176-87b6-f95c29c3f70f@github.com>

On Tue, 22 Dec 2020 14:08:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Adding support for SOCK_DGRAM/IPPROTO_ICMP(6) is good and I think is mostly okay. The comments and the formatting is messy in several places and should be cleaned up before the patch is sponsored.

Alan, thanks for taking a look at the patch. I tried to see which comments and  formatting where messy and I have to say I don't see what your are talking about; as far as I can tell the formatting in the patch doesn't diverge from the code style of the files they are in.  Can you give a specific example of what you consider messy so I can know what you're talking about?

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

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

From alanb at openjdk.java.net  Wed Dec 23 16:12:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Dec 2020 16:12:55 GMT
Subject: RFR: 8255264: Support for identifying the full range of IPv4
 localhost addresses on Windows
In-Reply-To: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>
References: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>
Message-ID: <tAP5gnF6DOraAVD-orCObO2GZnuYl_bYYy149KEQ_4g=.5b20156c-cfe0-4ae6-a084-e289beb03f2f@github.com>

On Mon, 30 Nov 2020 18:09:57 GMT, Mat Carter <github.com+54955201+macarte at openjdk.org> wrote:

> Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler)
> 
> This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows
> 
> IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to
> 127.255.255.255 inclusive.
> 
> The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change
> 
> Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address

Looks good.

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

Marked as reviewed by alanb (Reviewer).

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

From github.com+54955201+macarte at openjdk.java.net  Wed Dec 23 17:23:53 2020
From: github.com+54955201+macarte at openjdk.java.net (Mat Carter)
Date: Wed, 23 Dec 2020 17:23:53 GMT
Subject: RFR: 8255264: Support for identifying the full range of IPv4
 localhost addresses on Windows
In-Reply-To: <tAP5gnF6DOraAVD-orCObO2GZnuYl_bYYy149KEQ_4g=.5b20156c-cfe0-4ae6-a084-e289beb03f2f@github.com>
References: <6UtL7OPeZXi24GxIiOj0YlpnYrZFfgMANMnq3nGzjbg=.f5f3a659-264a-47e7-b5a4-42f3e995a3be@github.com>
 <tAP5gnF6DOraAVD-orCObO2GZnuYl_bYYy149KEQ_4g=.5b20156c-cfe0-4ae6-a084-e289beb03f2f@github.com>
Message-ID: <UB-26YAxbSCkG32xo90ToMlKO6vJ21JSErdEgbM4_i8=.4a4512ad-6773-418d-80b4-247de33fb616@github.com>

On Wed, 23 Dec 2020 16:10:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler)
>> 
>> This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows
>> 
>> IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to
>> 127.255.255.255 inclusive.
>> 
>> The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change
>> 
>> Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address
>
> Looks good.

Thanks for the review Alan

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

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

From fw at deneb.enyo.de  Sat Dec 26 14:53:27 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 26 Dec 2020 15:53:27 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>
 (Benjamin Marwell's message of "Tue, 22 Dec 2020 18:32:57 +0100")
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
 <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
 <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>
Message-ID: <87wnx41uvs.fsf@mid.deneb.enyo.de>

* Benjamin Marwell:

> Well, I am stuck with Java 8 and if any LDAP server goes down, all
> java applications will, too.  Python, .NET, etc. are not affected.

Surely that totally depends on the LDAP client implementation in use?

From bmarwell at apache.org  Sun Dec 27 10:05:22 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Sun, 27 Dec 2020 11:05:22 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <87wnx41uvs.fsf@mid.deneb.enyo.de>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
 <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
 <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>
 <87wnx41uvs.fsf@mid.deneb.enyo.de>
Message-ID: <CAKZnr+zS=UuwmzFj1W_0suW2eW3cG35vue-K7JK5hO+YF3Wt4g@mail.gmail.com>

Is there more than just one? The built-in will provide support
for javax.naming.spi.LdapDnsProvider from java 12 onwards.
But I was not aware of any custom implementations I could use as a drop-in
replacement with Apache Shiro.

The Java 8 implementation will just use the socket?s/InetAdress?s DNS
resolution algo, which is just getAddresses()[0].

Am Sa., 26. Dez. 2020 um 15:53 Uhr schrieb Florian Weimer <fw at deneb.enyo.de
>:

> * Benjamin Marwell:
>
> > Well, I am stuck with Java 8 and if any LDAP server goes down, all
> > java applications will, too.  Python, .NET, etc. are not affected.
>
> Surely that totally depends on the LDAP client implementation in use?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201227/a7278b33/attachment.htm>

From Alan.Bateman at oracle.com  Tue Dec 29 06:39:15 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Dec 2020 06:39:15 +0000
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <CAKZnr+zS=UuwmzFj1W_0suW2eW3cG35vue-K7JK5hO+YF3Wt4g@mail.gmail.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
 <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
 <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>
 <87wnx41uvs.fsf@mid.deneb.enyo.de>
 <CAKZnr+zS=UuwmzFj1W_0suW2eW3cG35vue-K7JK5hO+YF3Wt4g@mail.gmail.com>
Message-ID: <0d568dbb-407b-34fb-c78f-9cd43a4fd33c@oracle.com>

On 27/12/2020 10:05, Benjamin Marwell wrote:
> Is there more than just one? The built-in will provide support 
> for?javax.naming.spi.LdapDnsProvider from java 12 onwards.
> But I was not aware of any custom implementations I could use as a 
> drop-in replacement with Apache Shiro.
>
Do you know if the Apache Shiro project are using the SPI when deployed 
on newer Java releases?

-Alan

From bmarwell at apache.org  Tue Dec 29 10:47:52 2020
From: bmarwell at apache.org (Benjamin Marwell)
Date: Tue, 29 Dec 2020 11:47:52 +0100
Subject: [JDK-8257080] Java does not try all DNS results when opening a
 socket
In-Reply-To: <0d568dbb-407b-34fb-c78f-9cd43a4fd33c@oracle.com>
References: <CAKZnr+y6CPZ5M1_w_ZBTZQY_kK+gu+0yYtJYuxu0Ww8f4RiuVA@mail.gmail.com>
 <75e8db1d-c179-55a4-537d-be5e942352cc@oracle.com>
 <CAKZnr+yFjGq+CH_2O8O2SYXjtv+McXoMDoif_xGiHKJNF-Nubg@mail.gmail.com>
 <2e8e61de-2b7d-1739-ab27-1ed08957788c@oracle.com>
 <23c5d0f0-64ff-05e3-9951-66312383bad2@apache.org>
 <ea372d5a-f7a1-65f7-9370-c1c173c728a0@oracle.com>
 <560aa5bf-71ce-57a2-bf9f-d0f8d5b1c3e8@apache.org>
 <0f7885d7-7d3b-a840-8725-59137fbf6402@oracle.com>
 <bb6f4e18-4f23-0f59-d044-e68cfce910ad@oracle.com>
 <CAFWmRJ0bc7wnziF4e1--H101oa9rtdTPccX1xZo++TdqR1Lgig@mail.gmail.com>
 <66e5cb9e-384c-811a-48fa-92e9d0dffc32@oracle.com>
 <5A888540-E924-48EC-B2D8-5B58B524804C@oracle.com>
 <3A9DBE6A-C6D4-4D84-8812-0065FC24B055@oracle.com>
 <CAKZnr+wgA4ECEQZONuKY+KiEWyx6fLzAh4arjK4sFCnU6D1V7A@mail.gmail.com>
 <87wnx41uvs.fsf@mid.deneb.enyo.de>
 <CAKZnr+zS=UuwmzFj1W_0suW2eW3cG35vue-K7JK5hO+YF3Wt4g@mail.gmail.com>
 <0d568dbb-407b-34fb-c78f-9cd43a4fd33c@oracle.com>
Message-ID: <CAKZnr+xns5CRk4jRLyj401TDwmGyinnHgD9NcozE6-ePAYW1Sw@mail.gmail.com>

Hi Alan,

actually, I do not know, but I suspect it should work OOTB as we are using
the javax.naming.ldap.InitialLdapContext [1].

I discussed the new SPI with the shiro team, there is no experience with it
yet.
An integration test with an ApacheDS server as might reveal if it works as
expected.
However, no such tests exists at this time.

I will get back to you as soon as we have a working IT in place.
Contributions are always welcome! ;-)

- Ben

[1]:
https://github.com/apache/shiro/blob/0e5a4428bcaa0a4c03680f5faad5a4c897379497/core/src/main/java/org/apache/shiro/realm/ldap/JndiLdapContextFactory.java#L507-L509


Am Di., 29. Dez. 2020 um 07:39 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> On 27/12/2020 10:05, Benjamin Marwell wrote:
> > Is there more than just one? The built-in will provide support
> > for javax.naming.spi.LdapDnsProvider from java 12 onwards.
> > But I was not aware of any custom implementations I could use as a
> > drop-in replacement with Apache Shiro.
> >
> Do you know if the Apache Shiro project are using the SPI when deployed
> on newer Java releases?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201229/797da029/attachment.htm>