From sha.jiang at oracle.com  Mon Mar  2 08:08:00 2020
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 2 Mar 2020 16:08:00 +0800
Subject: RFR[15] JDK-8238740: java/net/httpclient/whitebox/FlowTestDriver.java
 would not specify a TLS protocol
Message-ID: <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>

Hi,
java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
would not use a specific TLS protocol, instead just use the default TLS 
protocol, exactly TLSv1.3 now.

diff -r 4a5a7dc9d05c 
test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java
--- 
a/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
Sun Mar 01 17:36:03 2020 -0800
+++ 
b/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
Mon Mar 02 16:01:15 2020 +0800
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights 
reserved.
 ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ? *
 ? * This code is free software; you can redistribute it and/or modify it
@@ -80,7 +80,6 @@
 ???????? SSLEngine engineClient = ctx.createSSLEngine();
 ???????? SSLParameters params = ctx.getSupportedSSLParameters();
 ???????? params.setApplicationProtocols(new String[]{"proto1", 
"proto2"}); // server will choose proto2
-??????? params.setProtocols(new String[]{"TLSv1.2"}); // TODO: This is 
essential. Needs to be protocol impl
 ???????? engineClient.setSSLParameters(params);
 ???????? engineClient.setUseClientMode(true);
 ???????? completion = new CompletableFuture<>();

Best regards,
John Jiang


From daniel.fuchs at oracle.com  Mon Mar  2 10:49:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 2 Mar 2020 10:49:56 +0000
Subject: (solaris) 8059309: network tests fail with
 "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
In-Reply-To: <AM6PR03MB4389607B87F144CAC78CA32EFFE80@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <4ea0a9a3-7ff7-4127-2196-d1626e3bbc19@oracle.com>
 <AM6PR03MB4389607B87F144CAC78CA32EFFE80@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <995e5380-9dfa-e003-ba8f-6f0d1c5bbc78@oracle.com>

Hi Bernd,

On 28/02/2020 22:06, Bernd Eckenfels wrote:
> What is the MAC address of the loopback interface on Solaris anyway? 

I'd expect there's none. "null" is what is consistently returned
after the fix (before you either get "null" or "SocketException")

> Maybe it's enough to assume there is none if the execution fails?

I believe that's what the fix is doing (by returning 0).

There's no special case for the loopback - and the issue here is
that a SocketException is thrown instead of returning null.
Regardless of whether the loopback interface is being queried or
not - I believe that return 0 when the query is not supported
is the right thing to do here.

best regards,

-- daniel

> 
> 
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Daniel 
> Fuchs <daniel.fuchs at oracle.com>
> *Gesendet:* Friday, February 28, 2020 4:41:51 PM
> *An:* OpenJDK Network Dev list <net-dev at openjdk.java.net>
> *Betreff:* (solaris) 8059309: network tests fail with 
> "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
> Hi,
> 
> Please find below a fix for:
> 
> 8059309: network tests fail with "java.net.SocketException:
>  ????????? Couldn't obtain phys addr" when run as "root"
> https://bugs.openjdk.java.net/browse/JDK-8059309
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8059309/webrev.00/
> 
> Recent reports have shown that the failure occurs when the tests
> are run with super user privileges.
> 
> The NetworkInterface code on Solaris attempts to use the DLPI interface,
> but this requires root privilege. If it fails to open the device, it
> falls back to using the ARP tables instead.
> 
> Apparently using the DLPI interface to query the mac address from
> the loopback isn't supported, which is causing the exception.
> 
> The fix is to examine the error status returned by the ACK
> message and if that's DL_UNSUPPORTED, returns 0 to trigger the
> fallback mechanism instead of throwing the socket exception.
> 
> best regards,
> 
> -- daniel


From daniel.fuchs at oracle.com  Mon Mar  2 10:52:35 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 2 Mar 2020 10:52:35 +0000
Subject: (solaris) 8059309: network tests fail with
 "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
In-Reply-To: <dc5cc367-2a37-1dfd-7b43-0f449a8c1aaf@oracle.com>
References: <4ea0a9a3-7ff7-4127-2196-d1626e3bbc19@oracle.com>
 <AM6PR03MB4389607B87F144CAC78CA32EFFE80@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <dc5cc367-2a37-1dfd-7b43-0f449a8c1aaf@oracle.com>
Message-ID: <cdedba88-d067-0006-d525-70ceab5912b1@oracle.com>

Hi Alan,

On 29/02/2020 07:54, Alan Bateman wrote:
> On 28/02/2020 22:06, Bernd Eckenfels wrote:
> I'm also curious if there are any platforms or configurations where the 
> loopback has a hardware address. Mostly wondering if this should be 
> short circuited to consistently return null (I would expect any native 
> methods or fallback to be used).

See my reply to Bernd. Maybe short-circuiting for the loopback would
be an option - but I believe the fix is correct - whether loopback
is being queried or not.

best regards,

-- daniel

> 
> -Alan


From ravi.k.reddy at oracle.com  Mon Mar  2 15:01:21 2020
From: ravi.k.reddy at oracle.com (Ravi Reddy)
Date: Mon, 2 Mar 2020 07:01:21 -0800 (PST)
Subject: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <61b15923-9770-4f48-9af4-cc174c04e665@default>
References: <70203ecd-a48e-4784-aee1-8d59241de4d6@default>
 <00940C28-2EAF-40D5-9C97-CC59C51B87B3@oracle.com>
 <2a109d9c-965c-4924-b081-c7f43694cdf9@default>
 <13e3aac5-87e8-4b13-f487-2d89529fa078@oracle.com>
 <CAKysZ8z5PH50tvwPSPptf9fn7T51TgaRp4RyX7UpbUmBwAD5dg@mail.gmail.com>
 <5154731a-3f0b-89ec-7e54-83355fd9e9b1@oracle.com>
 <61b15923-9770-4f48-9af4-cc174c04e665@default>
Message-ID: <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>

Hi Daniel,

As suggested by you I have added a test case for retry connection with proxy case . Please review the latest webrev and let me know your comments.

With the latest changes , the HttpURLConWithProxy test fails without the fix.

Webrev: http://cr.openjdk.java.net/~pkoppula/8183369/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8183369


Thanks,
Ravi


-----Original Message-----
From: Ravi Reddy 
Sent: Thursday, February 13, 2020 10:10 PM
To: Daniel Fuchs <daniel.fuchs at oracle.com>; Vyom Tiwari <vyommani at gmail.com>
Cc: net-dev <net-dev at openjdk.java.net>
Subject: RE: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Hi Daniel/Vyom,

As mentioned in the review comments ,
  Change in test case HttpURLConWithProxy.java is to make sure we don?t throw an error ?Can?t use direct connection? even when the connection is made through proxy. i.e to make sure the existing test case won't fail because of the fix.

Daniel , As you suggested I will try and come up with a test case to make sure there is a retry happening after connection fails once through proxy.



Thanks,
Ravi

-----Original Message-----
From: Daniel Fuchs
Sent: Thursday, February 13, 2020 8:59 PM
To: Vyom Tiwari <vyommani at gmail.com>
Cc: Ravi Reddy <ravi.k.reddy at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>; net-dev <net-dev at openjdk.java.net>
Subject: Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Thanks Vyom.

I was suspecting as much.

Ravi, could you come up with a test that fails without the fix and pass with it?

best regards,

-- daniel


On 13/02/2020 14:26, Vyom Tiwari wrote:
> Hi Ravi/Daniel,
> 
> At my local env(REL 7) test is passing without fix as well. Although 
> my local repo contain some additional code changes but it is not 
> related with the current fix.
> ################
> Test1 Passed with: Connect timed out
> Test2 Passed with: Connect timed out
> ##################
> 
> Please change copyright year(2020) as well.
> 
> Thanks,
> Vyom


From daniel.fuchs at oracle.com  Tue Mar  3 12:12:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 3 Mar 2020 12:12:56 +0000
Subject: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>
References: <70203ecd-a48e-4784-aee1-8d59241de4d6@default>
 <00940C28-2EAF-40D5-9C97-CC59C51B87B3@oracle.com>
 <2a109d9c-965c-4924-b081-c7f43694cdf9@default>
 <13e3aac5-87e8-4b13-f487-2d89529fa078@oracle.com>
 <CAKysZ8z5PH50tvwPSPptf9fn7T51TgaRp4RyX7UpbUmBwAD5dg@mail.gmail.com>
 <5154731a-3f0b-89ec-7e54-83355fd9e9b1@oracle.com>
 <61b15923-9770-4f48-9af4-cc174c04e665@default>
 <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>
Message-ID: <88a9bb98-b3be-dea7-cc11-ca53dc21fb4e@oracle.com>

Hi Ravi,

This looks good to me.

best regards,

-- daniel

On 02/03/2020 15:01, Ravi Reddy wrote:
> Hi Daniel,
> 
> As suggested by you I have added a test case for retry connection with proxy case . Please review the latest webrev and let me know your comments.
> 
> With the latest changes , the HttpURLConWithProxy test fails without the fix.
> 
> Webrev: http://cr.openjdk.java.net/~pkoppula/8183369/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8183369
> 
> 
> Thanks,
> Ravi
> 
> 
> -----Original Message-----
> From: Ravi Reddy
> Sent: Thursday, February 13, 2020 10:10 PM
> To: Daniel Fuchs <daniel.fuchs at oracle.com>; Vyom Tiwari <vyommani at gmail.com>
> Cc: net-dev <net-dev at openjdk.java.net>
> Subject: RE: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy
> 
> Hi Daniel/Vyom,
> 
> As mentioned in the review comments ,
>    Change in test case HttpURLConWithProxy.java is to make sure we don?t throw an error ?Can?t use direct connection? even when the connection is made through proxy. i.e to make sure the existing test case won't fail because of the fix.
> 
> Daniel , As you suggested I will try and come up with a test case to make sure there is a retry happening after connection fails once through proxy.
> 
> 
> 
> Thanks,
> Ravi
> 
> -----Original Message-----
> From: Daniel Fuchs
> Sent: Thursday, February 13, 2020 8:59 PM
> To: Vyom Tiwari <vyommani at gmail.com>
> Cc: Ravi Reddy <ravi.k.reddy at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>; net-dev <net-dev at openjdk.java.net>
> Subject: Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy
> 
> Thanks Vyom.
> 
> I was suspecting as much.
> 
> Ravi, could you come up with a test that fails without the fix and pass with it?
> 
> best regards,
> 
> -- daniel
> 
> 
> On 13/02/2020 14:26, Vyom Tiwari wrote:
>> Hi Ravi/Daniel,
>>
>> At my local env(REL 7) test is passing without fix as well. Although
>> my local repo contain some additional code changes but it is not
>> related with the current fix.
>> ################
>> Test1 Passed with: Connect timed out
>> Test2 Passed with: Connect timed out
>> ##################
>>
>> Please change copyright year(2020) as well.
>>
>> Thanks,
>> Vyom
> 


From chris.hegarty at oracle.com  Tue Mar  3 13:49:16 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 3 Mar 2020 13:49:16 +0000
Subject: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>
References: <70203ecd-a48e-4784-aee1-8d59241de4d6@default>
 <00940C28-2EAF-40D5-9C97-CC59C51B87B3@oracle.com>
 <2a109d9c-965c-4924-b081-c7f43694cdf9@default>
 <13e3aac5-87e8-4b13-f487-2d89529fa078@oracle.com>
 <CAKysZ8z5PH50tvwPSPptf9fn7T51TgaRp4RyX7UpbUmBwAD5dg@mail.gmail.com>
 <5154731a-3f0b-89ec-7e54-83355fd9e9b1@oracle.com>
 <61b15923-9770-4f48-9af4-cc174c04e665@default>
 <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>
Message-ID: <3BA374B6-801E-490E-8364-80C14CE55312@oracle.com>

Ravi,

> On 2 Mar 2020, at 15:01, Ravi Reddy <ravi.k.reddy at oracle.com> wrote:
> 
> Hi Daniel,
> 
> As suggested by you I have added a test case for retry connection with proxy case . Please review the latest webrev and let me know your comments.
> 
> With the latest changes , the HttpURLConWithProxy test fails without the fix.
> 
> Webrev: http://cr.openjdk.java.net/~pkoppula/8183369/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8183369

LGTM.

The use of logger in the test is very clever.

-Chris.

From vtewar26 at in.ibm.com  Tue Mar  3 14:54:23 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Tue, 3 Mar 2020 14:54:23 +0000
Subject: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>
References: <273d0a92-a43c-4b35-93db-0cf12ad42b0a@default>,
 <70203ecd-a48e-4784-aee1-8d59241de4d6@default>
 <00940C28-2EAF-40D5-9C97-CC59C51B87B3@oracle.com>
 <2a109d9c-965c-4924-b081-c7f43694cdf9@default>
 <13e3aac5-87e8-4b13-f487-2d89529fa078@oracle.com>
 <CAKysZ8z5PH50tvwPSPptf9fn7T51TgaRp4RyX7UpbUmBwAD5dg@mail.gmail.com>
 <5154731a-3f0b-89ec-7e54-83355fd9e9b1@oracle.com>
 <61b15923-9770-4f48-9af4-cc174c04e665@default>
Message-ID: <OFA7DDE328.972C81FF-ON00258520.0051A97E-00258520.0051E226@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200303/22e7f318/attachment.htm>

From daniel.fuchs at oracle.com  Tue Mar  3 15:48:09 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 3 Mar 2020 15:48:09 +0000
Subject: (solaris) 8059309: network tests fail with
 "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
In-Reply-To: <AM6PR03MB4389B32745F98D80A44F02BDFFE70@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <4ea0a9a3-7ff7-4127-2196-d1626e3bbc19@oracle.com>
 <AM6PR03MB4389607B87F144CAC78CA32EFFE80@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <995e5380-9dfa-e003-ba8f-6f0d1c5bbc78@oracle.com>
 <AM6PR03MB4389B32745F98D80A44F02BDFFE70@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <d4ba62c2-a496-9899-c390-2bb998dcc658@oracle.com>

Hi Bernd,

On 02/03/2020 20:44, Bernd Eckenfels wrote:
> However the question is, if other conditions (address families for 
> tunnels, x.25 etc) than loopback can also trigger this unsupported case 
> - but would actually return something in the fallback. So maybe for 
> compatibility trying the fallback is needed.

Yes that was my point. And it works with the loopback too since
in that case there's nothing to be found (either with DLPI or
with the fallback)

> 
> But in that case a loopback specific shortcut would be beneficial.

OK - maybe - here is an extended solution that will directly
return null if the NetworkInterface is the loopback.
However, there's a penalty to be paid for every interface
that is *not* the loopback.

http://cr.openjdk.java.net/~dfuchs/webrev_8059309/webrev.01/

Not sure which alternative is better?

best regards,

-- daniel



From christoph.langer at sap.com  Wed Mar  4 12:12:01 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 4 Mar 2020 12:12:01 +0000
Subject: RFR 8129841 Update comment for
 Java_java_net_Inet6AddressImpl_getHostByAddr
In-Reply-To: <OFC6CD64E3.E8657627-ON00258520.003B49F2-00258520.003BDA33@notes.na.collabserv.com>
References: <OFC6CD64E3.E8657627-ON00258520.003B49F2-00258520.003BDA33@notes.na.collabserv.com>
Message-ID: <AM0PR02MB5714FE3440ECCD6F2F1A2FE18AE50@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Vipin,

I'm forwarding this to net-dev where it should be reviewed.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Vipin Mv1
> Sent: Dienstag, 3. M?rz 2020 11:54
> To: core-libs-dev at openjdk.java.net
> Subject: RFR 8129841 Update comment for
> Java_java_net_Inet6AddressImpl_getHostByAddr
> 
> Hi All,
> 
> Please find the below changes for the issue
> https://bugs.openjdk.java.net/browse/JDK-8129841. Apart from the
> requested changes, I have made additional changes to the Signature where
> ever I found it incorrect.
> 
> 
> Thanks
> Vipin M V
> 
> 
> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c
> --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Wed Feb 05
> 12:20:36 2020 -0300
> +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Tue Mar 03
> 15:32:21 2020 +0530
> @@ -218,7 +218,7 @@
>  /*
>   * Class:     java_net_Inet4AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c
> --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Wed Feb 05
> 12:20:36 2020 -0300
> +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Tue Mar 03
> 15:32:21 2020 +0530
> @@ -413,7 +413,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> @@ -668,7 +668,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    isReachable0
> - * Signature: ([bII[bI)Z
> + * Signature: ([BII[BII)Z
>   */
>  JNIEXPORT jboolean JNICALL
>  Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
> diff -r 387369ff21a4
> src/java.base/windows/native/libnet/Inet4AddressImpl.c
> --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Wed
> Feb 05 12:20:36 2020 -0300
> +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Tue
> Mar 03 15:32:21 2020 +0530
> @@ -171,7 +171,7 @@
>  /*
>   * Class:     java_net_Inet4AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> diff -r 387369ff21a4
> src/java.base/windows/native/libnet/Inet6AddressImpl.c
> --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Wed
> Feb 05 12:20:36 2020 -0300
> +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Tue
> Mar 03 15:32:21 2020 +0530
> @@ -240,7 +240,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> @@ -435,7 +435,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    isReachable0
> - * Signature: ([bII[bI)Z
> + * Signature: ([BII[BII)Z
>   */
>  JNIEXPORT jboolean JNICALL
>  Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
> 
> 


From mark.reinhold at oracle.com  Wed Mar  4 23:57:39 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  5 Mar 2020 00:57:39 +0100 (CET)
Subject: New candidate JEP: 373: Reimplement the Legacy DatagramSocket API
Message-ID: <20200304235739.4B866319166@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/373

- Mark

From vtewar26 at in.ibm.com  Thu Mar  5 08:49:05 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Thu, 5 Mar 2020 08:49:05 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
References: <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
Message-ID: <OFCC0AB7C2.A78B5406-ON00258522.00305643-00258522.00307096@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200305/bd85bd9f/attachment.htm>

From julia.boes at oracle.com  Thu Mar  5 13:50:55 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 5 Mar 2020 13:50:55 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
Message-ID: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>

Hi,

Please see this fix that adds support for non-default file systems to 
the HttpClient. More specifically, the change is in 
RequestPublishers.FilePublisher where an UnsupportedOperationException 
is thrown if a java.io.File cannot be obtained. The exception is now 
caught and a function is used to obtain an InputStream with a privileged 
scope based on the captured AccessControlContext.

Bug: https://bugs.openjdk.java.net/browse/JDK-8235459

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

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.01/

Tests were run with repeat 100 cross-platform. A similar change to the 
receiving side is currently work in progress.

Regards,

Julia




From anthonyv.be at outlook.com  Thu Mar  5 18:25:46 2020
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Thu, 5 Mar 2020 19:25:46 +0100
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
Message-ID: <DB8PR07MB637984BB6DF51B80621D6AF4E8E20@DB8PR07MB6379.eurprd07.prod.outlook.com>

Hi Julia

Here's some suggestions w.r.t. RequestPublishers.java:

For distinguishing the non-default filesystem case, an alternative to 
using the try-catch block
is an if-else block with the same check as is done in Path::toFile:
 ??? if (path.getFileSystem() == FileSystems.getDefault())

When setting `length`, the catch clause can be limited to IOException, 
rather than Exception.

Maybe change the method `RuntimeException toUncheckedException(...)` to 
`void throwAsUncheckedException(...)`
and then instead of `throw toUncheckedException(...)` use 
`throwAsUncheckedException(...)`

Kind regards,
Anthony

On 05/03/2020 14:50, Julia Boes wrote:
> Hi,
>
> Please see this fix that adds support for non-default file systems to 
> the HttpClient. More specifically, the change is in 
> RequestPublishers.FilePublisher where an UnsupportedOperationException 
> is thrown if a java.io.File cannot be obtained. The exception is now 
> caught and a function is used to obtain an InputStream with a 
> privileged scope based on the captured AccessControlContext.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235459
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8240526
>
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.01/
>
> Tests were run with repeat 100 cross-platform. A similar change to the 
> receiving side is currently work in progress.
>
> Regards,
>
> Julia
>
>
>

From julia.boes at oracle.com  Fri Mar  6 13:04:54 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Fri, 6 Mar 2020 13:04:54 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <DB8PR07MB637984BB6DF51B80621D6AF4E8E20@DB8PR07MB6379.eurprd07.prod.outlook.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <DB8PR07MB637984BB6DF51B80621D6AF4E8E20@DB8PR07MB6379.eurprd07.prod.outlook.com>
Message-ID: <4125bd77-7c4b-f275-8d0c-ec8821d1898a@oracle.com>

Hi Anthony,

Thanks for your comments.

> For distinguishing the non-default filesystem case, an alternative to 
> using the try-catch block
> is an if-else block with the same check as is done in Path::toFile:
> ??? if (path.getFileSystem() == FileSystems.getDefault())

Path::toFile can be overridden so the try-catch block potentially covers 
more cases.

>
> When setting `length`, the catch clause can be limited to IOException, 
> rather than Exception.
Good catch, changed.
>
> Maybe change the method `RuntimeException toUncheckedException(...)` 
> to `void throwAsUncheckedException(...)`
> and then instead of `throw toUncheckedException(...)` use 
> `throwAsUncheckedException(...)`

In that case FilePublisher::createInputStream would be missing a return 
statement. The original version makes it explicit that we always throw 
something - I'll stick to the original version if that's ok with you.

Webrev is updated.

Cheers,

Julia



From anthonyv.be at outlook.com  Fri Mar  6 17:41:45 2020
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Fri, 6 Mar 2020 18:41:45 +0100
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <4125bd77-7c4b-f275-8d0c-ec8821d1898a@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <DB8PR07MB637984BB6DF51B80621D6AF4E8E20@DB8PR07MB6379.eurprd07.prod.outlook.com>
 <4125bd77-7c4b-f275-8d0c-ec8821d1898a@oracle.com>
Message-ID: <AM0PR07MB6372F87EC75EE1BF665E5CDBE8E30@AM0PR07MB6372.eurprd07.prod.outlook.com>

Hi Julia

On 06/03/2020 14:04, Julia Boes wrote:
> Hi Anthony,
>
> Thanks for your comments.
>
>> For distinguishing the non-default filesystem case, an alternative to 
>> using the try-catch block
>> is an if-else block with the same check as is done in Path::toFile:
>> ??? if (path.getFileSystem() == FileSystems.getDefault())
>
> Path::toFile can be overridden so the try-catch block potentially 
> covers more cases.
Good point, I hadn't thought of that.
>
>>
>> When setting `length`, the catch clause can be limited to 
>> IOException, rather than Exception.
> Good catch, changed.
>>
>> Maybe change the method `RuntimeException toUncheckedException(...)` 
>> to `void throwAsUncheckedException(...)`
>> and then instead of `throw toUncheckedException(...)` use 
>> `throwAsUncheckedException(...)`
>
> In that case FilePublisher::createInputStream would be missing a 
> return statement. The original version makes it explicit that we 
> always throw something - I'll stick to the original version if that's 
> ok with you.
I see now, thanks, and agree the original version is preferable.
> Webrev is updated.
>
> Cheers,
>
> Julia
>
>
Kind regards,
Anthony


From vtewar26 at in.ibm.com  Sat Mar  7 13:11:42 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Sat, 7 Mar 2020 13:11:42 +0000
Subject: RFR 8238579: HttpsURLConnection drops the timeout and hangs
 forever in read
In-Reply-To: <528a9ccb-36b8-9bf9-2eab-eacf705f87a5@oracle.com>
References: <528a9ccb-36b8-9bf9-2eab-eacf705f87a5@oracle.com>,
 <18d32bba-9a71-c003-cb26-c3ea423456d9@oracle.com>
 <CAKysZ8yG+o7JHvgeoOWA-m4FptYiFPg9mbLNrSpGNDArmgZHHg@mail.gmail.com>
 <OF86C130D3.7C5F7758-ON0025850F.0017442A-0025850F.001751AC@notes.na.collabserv.com>
Message-ID: <OFFC002F5A.1A90D603-ON00258524.00485649-00258524.00487BB8@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200307/6348691b/attachment.htm>

From sha.jiang at oracle.com  Mon Mar  9 02:07:23 2020
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 9 Mar 2020 10:07:23 +0800
Subject: RFR[15] JDK-8238740:
 java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS
 protocol
In-Reply-To: <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>
References: <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>
Message-ID: <cccc0abb-f7e2-596b-29a7-bbb961529dc1@oracle.com>

Could this simple patch be reviewed?

John

On 2020/3/2 16:08, sha.jiang at oracle.com wrote:
> Hi,
> java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> would not use a specific TLS protocol, instead just use the default 
> TLS protocol, exactly TLSv1.3 now.
>
> diff -r 4a5a7dc9d05c 
> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java
> --- 
> a/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> Sun Mar 01 17:36:03 2020 -0800
> +++ 
> b/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> Mon Mar 02 16:01:15 2020 +0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -80,7 +80,6 @@
> ???????? SSLEngine engineClient = ctx.createSSLEngine();
> ???????? SSLParameters params = ctx.getSupportedSSLParameters();
> ???????? params.setApplicationProtocols(new String[]{"proto1", 
> "proto2"}); // server will choose proto2
> -??????? params.setProtocols(new String[]{"TLSv1.2"}); // TODO: This 
> is essential. Needs to be protocol impl
> ???????? engineClient.setSSLParameters(params);
> ???????? engineClient.setUseClientMode(true);
> ???????? completion = new CompletableFuture<>();
>
> Best regards,
> John Jiang
>

From vtewar26 at in.ibm.com  Mon Mar  9 03:28:50 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Mon, 9 Mar 2020 03:28:50 +0000
Subject: RFR[15] JDK-8238740:
 java/net/httpclient/whitebox/FlowTestDriver.java
 would not specify a TLS protocol
In-Reply-To: <cccc0abb-f7e2-596b-29a7-bbb961529dc1@oracle.com>
References: <cccc0abb-f7e2-596b-29a7-bbb961529dc1@oracle.com>,
 <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>
Message-ID: <OFEDE91CED.2BB733E9-ON00258526.0012F6AF-00258526.00131EB1@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200309/b02cb4aa/attachment.htm>

From patrick.concannon at oracle.com  Mon Mar  9 12:39:05 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Mon, 9 Mar 2020 12:39:05 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending
 large datagrams (macOS)'
Message-ID: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>

Hi,

Could someone please review my fix for JDK-8239355 '(dc) Initial value 
of SO_SNDBUF should allow sending large datagrams (macOS)' ?

By default, macOS imposes a size of 9216on Datagrams which limits 
applications that don't set the SO_SNDBUF option - legacy DatagramSocket 
sets the value to 65507 at creation time.
This fix updates DatagramChannel so that the SO_SNDBUF is set to a 
minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets on 
macOS.


bug: https://bugs.openjdk.java.net/browse/JDK-8239355
webrev: 
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html

Kind regards,

Patrick


From daniel.fuchs at oracle.com  Mon Mar  9 16:53:16 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 9 Mar 2020 16:53:16 +0000
Subject: 8240754: Instrument FlowTest.java to provide more debug traces.
Message-ID: <03dc72b7-742b-bdcc-4ac0-a314ad34e0d7@oracle.com>

Hi,

Please find below a changeset that adds some more debugging
output to FlowTest.java for better test failure diagnosis.

8240754: Instrument FlowTest.java to provide more debug traces.
https://bugs.openjdk.java.net/browse/JDK-8240754

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8240754/webrev.00/

best regards,

-- daniel

From Alan.Bateman at oracle.com  Mon Mar  9 17:01:25 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Mar 2020 17:01:25 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
Message-ID: <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>



On 09/03/2020 12:39, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8239355 '(dc) Initial value 
> of SO_SNDBUF should allow sending large datagrams (macOS)' ?
>
> By default, macOS imposes a size of 9216on Datagrams which limits 
> applications that don't set the SO_SNDBUF option - legacy 
> DatagramSocket sets the value to 65507 at creation time.
> This fix updates DatagramChannel so that the SO_SNDBUF is set to a 
> minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets on 
> macOS.
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8239355
> webrev: 
> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html
This is a change to the DatagramChannel implementation. I guess I 
assumed there would be a DatagramChannel test that checked that 
getOption(SO_SNDBUF) returned a minimum value for both the IPv4 and IPv6 
cases. Testing send is a good idea but I'm concerned it is testing 
DatagramSocket implementation details that are a bit questionable. It's 
mostly SOCKET_SNDBUF = IPV4_SENDBUF that I'm concerned about because 
PlainDatagramSocketImpl isn't quite right (it shouldn't set SO_RCVBUF, 
it shouldn't set SO_SNDBUF if the default is larger, and it's not quite 
right for the IPv6 case). Will the test need further work when 
DatagramSocket is changed to delegate to a socket adaptor? Maybe we 
should change PlainDatagramSocketImpl at the same time?

-Alan






From chris.hegarty at oracle.com  Mon Mar  9 17:30:21 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 9 Mar 2020 17:30:21 +0000
Subject: 8240754: Instrument FlowTest.java to provide more debug traces.
In-Reply-To: <03dc72b7-742b-bdcc-4ac0-a314ad34e0d7@oracle.com>
References: <03dc72b7-742b-bdcc-4ac0-a314ad34e0d7@oracle.com>
Message-ID: <B84D1DE1-5900-4676-B15B-6D8AB8D4DC21@oracle.com>

Daniel,

> On 9 Mar 2020, at 16:53, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a changeset that adds some more debugging
> output to FlowTest.java for better test failure diagnosis.
> 
> 8240754: Instrument FlowTest.java to provide more debug traces.
> https://bugs.openjdk.java.net/browse/JDK-8240754
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8240754/webrev.00/

Looks ok to me.

-Chris.


From daniel.fuchs at oracle.com  Mon Mar  9 18:08:06 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 9 Mar 2020 18:08:06 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
Message-ID: <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>

Hi Alan,

On 09/03/2020 17:01, Alan Bateman wrote:
> On 09/03/2020 12:39, Patrick Concannon wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8239355
>> webrev: 
>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html 
>>
> This is a change to the DatagramChannel implementation. I guess I 
> assumed there would be a DatagramChannel test that checked that 
> getOption(SO_SNDBUF) returned a minimum value for both the IPv4 and IPv6 
> cases.

+1. It's so obvious I didn't think of it when Patrick & I discussed
the test.

> Testing send is a good idea but I'm concerned it is testing 
> DatagramSocket implementation details that are a bit questionable. It's 
> mostly SOCKET_SNDBUF = IPV4_SENDBUF that I'm concerned about because 
> PlainDatagramSocketImpl isn't quite right (it shouldn't set SO_RCVBUF, 
> it shouldn't set SO_SNDBUF if the default is larger, and it's not quite 
> right for the IPv6 case).

Yes - these are known limitations/issues with the current DatagramSocket
implementation on macOS.

> Will the test need further work when 
> DatagramSocket is changed to delegate to a socket adaptor?

Yes the test will need to change, and I believe that's OK.
Patrick already has already a change for that in the
JEP 373 branch.

> Maybe we 
> should change PlainDatagramSocketImpl at the same time?

I would advise against it. I think we should leave the
legacy stack unchanged.

best regards,

-- daniel

> 
> -Alan



From Alan.Bateman at oracle.com  Mon Mar  9 20:03:00 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Mar 2020 20:03:00 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
Message-ID: <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>



On 09/03/2020 18:08, Daniel Fuchs wrote:
> Hi Alan,
>
> On 09/03/2020 17:01, Alan Bateman wrote:
>> On 09/03/2020 12:39, Patrick Concannon wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8239355
>>> webrev: 
>>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html 
>>>
>> This is a change to the DatagramChannel implementation. I guess I 
>> assumed there would be a DatagramChannel test that checked that 
>> getOption(SO_SNDBUF) returned a minimum value for both the IPv4 and 
>> IPv6 cases.
>
> +1. It's so obvious I didn't think of it when Patrick & I discussed
> the test.
Okay, I think that would be useful to add as a macOS specific test. Also 
we can test DatagramChannel sending datagrams of maximum size on all 
platforms (doesn't need to be macOS specific). We probably don't need a 
DatagramSocket test for this change as it doesn't touch that code (and 
the code in PDSI isn't quite right).

-Alan

From daniel.fuchs at oracle.com  Tue Mar 10 13:11:38 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Mar 2020 13:11:38 +0000
Subject: RFR[15] JDK-8238740:
 java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS
 protocol
In-Reply-To: <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>
References: <b8dcf34e-31b5-3ad2-a6df-4490926cc6ee@oracle.com>
Message-ID: <f218d766-f758-1fbd-096c-90dd5161dc64@oracle.com>

Hi John,

Looks good to me.

best regards,

-- daniel

On 02/03/2020 08:08, sha.jiang at oracle.com wrote:
> Hi,
> java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> would not use a specific TLS protocol, instead just use the default TLS 
> protocol, exactly TLSv1.3 now.
> 
> diff -r 4a5a7dc9d05c 
> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> 
> --- 
> a/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> Sun Mar 01 17:36:03 2020 -0800
> +++ 
> b/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java 
> Mon Mar 02 16:01:15 2020 +0800
> @@ -1,5 +1,5 @@
>  ?/*
> - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights 
> reserved.
>  ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  ? *
>  ? * This code is free software; you can redistribute it and/or modify it
> @@ -80,7 +80,6 @@
>  ???????? SSLEngine engineClient = ctx.createSSLEngine();
>  ???????? SSLParameters params = ctx.getSupportedSSLParameters();
>  ???????? params.setApplicationProtocols(new String[]{"proto1", 
> "proto2"}); // server will choose proto2
> -??????? params.setProtocols(new String[]{"TLSv1.2"}); // TODO: This is 
> essential. Needs to be protocol impl
>  ???????? engineClient.setSSLParameters(params);
>  ???????? engineClient.setUseClientMode(true);
>  ???????? completion = new CompletableFuture<>();
> 
> Best regards,
> John Jiang
> 


From chris.hegarty at oracle.com  Tue Mar 10 13:24:40 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Mar 2020 13:24:40 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
Message-ID: <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>

Julia,

> On 5 Mar 2020, at 13:50, Julia Boes <julia.boes at oracle.com> wrote:
> 
> Hi,
> 
> Please see this fix that adds support for non-default file systems to the HttpClient. More specifically, the change is in RequestPublishers.FilePublisher where an UnsupportedOperationException is thrown if a java.io.File cannot be obtained. The exception is now caught and a function is used to obtain an InputStream with a privileged scope based on the captured AccessControlContext.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235459
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8240526

I added myself as reviewer.

> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.01/

The change looks good, and the tests appear comprehensive.

-Chris.


From daniel.fuchs at oracle.com  Tue Mar 10 15:37:37 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Mar 2020 15:37:37 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
References: <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
Message-ID: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>

Hi Vyom,

I have sent your proposed fix to our test system and observed no
regression. I agree your proposed changes seem to address the
issue adequately. However, I'd like to hear a second opinion on the
possible side effects of this fix, since NET_Timeout may be called
at many other places.

I see that Alan has commented on
https://bugs.openjdk.java.net/browse/JDK-8237858

It would be good to get his approval (or at least Michael McMahon's) 
before pushing.

best regards,

-- daniel

On 25/02/2020 16:36, Vyom Tewari26 wrote:
> Hi ,
> Please find the below fix for the 
> issue(https://bugs.openjdk.java.net/browse/JDK-8237858). In 
> "PlainSocketImpl_socketAccept" did not handle -1 timeout? properly.
> In case of -1 timeout, "PlainSocketImpl_socketAccept" calls 
> "NET_Timeout"? if it is interrupted by signal(EINTR) then in case of -1 
> timeout it returns immediately instead of looping again.
> Thanks,
> Vyom
> ##########################################################
> diff -r d6b968af8b65 src/java.base/linux/native/libnet/linux_close.c
> --- a/src/java.base/linux/native/libnet/linux_close.c?? ?Mon Feb 24 
> 23:44:29 2020 -0500
> +++ b/src/java.base/linux/native/libnet/linux_close.c?? ?Tue Feb 25 
> 19:06:11 2020 +0530
> @@ -437,12 +437,16 @@
>  ????????? * has expired return 0 (indicating timeout expired).
>  ????????? */
>  ???????? if (rv < 0 && errno == EINTR) {
> -??????????? jlong newNanoTime = JVM_NanoTime(env, 0);
> -??????????? nanoTimeout -= newNanoTime - prevNanoTime;
> -??????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
> -??????????????? return 0;
> +??????????? if(timeout > 0) {
> +??????????????? jlong newNanoTime = JVM_NanoTime(env, 0);
> +??????????????? nanoTimeout -= newNanoTime - prevNanoTime;
> +??????????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
> +??????????????????? return 0;
> +??????????????? }
> +??????????????? prevNanoTime = newNanoTime;
> +??????????? } else {
> +??????????????? continue; // timeout is -1, so? loop again.
>  ???????????? }
> -??????????? prevNanoTime = newNanoTime;
>  ???????? } else {
>  ???????????? return rv;
>  ???????? }
> 
> ############################################################
> 


From michael.x.mcmahon at oracle.com  Tue Mar 10 16:37:14 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 10 Mar 2020 17:37:14 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
References: <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
Message-ID: <7cbe7961-0ec4-fecc-68fc-f86503fc08b9@oracle.com>

The change looks okay to me. Though the comment about the -1 case also 
applies
if timeout is 0. The behavior is still okay in that case, but the 
comment should acknowledge that,
however unlikely it is to occur.

- Michael.

On 10/03/2020 16:37, Daniel Fuchs wrote:
> Hi Vyom,
>
> I have sent your proposed fix to our test system and observed no
> regression. I agree your proposed changes seem to address the
> issue adequately. However, I'd like to hear a second opinion on the
> possible side effects of this fix, since NET_Timeout may be called
> at many other places.
>
> I see that Alan has commented on
> https://bugs.openjdk.java.net/browse/JDK-8237858
>
> It would be good to get his approval (or at least Michael McMahon's) 
> before pushing.
>
> best regards,
>
> -- daniel
>
> On 25/02/2020 16:36, Vyom Tewari26 wrote:
>> Hi ,
>> Please find the below fix for the 
>> issue(https://bugs.openjdk.java.net/browse/JDK-8237858). In 
>> "PlainSocketImpl_socketAccept" did not handle -1 timeout properly.
>> In case of -1 timeout, "PlainSocketImpl_socketAccept" calls 
>> "NET_Timeout"? if it is interrupted by signal(EINTR) then in case of 
>> -1 timeout it returns immediately instead of looping again.
>> Thanks,
>> Vyom
>> ##########################################################
>> diff -r d6b968af8b65 src/java.base/linux/native/libnet/linux_close.c
>> --- a/src/java.base/linux/native/libnet/linux_close.c?? ?Mon Feb 24 
>> 23:44:29 2020 -0500
>> +++ b/src/java.base/linux/native/libnet/linux_close.c?? ?Tue Feb 25 
>> 19:06:11 2020 +0530
>> @@ -437,12 +437,16 @@
>> ?????????? * has expired return 0 (indicating timeout expired).
>> ?????????? */
>> ????????? if (rv < 0 && errno == EINTR) {
>> -??????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>> -??????????? nanoTimeout -= newNanoTime - prevNanoTime;
>> -??????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>> -??????????????? return 0;
>> +??????????? if(timeout > 0) {
>> +??????????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>> +??????????????? nanoTimeout -= newNanoTime - prevNanoTime;
>> +??????????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>> +??????????????????? return 0;
>> +??????????????? }
>> +??????????????? prevNanoTime = newNanoTime;
>> +??????????? } else {
>> +??????????????? continue; // timeout is -1, so? loop again.
>> ????????????? }
>> -??????????? prevNanoTime = newNanoTime;
>> ????????? } else {
>> ????????????? return rv;
>> ????????? }
>>
>> ############################################################
>>
>

From vtewar26 at in.ibm.com  Tue Mar 10 16:53:14 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Tue, 10 Mar 2020 16:53:14 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
References: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>,
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
Message-ID: <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200310/02af7858/attachment-0001.htm>

From daniel.fuchs at oracle.com  Tue Mar 10 17:21:35 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 Mar 2020 17:21:35 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
References: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
Message-ID: <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>

Hi Vyom,

Now I have second thoughts. The documentation of poll(2) says:

        int poll(struct pollfd *fds, nfds_t nfds, int timeout);

        [...]

        Specifying a negative value in timeout means an infinite
        timeout.
        Specifying a timeout of zero causes poll() to return
        immediately, even if no file descriptors are ready.

As Michael hinted, are we sure that we are handling the
timeout=0 case properly?

Moreover, the timeout parameter is supposed to be an int.
I'd be more satisfied if we declared an int variable e.g.

    int timeoutms = timeout;

at about line 411, and then update it just after line 446:

    timeoutms = nanoTimeout / NET_NSEC_PER_MSEC

What do you think?

Also JDK-8179905 [1] also modified aix_close.c, solaris_close.c,
bsd_close.c [2] - so I believe you should also fix all these places.

best regards,

-- daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8179905
[2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/cc195249c879

On 10/03/2020 16:53, Vyom Tewari26 wrote:
> Hi Daniel,
> Thanks for review and running all tests,? In past we(i am the culprit) 
> removed the "if(timeout > 0) {" condition by mistake. This check is to 
> make sure that if the timeout set only then we do all other time 
> calculation but somehow it was not very clear by reading the code.
> NET_Timeout does not tells that there is infinite(-1) timeout as well, 
> if you see the code changes I explicitly put else block to make code 
> more readable.
> I hosted the patch to 
> cr.openjdk.net(http://cr.openjdk.java.net/~vtewari/8237858/webrev/index.html).
> Thanks,
> Vyom
> 
>     ----- Original message -----
>     From: Daniel Fuchs <daniel.fuchs at oracle.com>
>     To: Vyom Tewari26 <vtewar26 at in.ibm.com>, net-dev at openjdk.java.net
>     Cc:
>     Subject: [EXTERNAL] Re: RFR 8237858: PlainSocketImpl.socketAccept()
>     handles EINTR incorrectly
>     Date: Tue, Mar 10, 2020 9:07 PM
>     Hi Vyom,
> 
>     I have sent your proposed fix to our test system and observed no
>     regression. I agree your proposed changes seem to address the
>     issue adequately. However, I'd like to hear a second opinion on the
>     possible side effects of this fix, since NET_Timeout may be called
>     at many other places.
> 
>     I see that Alan has commented on
>     https://bugs.openjdk.java.net/browse/JDK-8237858
> 
>     It would be good to get his approval (or at least Michael McMahon's)
>     before pushing.
> 
>     best regards,
> 
>     -- daniel
> 
>     On 25/02/2020 16:36, Vyom Tewari26 wrote:
>      > Hi ,
>      > Please find the below fix for the
>      > issue(https://bugs.openjdk.java.net/browse/JDK-8237858?). In
>      > "PlainSocketImpl_socketAccept" did not handle -1 timeout? properly.
>      > In case of -1 timeout, "PlainSocketImpl_socketAccept" calls
>      > "NET_Timeout"? if it is interrupted by signal(EINTR) then in case
>     of -1
>      > timeout it returns immediately instead of looping again.
>      > Thanks,
>      > Vyom
>      > ##########################################################
>      > diff -r d6b968af8b65 src/java.base/linux/native/libnet/linux_close.c
>      > --- a/src/java.base/linux/native/libnet/linux_close.c?? ?Mon Feb 24
>      > 23:44:29 2020 -0500
>      > +++ b/src/java.base/linux/native/libnet/linux_close.c?? ?Tue Feb 25
>      > 19:06:11 2020 +0530
>      > @@ -437,12 +437,16 @@
>      > ?????????? * has expired return 0 (indicating timeout expired).
>      > ?????????? */
>      > ????????? if (rv < 0 && errno == EINTR) {
>      > -??????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>      > -??????????? nanoTimeout -= newNanoTime - prevNanoTime;
>      > -??????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>      > -??????????????? return 0;
>      > +??????????? if(timeout > 0) {
>      > +??????????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>      > +??????????????? nanoTimeout -= newNanoTime - prevNanoTime;
>      > +??????????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>      > +??????????????????? return 0;
>      > +??????????????? }
>      > +??????????????? prevNanoTime = newNanoTime;
>      > +??????????? } else {
>      > +??????????????? continue; // timeout is -1, so? loop again.
>      > ????????????? }
>      > -??????????? prevNanoTime = newNanoTime;
>      > ????????? } else {
>      > ????????????? return rv;
>      > ????????? }
>      >
>      > ############################################################
>      >
> 
> 


From michael.x.mcmahon at oracle.com  Tue Mar 10 17:25:28 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 10 Mar 2020 18:25:28 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
References: <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
Message-ID: <1164204b-750a-99c2-8abc-aa2aac00df15@oracle.com>

As it happens, I'm not sure that NET_Timeout is ever called with timeout 
= 0.

A zero value for the socket option means block forever and there is no 
support
for polling in the API.

- Michael.

On 10/03/2020 18:21, Daniel Fuchs wrote:
> Hi Vyom,
>
> Now I have second thoughts. The documentation of poll(2) says:
>
> ?????? int poll(struct pollfd *fds, nfds_t nfds, int timeout);
>
> ?????? [...]
>
> ?????? Specifying a negative value in timeout means an infinite
> ?????? timeout.
> ?????? Specifying a timeout of zero causes poll() to return
> ?????? immediately, even if no file descriptors are ready.
>
> As Michael hinted, are we sure that we are handling the
> timeout=0 case properly?
>
> Moreover, the timeout parameter is supposed to be an int.
> I'd be more satisfied if we declared an int variable e.g.
>
> ?? int timeoutms = timeout;
>
> at about line 411, and then update it just after line 446:
>
> ?? timeoutms = nanoTimeout / NET_NSEC_PER_MSEC
>
> What do you think?
>
> Also JDK-8179905 [1] also modified aix_close.c, solaris_close.c,
> bsd_close.c [2] - so I believe you should also fix all these places.
>
> best regards,
>
> -- daniel
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8179905
> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/cc195249c879
>
> On 10/03/2020 16:53, Vyom Tewari26 wrote:
>> Hi Daniel,
>> Thanks for review and running all tests,? In past we(i am the 
>> culprit) removed the "if(timeout > 0) {" condition by mistake. This 
>> check is to make sure that if the timeout set only then we do all 
>> other time calculation but somehow it was not very clear by reading 
>> the code.
>> NET_Timeout does not tells that there is infinite(-1) timeout as 
>> well, if you see the code changes I explicitly put else block to make 
>> code more readable.
>> I hosted the patch to 
>> cr.openjdk.net(http://cr.openjdk.java.net/~vtewari/8237858/webrev/index.html).
>> Thanks,
>> Vyom
>>
>> ??? ----- Original message -----
>> ??? From: Daniel Fuchs <daniel.fuchs at oracle.com>
>> ??? To: Vyom Tewari26 <vtewar26 at in.ibm.com>, net-dev at openjdk.java.net
>> ??? Cc:
>> ??? Subject: [EXTERNAL] Re: RFR 8237858: PlainSocketImpl.socketAccept()
>> ??? handles EINTR incorrectly
>> ??? Date: Tue, Mar 10, 2020 9:07 PM
>> ??? Hi Vyom,
>>
>> ??? I have sent your proposed fix to our test system and observed no
>> ??? regression. I agree your proposed changes seem to address the
>> ??? issue adequately. However, I'd like to hear a second opinion on the
>> ??? possible side effects of this fix, since NET_Timeout may be called
>> ??? at many other places.
>>
>> ??? I see that Alan has commented on
>> ??? https://bugs.openjdk.java.net/browse/JDK-8237858
>>
>> ??? It would be good to get his approval (or at least Michael McMahon's)
>> ??? before pushing.
>>
>> ??? best regards,
>>
>> ??? -- daniel
>>
>> ??? On 25/02/2020 16:36, Vyom Tewari26 wrote:
>> ???? > Hi ,
>> ???? > Please find the below fix for the
>> ???? > issue(https://bugs.openjdk.java.net/browse/JDK-8237858?). In
>> ???? > "PlainSocketImpl_socketAccept" did not handle -1 timeout? 
>> properly.
>> ???? > In case of -1 timeout, "PlainSocketImpl_socketAccept" calls
>> ???? > "NET_Timeout"? if it is interrupted by signal(EINTR) then in case
>> ??? of -1
>> ???? > timeout it returns immediately instead of looping again.
>> ???? > Thanks,
>> ???? > Vyom
>> ???? > ##########################################################
>> ???? > diff -r d6b968af8b65 
>> src/java.base/linux/native/libnet/linux_close.c
>> ???? > --- a/src/java.base/linux/native/libnet/linux_close.c?? ?Mon 
>> Feb 24
>> ???? > 23:44:29 2020 -0500
>> ???? > +++ b/src/java.base/linux/native/libnet/linux_close.c?? ?Tue 
>> Feb 25
>> ???? > 19:06:11 2020 +0530
>> ???? > @@ -437,12 +437,16 @@
>> ???? > ?????????? * has expired return 0 (indicating timeout expired).
>> ???? > ?????????? */
>> ???? > ????????? if (rv < 0 && errno == EINTR) {
>> ???? > -??????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>> ???? > -??????????? nanoTimeout -= newNanoTime - prevNanoTime;
>> ???? > -??????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>> ???? > -??????????????? return 0;
>> ???? > +??????????? if(timeout > 0) {
>> ???? > +??????????????? jlong newNanoTime = JVM_NanoTime(env, 0);
>> ???? > +??????????????? nanoTimeout -= newNanoTime - prevNanoTime;
>> ???? > +??????????????? if (nanoTimeout < NET_NSEC_PER_MSEC) {
>> ???? > +??????????????????? return 0;
>> ???? > +??????????????? }
>> ???? > +??????????????? prevNanoTime = newNanoTime;
>> ???? > +??????????? } else {
>> ???? > +??????????????? continue; // timeout is -1, so? loop again.
>> ???? > ????????????? }
>> ???? > -??????????? prevNanoTime = newNanoTime;
>> ???? > ????????? } else {
>> ???? > ????????????? return rv;
>> ???? > ????????? }
>> ???? >
>> ???? > ############################################################
>> ???? >
>>
>>
>

From patrick.concannon at oracle.com  Tue Mar 10 18:32:25 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 10 Mar 2020 18:32:25 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
Message-ID: <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>

Hi Alan and Daniel,

Thanks for the feedback.

I've changed the test to be DatagramChannel specific, and it now checks 
getOption(SO_SNDBUF) for both IPv4 and IPv6. You can find the updated 
webrev below.

http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02


Kind regards,

Patrick

On 09/03/2020 20:03, Alan Bateman wrote:
>
>
> On 09/03/2020 18:08, Daniel Fuchs wrote:
>> Hi Alan,
>>
>> On 09/03/2020 17:01, Alan Bateman wrote:
>>> On 09/03/2020 12:39, Patrick Concannon wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8239355
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html 
>>>>
>>> This is a change to the DatagramChannel implementation. I guess I 
>>> assumed there would be a DatagramChannel test that checked that 
>>> getOption(SO_SNDBUF) returned a minimum value for both the IPv4 and 
>>> IPv6 cases.
>>
>> +1. It's so obvious I didn't think of it when Patrick & I discussed
>> the test.
> Okay, I think that would be useful to add as a macOS specific test. 
> Also we can test DatagramChannel sending datagrams of maximum size on 
> all platforms (doesn't need to be macOS specific). We probably don't 
> need a DatagramSocket test for this change as it doesn't touch that 
> code (and the code in PDSI isn't quite right).
>
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200310/cc4c5483/attachment.htm>

From Alan.Bateman at oracle.com  Tue Mar 10 19:59:02 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Mar 2020 19:59:02 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
Message-ID: <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>

On 10/03/2020 18:32, Patrick Concannon wrote:
>
> Hi Alan and Daniel,
>
> Thanks for the feedback.
>
> I've changed the test to be DatagramChannel specific, and it now 
> checks getOption(SO_SNDBUF) for both IPv4 and IPv6. You can find the 
> updated webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02
>
Thanks for adding a test for getOption(SO_SNDBUF). That test 
(testGetOption) should be checking that SO_SNDBUF is >= expected value? 
as it's okay for net.inet.udp.maxdgram to have a larger than what the 
test expects.

testSend sends to the loopback address but I think we need this test to 
send datagrams on the network (sending to the loopback is okay too but I 
think you want this test to send a datagram on the network because we 
want fragmentation on the network(.

The java.net.preferIPv6Addresses system property is about configuring 
the order of name service lookup. These runs shouldn't impact anything 
here, dual and preferIPv4Stack=true should be all that is needed.

A minor nit is that we should probably find a name for the test that is 
consistent with the other tests in this area. Something like 
LargeDatagram or MinSendBufferSize is okay.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200310/24f364d2/attachment.htm>

From vtewar26 at in.ibm.com  Wed Mar 11 03:14:56 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Wed, 11 Mar 2020 03:14:56 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
References: <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>,
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
Message-ID: <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200311/b1f95ed0/attachment-0001.htm>

From vtewar26 at in.ibm.com  Wed Mar 11 04:50:52 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Wed, 11 Mar 2020 04:50:52 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <1164204b-750a-99c2-8abc-aa2aac00df15@oracle.com>
References: <1164204b-750a-99c2-8abc-aa2aac00df15@oracle.com>,
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
Message-ID: <OFEC7E9454.DA32A725-ON00258528.001A786B-00258528.001AA14C@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200311/f7f9d9e5/attachment.htm>

From Alan.Bateman at oracle.com  Wed Mar 11 07:17:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Mar 2020 07:17:46 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
References: <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com> <>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
Message-ID: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>

Vyom,

Are you planning to create a native test for this? I realize the fix you 
are discussing here isn't too interesting for >= JDK 13 but I think it 
could be useful to ensure that we have a test that signals threads in 
all of the blocking operations (connect might be tricky butt at least 
read, write, and accept).

-Alan

From vtewar26 at in.ibm.com  Wed Mar 11 08:09:02 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Wed, 11 Mar 2020 08:09:02 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>,
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <> <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
Message-ID: <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200311/763cee75/attachment-0001.htm>

From Alan.Bateman at oracle.com  Wed Mar 11 08:21:24 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Mar 2020 08:21:24 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com> <>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
Message-ID: <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>

On 11/03/2020 08:09, Vyom Tewari26 wrote:
> Hi Alan,
> Thanks for comment yes for? >=JDK13 we are using new socket impl which 
> does not have this problem, i am not planning to wright a test,? to 
> test this issue we need to get the native thread ID then we have to 
> interrupt the thread to see if JDK code is behaving as expected.
> I tested this issue at my local Linux env, what i did is modify the 
> java.lang.Thread.getId() to always return the *native thread id of 
> main thread* and use this native thread id in the test program to send 
> a signal(kill -SIGPIPE? threadid) and? i checked that JDK code is 
> behaving as expected.
> We can try to write a test case(which requires some native code as 
> well) which simulate the above but that will be lot of work.
> We can file a new issue to write a test which test 
> how(read,write,accept) operations behave when they are interrupted by 
> a signal.
> Alan, what do you think ?.
Native tests used to be hard but there is supporting infrastructure in 
the build for some time that makes it a lot easier. In this case, I 
think it should be possible to invoke a JNI method that returns the 
native thread id and then it can be signalled when the thread is blocked 
in accept (or read or write). So it shouldn't be too hard, it comes to 
whether anyone has time.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200311/6503a2f5/attachment.htm>

From ecki at zusammenkunft.net  Wed Mar 11 09:45:25 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 11 Mar 2020 09:45:25 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com> <>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>,
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
Message-ID: <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>

Hello,

Depending on the test environment you don't need much native tools. You can use java.io.File to open /proc/thread-self to get the TID and use ProcessBuilder to execute the kill command.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Alan Bateman <Alan.Bateman at oracle.com>
Gesendet: Wednesday, March 11, 2020 9:21:24 AM
An: Vyom Tewari26 <vtewar26 at in.ibm.com>
Cc: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Betreff: Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

On 11/03/2020 08:09, Vyom Tewari26 wrote:
Hi Alan,

Thanks for comment yes for  >=JDK13 we are using new socket impl which does not have this problem, i am not planning to wright a test,  to test this issue we need to get the native thread ID then we have to interrupt the thread to see if JDK code is behaving as expected.

I tested this issue at my local Linux env, what i did is modify the java.lang.Thread.getId() to always return the native thread id of main thread and use this native thread id in the test program to send a signal(kill -SIGPIPE  threadid) and  i checked that JDK code is behaving as expected.

We can try to write a test case(which requires some native code as well) which simulate the above but that will be lot of work.

We can file a new issue to write a test which test how(read,write,accept) operations behave when they are interrupted by a signal.

Alan, what do you think ?.
Native tests used to be hard but there is supporting infrastructure in the build for some time that makes it a lot easier. In this case, I think it should be possible to invoke a JNI method that returns the native thread id and then it can be signalled when the thread is blocked in accept (or read or write). So it shouldn't be too hard, it comes to whether anyone has time.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200311/3f7166b9/attachment.htm>

From daniel.fuchs at oracle.com  Wed Mar 11 10:58:09 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 11 Mar 2020 10:58:09 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
Message-ID: <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>

Hi Alan,

On 10/03/2020 19:59, Alan Bateman wrote:
> On 10/03/2020 18:32, Patrick Concannon wrote:
>>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02
>>
> Thanks for adding a test for getOption(SO_SNDBUF). That test 
> (testGetOption) should be checking that SO_SNDBUF is >= expected value  
> as it's okay for net.inet.udp.maxdgram to have a larger than what the 
> test expects.

+1

> testSend sends to the loopback address but I think we need this test to 
> send datagrams on the network (sending to the loopback is okay too but I 
> think you want this test to send a datagram on the network because we 
> want fragmentation on the network(.

Do we really? I am not sure we do.
We just want to verify that we don't get the "packet too large"
exception caused by the SO_SNDBUF buffer being too small.
In other words, we want to check that setting SO_SNDBUF was
effective and that it was really passed to the underlying
system stack and taken into account.
But maybe you have a different scenario in mind?

Using the loopback is also expedient because a machine that has IPv6
might not have an IPv6 external address configured, but it should have
an IPv6 loopback (::1) always. I assume we could loop over the network
interfaces and try to find one that has an IPv6 address configured which
is not the loopback - but that complicates the test. We can do it
if there's a strong reason to do it (we don't want to test that the
network itself actually supports ~64k datagrams, we just want to test
that we would be able to send them if it supported it?)

> The java.net.preferIPv6Addresses system property is about configuring 
> the order of name service lookup. These runs shouldn't impact anything 
> here, dual and preferIPv4Stack=true should be all that is needed.

Yes and no - and the test is there to verify that it doesn't have any
unexpected side effects (we know it shouldn't).

> A minor nit is that we should probably find a name for the test that is 
> consistent with the other tests in this area. Something like 
> LargeDatagram or MinSendBufferSize is okay.

+1

best regards,

-- daniel
> 
> -Alan


From Alan.Bateman at oracle.com  Wed Mar 11 12:08:35 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Mar 2020 12:08:35 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
Message-ID: <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>

On 11/03/2020 10:58, Daniel Fuchs wrote:
> :
>
>> testSend sends to the loopback address but I think we need this test 
>> to send datagrams on the network (sending to the loopback is okay too 
>> but I think you want this test to send a datagram on the network 
>> because we want fragmentation on the network(.
>
> Do we really? I am not sure we do.
> We just want to verify that we don't get the "packet too large"
> exception caused by the SO_SNDBUF buffer being too small.
It would be great if we had a test to send large datagrams on the 
network as that is the only way to properly test that they can be 
re-assembled and received. I don't mind if it's a separate test, I agree 
it can be tricky on systems that have unusual configurations. I'm just 
pointing out that testing that the send doesn't fail and that the 
datagram can be received through the loopback may not be enough here.

> :
>
>> The java.net.preferIPv6Addresses system property is about configuring 
>> the order of name service lookup. These runs shouldn't impact 
>> anything here, dual and preferIPv4Stack=true should be all that is 
>> needed.
>
> Yes and no - and the test is there to verify that it doesn't have any
> unexpected side effects (we know it shouldn't).
My preference would be to drop these so the test only runs twice. The 
reason is that the effect of setting java.net.preferIPv6Addresses is not 
widely known and it will confuse anyone that needs to maintain this test 
in the future.

-Alan

From daniel.fuchs at oracle.com  Wed Mar 11 12:27:44 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 11 Mar 2020 12:27:44 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
 <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
Message-ID: <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>

Hi Alan,

On 11/03/2020 12:08, Alan Bateman wrote:
>> Do we really? I am not sure we do.
>> We just want to verify that we don't get the "packet too large"
>> exception caused by the SO_SNDBUF buffer being too small.
> It would be great if we had a test to send large datagrams on the 
> network as that is the only way to properly test that they can be 
> re-assembled and received. I don't mind if it's a separate test, I agree 
> it can be tricky on systems that have unusual configurations. I'm just 
> pointing out that testing that the send doesn't fail and that the 
> datagram can be received through the loopback may not be enough here.
Our test doesn't even try to receive the datagram. It just sends it.
We can write a new test that does the full roundtrip if you think
it's worthwile.

>> Yes and no - and the test is there to verify that it doesn't have any
>> unexpected side effects (we know it shouldn't).
> My preference would be to drop these so the test only runs twice. The 
> reason is that the effect of setting java.net.preferIPv6Addresses is not 
> widely known and it will confuse anyone that needs to maintain this test 
> in the future.

OK - then we can remove the preferIPv6Addresses property and replace:

  114         populateDataProvider(testcases, datagramChannel, MAX_PAYLOAD,
  117                 null);

with

       if (hasIPv4())
           populateDataProvider(testcases, datagramChannel, IPV4_SNDBUF,
                      StandardProtocolFamily.INET);
       if (hasIPv6() && !preferIPv4Stack())
           populateDataProvider(testcases, datagramChannel, IPV6_SNDBUF,
                      StandardProtocolFamily.INET6);


to verify that the channel opened with the no-arg DatagramChannel.open()
can be used to send both IPv4 and IPv6 datagrams.

cheers,

-- daniel

From patrick.concannon at oracle.com  Wed Mar 11 16:54:15 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 11 Mar 2020 16:54:15 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
 <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
 <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>
Message-ID: <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>

Hi,

I've included those additional changes, and they can be found in the new 
webrev below.

http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/


Kind regards,

Patrick

On 11/03/2020 12:27, Daniel Fuchs wrote:
> Hi Alan,
>
> On 11/03/2020 12:08, Alan Bateman wrote:
>>> Do we really? I am not sure we do.
>>> We just want to verify that we don't get the "packet too large"
>>> exception caused by the SO_SNDBUF buffer being too small.
>> It would be great if we had a test to send large datagrams on the 
>> network as that is the only way to properly test that they can be 
>> re-assembled and received. I don't mind if it's a separate test, I 
>> agree it can be tricky on systems that have unusual configurations. 
>> I'm just pointing out that testing that the send doesn't fail and 
>> that the datagram can be received through the loopback may not be 
>> enough here.
> Our test doesn't even try to receive the datagram. It just sends it.
> We can write a new test that does the full roundtrip if you think
> it's worthwile.
>
>>> Yes and no - and the test is there to verify that it doesn't have any
>>> unexpected side effects (we know it shouldn't).
>> My preference would be to drop these so the test only runs twice. The 
>> reason is that the effect of setting java.net.preferIPv6Addresses is 
>> not widely known and it will confuse anyone that needs to maintain 
>> this test in the future.
>
> OK - then we can remove the preferIPv6Addresses property and replace:
>
> ?114???????? populateDataProvider(testcases, datagramChannel, 
> MAX_PAYLOAD,
> ?117???????????????? null);
>
> with
>
> ????? if (hasIPv4())
> ????????? populateDataProvider(testcases, datagramChannel, IPV4_SNDBUF,
> ???????????????????? StandardProtocolFamily.INET);
> ????? if (hasIPv6() && !preferIPv4Stack())
> ????????? populateDataProvider(testcases, datagramChannel, IPV6_SNDBUF,
> ???????????????????? StandardProtocolFamily.INET6);
>
>
> to verify that the channel opened with the no-arg DatagramChannel.open()
> can be used to send both IPv4 and IPv6 datagrams.
>
> cheers,
>
> -- daniel

From patrick.concannon at oracle.com  Wed Mar 11 17:42:27 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Wed, 11 Mar 2020 17:42:27 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
 <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
 <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>
 <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
Message-ID: <bc2c2071-d1ec-5e06-caea-f2aae20e43d6@oracle.com>

Regarding the test to check that large datagrams are sent and received 
correctly across a network:? I've created a new issue for it and 
included the link below.

https://bugs.openjdk.java.net/browse/JDK-8240901

Kind regards,

Patrick

On 11/03/2020 16:54, Patrick Concannon wrote:
> Hi,
>
> I've included those additional changes, and they can be found in the 
> new webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
>
>
> Kind regards,
>
> Patrick
>
> On 11/03/2020 12:27, Daniel Fuchs wrote:
>> Hi Alan,
>>
>> On 11/03/2020 12:08, Alan Bateman wrote:
>>>> Do we really? I am not sure we do.
>>>> We just want to verify that we don't get the "packet too large"
>>>> exception caused by the SO_SNDBUF buffer being too small.
>>> It would be great if we had a test to send large datagrams on the 
>>> network as that is the only way to properly test that they can be 
>>> re-assembled and received. I don't mind if it's a separate test, I 
>>> agree it can be tricky on systems that have unusual configurations. 
>>> I'm just pointing out that testing that the send doesn't fail and 
>>> that the datagram can be received through the loopback may not be 
>>> enough here.
>> Our test doesn't even try to receive the datagram. It just sends it.
>> We can write a new test that does the full roundtrip if you think
>> it's worthwile.
>>
>>>> Yes and no - and the test is there to verify that it doesn't have any
>>>> unexpected side effects (we know it shouldn't).
>>> My preference would be to drop these so the test only runs twice. 
>>> The reason is that the effect of setting 
>>> java.net.preferIPv6Addresses is not widely known and it will confuse 
>>> anyone that needs to maintain this test in the future.
>>
>> OK - then we can remove the preferIPv6Addresses property and replace:
>>
>> ?114???????? populateDataProvider(testcases, datagramChannel, 
>> MAX_PAYLOAD,
>> ?117???????????????? null);
>>
>> with
>>
>> ????? if (hasIPv4())
>> ????????? populateDataProvider(testcases, datagramChannel, IPV4_SNDBUF,
>> ???????????????????? StandardProtocolFamily.INET);
>> ????? if (hasIPv6() && !preferIPv4Stack())
>> ????????? populateDataProvider(testcases, datagramChannel, IPV6_SNDBUF,
>> ???????????????????? StandardProtocolFamily.INET6);
>>
>>
>> to verify that the channel opened with the no-arg DatagramChannel.open()
>> can be used to send both IPv4 and IPv6 datagrams.
>>
>> cheers,
>>
>> -- daniel

From Alan.Bateman at oracle.com  Wed Mar 11 19:31:48 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Mar 2020 19:31:48 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
 <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
 <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>
 <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
Message-ID: <3a275479-f591-7a0d-4262-0694e8c8908f@oracle.com>

On 11/03/2020 16:54, Patrick Concannon wrote:
> Hi,
>
> I've included those additional changes, and they can be found in the 
> new webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
Thanks for the update, looks good. I assume the updates to the IPSupport 
infra isn't needed but it might be needed some day so okay to include.

I see your mail with the link to JDK-8240901 to add tests that 
send/receive large datagrams so I think we're good.

-Alan.

From daniel.fuchs at oracle.com  Thu Mar 12 10:16:28 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Mar 2020 10:16:28 +0000
Subject: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow
 sending large datagrams (macOS)'
In-Reply-To: <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
References: <c3085ee6-e212-2679-bea7-948a5b9aa6a3@oracle.com>
 <0cccda31-79b7-6e97-c2e0-74d6977fa54a@oracle.com>
 <a9a23347-b0c4-7c3b-2db4-56fd4de1a84d@oracle.com>
 <1bff01b4-efe6-4fd5-1bdd-8a9faf60dcd4@oracle.com>
 <3b3522b0-cf33-bbb6-cb2b-dc7b05b0a23d@oracle.com>
 <12bce415-f3e8-7d5b-767f-924ddc9a9dc1@oracle.com>
 <63471911-c401-056e-ccb0-3e5388b92c43@oracle.com>
 <bd79c7da-f685-27f1-a445-95b14afc596a@oracle.com>
 <2a292763-b19c-71d3-2c0e-a6f6bf1d149b@oracle.com>
 <dd06716e-5905-959b-e93e-a9e7774a4cfe@oracle.com>
Message-ID: <af15f371-bb0d-0638-9a60-dc4015c7d1bd@oracle.com>

On 11/03/2020 16:54, Patrick Concannon wrote:
> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/

Looks good to me Patrick!

best regards,

-- daniel

From julia.boes at oracle.com  Thu Mar 12 10:23:24 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 12 Mar 2020 10:23:24 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
Message-ID: <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>

Thanks for the review, Chris.

After running further httpclient tests, I had to adjusted the exception 
handling of an existing test, RelayingPublishers.

I also added a check in FilePublisher::createInputStream to throw if the 
path is of a directory.

Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.02/

Thanks,

Julia


From daniel.fuchs at oracle.com  Thu Mar 12 10:52:37 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Mar 2020 10:52:37 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
Message-ID: <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>

Hi Julia,

I think we need to revisit the
    public static FilePublisher create(Path path)
a bit.

We should try to call Path::toFile first - whether there is a security
manager or not. In the case where that succeeds, we can use
new FileInputStream(), otherwise, we use Files.newInputStream.

It's unfortunate that new FileInputStream() and Files.newInputStream()
use different sets of exceptions, and that our public signature use
the exception thrown by the former.

Keeping using new FileInputStream() for the case where the Path::toFile
returns a file will ensure that we preserve backward compatibility
with existing code, but the current implementation of create() is
missing the case where there is no security manager and
Path::toFile doesn't throw.

If you fix that then no changes should be needed in RelayingPublishers.

best regards,

-- daniel

On 12/03/2020 10:23, Julia Boes wrote:
> Thanks for the review, Chris.
> 
> After running further httpclient tests, I had to adjusted the exception 
> handling of an existing test, RelayingPublishers.
> 
> I also added a check in FilePublisher::createInputStream to throw if the 
> path is of a directory.
> 
> Updated webrev: 
> http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.02/
> 
> Thanks,
> 
> Julia
> 


From xuelei.fan at oracle.com  Mon Mar 16 04:25:41 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sun, 15 Mar 2020 21:25:41 -0700
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
Message-ID: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>

Hi,

Could I get the following update reviewed?

Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/

In a preview review thread,
 
https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html

I requested to remove the deprecated javax.security.cert APIs in JDK 15. 
  Be part of the removal, the deprecated interface method 
javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved.

As SSLSession.getPeerCertificateChain() is an interface method, third 
party's implementation must override this method.  If it is removed, 
there are compiler errors unless the override implementation get removed 
in third party's source code.

Maybe, we could retire SSLSession.getPeerCertificateChain() first, and 
then come back to remove the deprecated javax.security.cert package in a 
few years.

In this update, I'm trying to change 
SSLSession.getPeerCertificateChain() to default method , throwing 
exception in the default implementation, and removing the real 
implementation in the SunJSSE provider and related code (Httpclient).

Thanks,
Xuelei

From Alan.Bateman at oracle.com  Mon Mar 16 07:36:38 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Mar 2020 07:36:38 +0000
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
Message-ID: <cb6ee604-8e46-5846-8bfe-bed1d1f08130@oracle.com>

On 16/03/2020 04:25, Xuelei Fan wrote:
> Hi,
>
> Could I get the following update reviewed?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
>
I see you've created a new issue (and sub-tasks), in which JDK-8227024, 
CSR and other tasks need to be closed to avoid any confusion.

SSLSession - the method is already terminally deprecated so there is a 
big note in the javadoc. No need to duplicate the text in an @implNote. 
For @implSpec then I think you want "The default method throws ....".

HandshakeCompletedEvent - you can drop the @implNote here too. Catching 
UOE and then re-throwing it with the UOE from SSLSession as the cause is 
confusing. I think you can leave the implementation as-is.

-Alan.

From daniel.fuchs at oracle.com  Mon Mar 16 10:37:19 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 16 Mar 2020 10:37:19 +0000
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
Message-ID: <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com>

Hi Xuelei,

HandshakeCompletedEvent.java: typo:

  186                 "This method has retired, pleaase use the " +

Same in SSLSession.java:

  303             "This method has retired, pleaase use the " +

WRT to the HttpClient code I wonder whether the deprecated method
should be kept. On the one hand I'd welcome the removal of
the implemenatation of terminally deprecated methods.
On the other hand the two classes in HttpClient implement simple
delegation over an SSLSession object. Unless we can guarantee that
this object is our own implementation, maybe the delegation should
be kept - and the throwing of UnsupportedOperationException left
up to the delegate object?

I am not sure what's the best course here.

best regards

-- daniel


On 16/03/2020 04:25, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
> 
> In a preview review thread,
> 
> https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html
> 
> I requested to remove the deprecated javax.security.cert APIs in JDK 15. 
>  ?Be part of the removal, the deprecated interface method 
> javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved.
> 
> As SSLSession.getPeerCertificateChain() is an interface method, third 
> party's implementation must override this method.? If it is removed, 
> there are compiler errors unless the override implementation get removed 
> in third party's source code.
> 
> Maybe, we could retire SSLSession.getPeerCertificateChain() first, and 
> then come back to remove the deprecated javax.security.cert package in a 
> few years.
> 
> In this update, I'm trying to change 
> SSLSession.getPeerCertificateChain() to default method , throwing 
> exception in the default implementation, and removing the real 
> implementation in the SunJSSE provider and related code (Httpclient).
> 
> Thanks,
> Xuelei


From michael.x.mcmahon at oracle.com  Mon Mar 16 12:39:03 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 16 Mar 2020 12:39:03 +0000
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
Message-ID: <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>

Hi Alex,

(and redirecting the thread to net-dev)

It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior 
rather than the spec.

But, more important I think is the behavior change of the fix itself and 
that will require
careful review which we can't commit to immediately. We will try and get 
back to you
about it in a week or so.

Thanks,

Michael.

On 14/03/2020 00:08, Alex Kashchenko wrote:
> Hi,
>
> Based on these maillist threads:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html 
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html 
>
>
> I am looking for comments and suggestions, whether the following 
> change to JarURLConnection.getJarFile() behaviour may be acceptable:
>
> If, during connect() call, jarFile itself was created successfully, 
> but access to (non-existent) jarEntry failed - return this jarFile to 
> caller instead of throwing exception.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
>
> This change also allows to fix JDK-8232854 with the minimal change to 
> URLClassPath (included with the patch).
>
> This change doesn't cause regression failures in java/net.
>
> This change causes one compatibility failure, when getManifest() 
> doesn't throw expected IOException when URL points to non-existent 
> class inside JAR.
>

From xuelei.fan at oracle.com  Mon Mar 16 16:00:48 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 16 Mar 2020 09:00:48 -0700
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <cb6ee604-8e46-5846-8bfe-bed1d1f08130@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
 <cb6ee604-8e46-5846-8bfe-bed1d1f08130@oracle.com>
Message-ID: <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com>

Hi Alan,

Thanks for the review.  All comments look good to me.  Here is the 
update webrev:
   http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/

HandshakeCompletedEvent.java and SSLSession.java are updated.

Thanks,
Xuelei

On 3/16/2020 12:36 AM, Alan Bateman wrote:
> On 16/03/2020 04:25, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
>> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
>>
> I see you've created a new issue (and sub-tasks), in which JDK-8227024, 
> CSR and other tasks need to be closed to avoid any confusion.
> 
> SSLSession - the method is already terminally deprecated so there is a 
> big note in the javadoc. No need to duplicate the text in an @implNote. 
> For @implSpec then I think you want "The default method throws ....".
> 
> HandshakeCompletedEvent - you can drop the @implNote here too. Catching 
> UOE and then re-throwing it with the UOE from SSLSession as the cause is 
> confusing. I think you can leave the implementation as-is.
> > -Alan.

From xuelei.fan at oracle.com  Mon Mar 16 16:31:12 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 16 Mar 2020 09:31:12 -0700
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
 <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com>
Message-ID: <798b2114-3b75-d95e-169b-fb7f6de1381e@oracle.com>

On 3/16/2020 3:37 AM, Daniel Fuchs wrote:
> Hi Xuelei,
> 
> HandshakeCompletedEvent.java: typo:
> 
>  ?186???????????????? "This method has retired, pleaase use the " +
> 
> Same in SSLSession.java:
> 
>  ?303???????????? "This method has retired, pleaase use the " +
> 
I removed the sections per Alan's comment.

> WRT to the HttpClient code I wonder whether the deprecated method
> should be kept. On the one hand I'd welcome the removal of
> the implemenatation of terminally deprecated methods.
> On the other hand the two classes in HttpClient implement simple
> delegation over an SSLSession object. Unless we can guarantee that
> this object is our own implementation, maybe the delegation should
> be kept - and the throwing of UnsupportedOperationException left
> up to the delegate object?
> 
> I am not sure what's the best course here.
> 
There are compiler error if SSLSession.getPeerCertificateChain() get 
removed, while the implementation override it.  As one of the goals, the 
implementation, especially third party provider that is intended to 
support multiple releases, should remove override implementation as soon 
as possible, without waiting for the removal of the 
SSLSession.getPeerCertificateChain() method.  Otherwise, there are still 
compiler error when we want to remove this interface method in the future.

It should be fine to keep the HttpClient implementation as it only ship 
with the current JDK release.  But if you don't mind, I would like to 
remove it to show an example about how to handle with the method in 
third party's source code.


Thanks,
Xuelei

> best regards
> 
> -- daniel
> 
> 
> On 16/03/2020 04:25, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
>> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
>>
>> In a preview review thread,
>>
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html 
>>
>>
>> I requested to remove the deprecated javax.security.cert APIs in JDK 
>> 15. ??Be part of the removal, the deprecated interface method 
>> javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved.
>>
>> As SSLSession.getPeerCertificateChain() is an interface method, third 
>> party's implementation must override this method.? If it is removed, 
>> there are compiler errors unless the override implementation get 
>> removed in third party's source code.
>>
>> Maybe, we could retire SSLSession.getPeerCertificateChain() first, and 
>> then come back to remove the deprecated javax.security.cert package in 
>> a few years.
>>
>> In this update, I'm trying to change 
>> SSLSession.getPeerCertificateChain() to default method , throwing 
>> exception in the default implementation, and removing the real 
>> implementation in the SunJSSE provider and related code (Httpclient).
>>
>> Thanks,
>> Xuelei
> 

From Alan.Bateman at oracle.com  Mon Mar 16 17:23:36 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Mar 2020 17:23:36 +0000
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
 <cb6ee604-8e46-5846-8bfe-bed1d1f08130@oracle.com>
 <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com>
Message-ID: <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com>



On 16/03/2020 16:00, Xuelei Fan wrote:
> Hi Alan,
>
> Thanks for the review.? All comments look good to me.? Here is the 
> update webrev:
> ? http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/
>
> HandshakeCompletedEvent.java and SSLSession.java are updated.
Thanks.? One suggestion is to use "The default implementation ..." 
rather than "This default method ..." in the @implSpec (no need for a 
new webrev).

-Alan.

From xuelei.fan at oracle.com  Mon Mar 16 17:30:28 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 16 Mar 2020 10:30:28 -0700
Subject: RFR JDK-8241039, Retire the deprecated
 SSLSession.getPeerCertificateChain() method
In-Reply-To: <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com>
References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com>
 <cb6ee604-8e46-5846-8bfe-bed1d1f08130@oracle.com>
 <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com>
 <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com>
Message-ID: <31d2e58b-739a-6a69-b376-69287a3f3acd@oracle.com>

I updated the CSR and local code.

Thanks,
Xuelei

On 3/16/2020 10:23 AM, Alan Bateman wrote:
> 
> 
> On 16/03/2020 16:00, Xuelei Fan wrote:
>> Hi Alan,
>>
>> Thanks for the review.? All comments look good to me.? Here is the 
>> update webrev:
>> ? http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/
>>
>> HandshakeCompletedEvent.java and SSLSession.java are updated.
> Thanks.? One suggestion is to use "The default implementation ..." 
> rather than "This default method ..." in the @implSpec (no need for a 
> new webrev).
> 
> -Alan.

From vyommani at gmail.com  Tue Mar 17 05:21:46 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Tue, 17 Mar 2020 10:51:46 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
Message-ID: <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>

Hi Daniel/Michael,

Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html), where i
put a test case as well.
Thanks,
Vyom

On Wed, Mar 11, 2020 at 3:16 PM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> Hello,
>
> Depending on the test environment you don't need much native tools. You
> can use java.io.File to open /proc/thread-self to get the TID and use
> ProcessBuilder to execute the kill command.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ------------------------------
> *Von:* net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Alan
> Bateman <Alan.Bateman at oracle.com>
> *Gesendet:* Wednesday, March 11, 2020 9:21:24 AM
> *An:* Vyom Tewari26 <vtewar26 at in.ibm.com>
> *Cc:* net-dev at openjdk.java.net <net-dev at openjdk.java.net>
> *Betreff:* Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
> incorrectly
>
> On 11/03/2020 08:09, Vyom Tewari26 wrote:
>
> Hi Alan,
>
> Thanks for comment yes for  >=JDK13 we are using new socket impl which
> does not have this problem, i am not planning to wright a test,  to test
> this issue we need to get the native thread ID then we have to interrupt
> the thread to see if JDK code is behaving as expected.
>
> I tested this issue at my local Linux env, what i did is modify the
> java.lang.Thread.getId() to always return the *native thread id of main
> thread* and use this native thread id in the test program to send a
> signal(kill -SIGPIPE  threadid) and  i checked that JDK code is behaving as
> expected.
>
> We can try to write a test case(which requires some native code as well)
> which simulate the above but that will be lot of work.
>
> We can file a new issue to write a test which test how(read,write,accept)
> operations behave when they are interrupted by a signal.
>
> Alan, what do you think ?.
>
> Native tests used to be hard but there is supporting infrastructure in the
> build for some time that makes it a lot easier. In this case, I think it
> should be possible to invoke a JNI method that returns the native thread id
> and then it can be signalled when the thread is blocked in accept (or read
> or write). So it shouldn't be too hard, it comes to whether anyone has time.
>
> -Alan.
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200317/5ac1a80e/attachment-0001.htm>

From Alan.Bateman at oracle.com  Tue Mar 17 07:03:26 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Mar 2020 07:03:26 +0000
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
Message-ID: <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>



On 17/03/2020 05:21, Vyom Tiwari wrote:
> Hi Daniel/Michael,
>
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html), 
> where i put a test case as well.
>
Can you look at make/test/JtregNativeJdk.gmk? That should give you ideas 
on how to develop tests that use JNI code. You should just need two 
native methods, one to call pthread_self, the other call pthread_kill. 
It could potentially use sun.nio.ch.NativeThread but we'll see how far 
you get first. Once you have the primitives it should be easy to create 
a test that signals a thread blocked in read, write or accept.

-Alan

From vipinmv1 at in.ibm.com  Tue Mar 17 08:52:46 2020
From: vipinmv1 at in.ibm.com (Vipin Mv1)
Date: Tue, 17 Mar 2020 08:52:46 +0000
Subject: Fw:  RE: RFR 8129841 Update comment for
 Java_java_net_Inet6AddressImpl_getHostByAddr
Message-ID: <OFD51FCC5D.E06F9C97-ON0025852E.0030C6EB-0025852E.0030C6F1@notes.na.collabserv.com>


A gentle reminder to please review this patch.

Thanks & Regards						 			
Vipin MV					 			
				 			
 						

-----Forwarded by Vipin Mv1/India/IBM on 03/17/2020 02:21PM -----
To: Vipin Mv1 <vipinmv1 at in.ibm.com>, "net-dev at openjdk.java.net" <net-dev at openjdk.java.net>
From: "Langer, Christoph" <christoph.langer at sap.com>
Date: 03/04/2020 05:42PM
Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
Subject: [EXTERNAL] RE: RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr

Hi Vipin,

I'm forwarding this to net-dev where it should be reviewed.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Vipin Mv1
> Sent: Dienstag, 3. M?rz 2020 11:54
> To: core-libs-dev at openjdk.java.net
> Subject: RFR 8129841 Update comment for
> Java_java_net_Inet6AddressImpl_getHostByAddr
> 
> Hi All,
> 
> Please find the below changes for the issue
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8129841&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=YGcJOWSLdBGnjzzUPMOeoQB-1IAycTyy6T7cx_ZtPhM&m=kL_iJ_cygw6-ev3RGouGahhDfztLviWgqhWWmAmTaM0&s=b2qt4d4_i0MSndQgGzyANvzawwhvNAyLkqg9uOFS_y0&e= . Apart from the
> requested changes, I have made additional changes to the Signature where
> ever I found it incorrect.
> 
> 
> Thanks
> Vipin M V
> 
> 
> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c
> --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Wed Feb 05
> 12:20:36 2020 -0300
> +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Tue Mar 03
> 15:32:21 2020 +0530
> @@ -218,7 +218,7 @@
>  /*
>   * Class:     java_net_Inet4AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c
> --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Wed Feb 05
> 12:20:36 2020 -0300
> +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Tue Mar 03
> 15:32:21 2020 +0530
> @@ -413,7 +413,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> @@ -668,7 +668,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    isReachable0
> - * Signature: ([bII[bI)Z
> + * Signature: ([BII[BII)Z
>   */
>  JNIEXPORT jboolean JNICALL
>  Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
> diff -r 387369ff21a4
> src/java.base/windows/native/libnet/Inet4AddressImpl.c
> --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Wed
> Feb 05 12:20:36 2020 -0300
> +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Tue
> Mar 03 15:32:21 2020 +0530
> @@ -171,7 +171,7 @@
>  /*
>   * Class:     java_net_Inet4AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> diff -r 387369ff21a4
> src/java.base/windows/native/libnet/Inet6AddressImpl.c
> --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Wed
> Feb 05 12:20:36 2020 -0300
> +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Tue
> Mar 03 15:32:21 2020 +0530
> @@ -240,7 +240,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    getHostByAddr
> - * Signature: (I)Ljava/lang/String;
> + * Signature: ([B)Ljava/lang/String;
>   *
>   * Theoretically the UnknownHostException could be enriched with gai error
>   * information. But as it is silently ignored anyway, there's no need for this.
> @@ -435,7 +435,7 @@
>  /*
>   * Class:     java_net_Inet6AddressImpl
>   * Method:    isReachable0
> - * Signature: ([bII[bI)Z
> + * Signature: ([BII[BII)Z
>   */
>  JNIEXPORT jboolean JNICALL
>  Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
> 
> 



From Alan.Bateman at oracle.com  Tue Mar 17 09:02:23 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Mar 2020 09:02:23 +0000
Subject: Fw: RE: RFR 8129841 Update comment for
 Java_java_net_Inet6AddressImpl_getHostByAddr
In-Reply-To: <OFD51FCC5D.E06F9C97-ON0025852E.0030C6EB-0025852E.0030C6F1@notes.na.collabserv.com>
References: <OFD51FCC5D.E06F9C97-ON0025852E.0030C6EB-0025852E.0030C6F1@notes.na.collabserv.com>
Message-ID: <cd248292-9d56-be92-3a18-ec2b3876f79c@oracle.com>

Looks okay and matches the sigs in the generated header files.

-Alan

On 17/03/2020 08:52, Vipin Mv1 wrote:
> A gentle reminder to please review this patch.
>
> Thanks & Regards						 			
> Vipin MV					 			
> 				 			
>   						
>
> -----Forwarded by Vipin Mv1/India/IBM on 03/17/2020 02:21PM -----
> To: Vipin Mv1 <vipinmv1 at in.ibm.com>, "net-dev at openjdk.java.net" <net-dev at openjdk.java.net>
> From: "Langer, Christoph" <christoph.langer at sap.com>
> Date: 03/04/2020 05:42PM
> Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: [EXTERNAL] RE: RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr
>
> Hi Vipin,
>
> I'm forwarding this to net-dev where it should be reviewed.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>> Of Vipin Mv1
>> Sent: Dienstag, 3. M?rz 2020 11:54
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR 8129841 Update comment for
>> Java_java_net_Inet6AddressImpl_getHostByAddr
>>
>> Hi All,
>>
>> Please find the below changes for the issue
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8129841&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=YGcJOWSLdBGnjzzUPMOeoQB-1IAycTyy6T7cx_ZtPhM&m=kL_iJ_cygw6-ev3RGouGahhDfztLviWgqhWWmAmTaM0&s=b2qt4d4_i0MSndQgGzyANvzawwhvNAyLkqg9uOFS_y0&e= . Apart from the
>> requested changes, I have made additional changes to the Signature where
>> ever I found it incorrect.
>>
>>
>> Thanks
>> Vipin M V
>>
>>
>> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c
>> --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Wed Feb 05
>> 12:20:36 2020 -0300
>> +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c	Tue Mar 03
>> 15:32:21 2020 +0530
>> @@ -218,7 +218,7 @@
>>   /*
>>    * Class:     java_net_Inet4AddressImpl
>>    * Method:    getHostByAddr
>> - * Signature: (I)Ljava/lang/String;
>> + * Signature: ([B)Ljava/lang/String;
>>    *
>>    * Theoretically the UnknownHostException could be enriched with gai error
>>    * information. But as it is silently ignored anyway, there's no need for this.
>> diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c
>> --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Wed Feb 05
>> 12:20:36 2020 -0300
>> +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c	Tue Mar 03
>> 15:32:21 2020 +0530
>> @@ -413,7 +413,7 @@
>>   /*
>>    * Class:     java_net_Inet6AddressImpl
>>    * Method:    getHostByAddr
>> - * Signature: (I)Ljava/lang/String;
>> + * Signature: ([B)Ljava/lang/String;
>>    *
>>    * Theoretically the UnknownHostException could be enriched with gai error
>>    * information. But as it is silently ignored anyway, there's no need for this.
>> @@ -668,7 +668,7 @@
>>   /*
>>    * Class:     java_net_Inet6AddressImpl
>>    * Method:    isReachable0
>> - * Signature: ([bII[bI)Z
>> + * Signature: ([BII[BII)Z
>>    */
>>   JNIEXPORT jboolean JNICALL
>>   Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
>> diff -r 387369ff21a4
>> src/java.base/windows/native/libnet/Inet4AddressImpl.c
>> --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Wed
>> Feb 05 12:20:36 2020 -0300
>> +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c	Tue
>> Mar 03 15:32:21 2020 +0530
>> @@ -171,7 +171,7 @@
>>   /*
>>    * Class:     java_net_Inet4AddressImpl
>>    * Method:    getHostByAddr
>> - * Signature: (I)Ljava/lang/String;
>> + * Signature: ([B)Ljava/lang/String;
>>    *
>>    * Theoretically the UnknownHostException could be enriched with gai error
>>    * information. But as it is silently ignored anyway, there's no need for this.
>> diff -r 387369ff21a4
>> src/java.base/windows/native/libnet/Inet6AddressImpl.c
>> --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Wed
>> Feb 05 12:20:36 2020 -0300
>> +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c	Tue
>> Mar 03 15:32:21 2020 +0530
>> @@ -240,7 +240,7 @@
>>   /*
>>    * Class:     java_net_Inet6AddressImpl
>>    * Method:    getHostByAddr
>> - * Signature: (I)Ljava/lang/String;
>> + * Signature: ([B)Ljava/lang/String;
>>    *
>>    * Theoretically the UnknownHostException could be enriched with gai error
>>    * information. But as it is silently ignored anyway, there's no need for this.
>> @@ -435,7 +435,7 @@
>>   /*
>>    * Class:     java_net_Inet6AddressImpl
>>    * Method:    isReachable0
>> - * Signature: ([bII[bI)Z
>> + * Signature: ([BII[BII)Z
>>    */
>>   JNIEXPORT jboolean JNICALL
>>   Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
>>
>>
>


From vtewar26 at in.ibm.com  Tue Mar 17 10:02:52 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Tue, 17 Mar 2020 10:02:52 +0000
Subject: Fw: RE: RFR 8129841 Update comment for
 Java_java_net_Inet6AddressImpl_getHostByAddr
In-Reply-To: <cd248292-9d56-be92-3a18-ec2b3876f79c@oracle.com>
References: <cd248292-9d56-be92-3a18-ec2b3876f79c@oracle.com>,
 <OFD51FCC5D.E06F9C97-ON0025852E.0030C6EB-0025852E.0030C6F1@notes.na.collabserv.com>
Message-ID: <OF6DF8BF06.F12E80AB-ON0025852E.0036FB05-0025852E.003731CE@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200317/c2794739/attachment-0001.htm>

From jai.forums2013 at gmail.com  Wed Mar 18 11:18:40 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 18 Mar 2020 16:48:40 +0530
Subject: RFR: JDK-8241138: http.nonProxyHosts=* causes
 StringIndexOutOfBoundsException in DefaultProxySelector
Message-ID: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>

Can I please get a review and a sponsor for a patch which fixes the
issue reported in JDK-8241138[1]?

The patch is hosted as a webrev at [2]. The change in the patch now adds
an explicit equals check for "*" before checking it for various other
possible patterns. The patch also updates an existing testcase to
include test for this specific scenario.


[1] https://bugs.openjdk.java.net/browse/JDK-8241138

[2] https://cr.openjdk.java.net/~jpai/webrev/8241138/1/webrev/

-Jaikiran


From daniel.fuchs at oracle.com  Wed Mar 18 12:03:29 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Mar 2020 12:03:29 +0000
Subject: RFR: JDK-8241138: http.nonProxyHosts=* causes
 StringIndexOutOfBoundsException in DefaultProxySelector
In-Reply-To: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>
References: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>
Message-ID: <7131f085-57e1-60bb-8b26-76870e7a433d@oracle.com>

Hi Jaikiran,

This looks reasonable to me.
I will happily sponsor it - unless there are other takers.

best regards,

-- daniel

On 18/03/2020 11:18, Jaikiran Pai wrote:
> Can I please get a review and a sponsor for a patch which fixes the
> issue reported in JDK-8241138[1]?
> 
> The patch is hosted as a webrev at [2]. The change in the patch now adds
> an explicit equals check for "*" before checking it for various other
> possible patterns. The patch also updates an existing testcase to
> include test for this specific scenario.
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8241138
> 
> [2] https://cr.openjdk.java.net/~jpai/webrev/8241138/1/webrev/
> 
> -Jaikiran
> 


From chris.hegarty at oracle.com  Wed Mar 18 12:23:55 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 18 Mar 2020 12:23:55 +0000
Subject: RFR: JDK-8241138: http.nonProxyHosts=* causes
 StringIndexOutOfBoundsException in DefaultProxySelector
In-Reply-To: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>
References: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>
Message-ID: <799489E3-13B5-4045-AD9A-281DFC783523@oracle.com>


> On 18 Mar 2020, at 11:18, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> ...
> 
> [2] https://cr.openjdk.java.net/~jpai/webrev/8241138/1/webrev/

LGTM.

-Chris.


From jai.forums2013 at gmail.com  Thu Mar 19 01:31:43 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 19 Mar 2020 07:01:43 +0530
Subject: RFR: JDK-8241138: http.nonProxyHosts=* causes
 StringIndexOutOfBoundsException in DefaultProxySelector
In-Reply-To: <7131f085-57e1-60bb-8b26-76870e7a433d@oracle.com>
References: <c0d52584-0341-95c7-ecdb-3f2fdd95f49f@gmail.com>
 <7131f085-57e1-60bb-8b26-76870e7a433d@oracle.com>
Message-ID: <5cf16379-823d-dc23-9347-8fd93e768edd@gmail.com>

Thank you Chris and Daniel for the reviews and the sponsoring.

-Jaikiran

On 18/03/20 5:33 pm, Daniel Fuchs wrote:
> Hi Jaikiran,
>
> This looks reasonable to me.
> I will happily sponsor it - unless there are other takers.
>
> best regards,
>
> -- daniel
>
> On 18/03/2020 11:18, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for a patch which fixes the
>> issue reported in JDK-8241138[1]?
>>
>> The patch is hosted as a webrev at [2]. The change in the patch now adds
>> an explicit equals check for "*" before checking it for various other
>> possible patterns. The patch also updates an existing testcase to
>> include test for this specific scenario.
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8241138
>>
>> [2] https://cr.openjdk.java.net/~jpai/webrev/8241138/1/webrev/
>>
>> -Jaikiran
>>
>

From rahul.r.yadav at oracle.com  Thu Mar 19 10:18:40 2020
From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com)
Date: Thu, 19 Mar 2020 10:18:40 +0000
Subject: RFR JDK-8240921: Minor correction to HttpResponse.BodySubscribers
 example
Message-ID: <ddcbda2e-64e4-f406-26eb-917babae8332@oracle.com>

Hello,

 ?Can I please have my fix reviewed for issue JDK-8240921 - Minor 
correction to HttpResponse.BodySubscribers example?

 ?The fix updates the incorrect example of the usage of the class 
java.net.http.HttpResponse.BodySubscribers.The patch also updates the 
test case for this scenario.

 ?Issue: https://bugs.openjdk.java.net/browse/JDK-8240921

 ?Webrev: 
http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrev/webrev.00,

- Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200319/a7da0524/attachment.htm>

From rahul.r.yadav at oracle.com  Thu Mar 19 10:20:36 2020
From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com)
Date: Thu, 19 Mar 2020 10:20:36 +0000
Subject: RFR JDK-8240921: Minor correction to HttpResponse.BodySubscribers
 example
Message-ID: <4f384879-ca44-4705-41d2-18e602a5509d@oracle.com>

Hello,

 ?Can I please have my fix reviewed for issue JDK-8240921 - Minor 
correction to HttpResponse.BodySubscribers example?

 ?The fix updates the incorrect example of the usage of the class 
java.net.http.HttpResponse.BodySubscribers.The patch also updates the 
test case for this scenario.

 ?Issue: https://bugs.openjdk.java.net/browse/JDK-8240921

 ?Webrev: 
http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrev/webrev.00 
<http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrev/webrev.00,>

- Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200319/6ba646c9/attachment.htm>

From rahul.r.yadav at oracle.com  Thu Mar 19 10:29:51 2020
From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com)
Date: Thu, 19 Mar 2020 10:29:51 +0000
Subject: <Updated> RFR JDK-8240921: Minor correction to
 HttpResponse.BodySubscribers example
Message-ID: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>

Hello,

 ?Can I please have my fix reviewed for issue JDK-8240921 - Minor 
correction to HttpResponse.BodySubscribers example?

 ?The fix updates the incorrect example of the usage of the class 
java.net.http.HttpResponse.BodySubscribers.The patch also updates the 
test case for this scenario.

 ?Issue: https://bugs.openjdk.java.net/browse/JDK-8240921

 ?Webrev: 
http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrevs/webrev.00/

- Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200319/603d5038/attachment-0001.htm>

From julia.boes at oracle.com  Thu Mar 19 11:30:03 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 19 Mar 2020 11:30:03 +0000
Subject: <Updated> RFR JDK-8240921: Minor correction to
 HttpResponse.BodySubscribers example
In-Reply-To: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
References: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
Message-ID: <8c18d99f-439e-f798-7547-03a3860ad82d@oracle.com>

Hi Rahul,

The fix looks good to me.

Cheers,

Julia


From chris.hegarty at oracle.com  Thu Mar 19 11:33:42 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Mar 2020 11:33:42 +0000
Subject: <Updated> RFR JDK-8240921: Minor correction to
 HttpResponse.BodySubscribers example
In-Reply-To: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
References: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
Message-ID: <58C87ACC-A168-46A0-9689-BEF108C19485@oracle.com>

Rahul,

> On 19 Mar 2020, at 10:29, rahul.r.yadav at oracle.com wrote:
> 
> Hello, 
> 
>  Can I please have my fix reviewed for issue JDK-8240921 - Minor correction to HttpResponse.BodySubscribers example?
> 
>  The fix updates the incorrect example of the usage of the class java.net.http.HttpResponse.BodySubscribers.The patch also updates the test case for this scenario.
> 
>  Issue:  https://bugs.openjdk.java.net/browse/JDK-8240921 <https://bugs.openjdk.java.net/browse/JDK-8240921>
> 
>  Webrev: http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrevs/webrev.00/>
> 

LGTM.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200319/7d388ca3/attachment.htm>

From daniel.fuchs at oracle.com  Thu Mar 19 11:41:21 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Mar 2020 11:41:21 +0000
Subject: <Updated> RFR JDK-8240921: Minor correction to
 HttpResponse.BodySubscribers example
In-Reply-To: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
References: <17c28cc4-9a88-ef65-0437-63e310764de1@oracle.com>
Message-ID: <97ab7265-648a-c413-9fbd-ec419bddb321@oracle.com>

Hi Rahul,

This looks good to me.
Thanks for fixing it!

best regards,

-- daniel

On 19/03/2020 10:29, rahul.r.yadav at oracle.com wrote:
> Hello,
> 
>  ?Can I please have my fix reviewed for issue JDK-8240921 - Minor 
> correction to HttpResponse.BodySubscribers example?
> 
>  ?The fix updates the incorrect example of the usage of the class 
> java.net.http.HttpResponse.BodySubscribers.The patch also updates the 
> test case for this scenario.
> 
>  ?Issue: https://bugs.openjdk.java.net/browse/JDK-8240921
> 
>  ?Webrev: 
> http://cr.openjdk.java.net/~pconcannon/rayayada/8240921/webrevs/webrev.00/
> 
> - Rahul


From ivan.gerasimov at oracle.com  Fri Mar 20 07:19:40 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 20 Mar 2020 00:19:40 -0700
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
Message-ID: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>

Hello!

An OOM error is intermittently observed on MacOS when joining a 
multicast group.

A workaround was implemented as part of the fix for JDK-8236925.

It is proposed to backport a portion of that fix, which helps to 
mitigate the issue on MacOS.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044365
WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/

Mach5 control build in progress.

-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Fri Mar 20 08:08:43 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2020 08:08:43 +0000
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
In-Reply-To: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
References: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
Message-ID: <cbe0cf25-c297-0ff1-6bb0-bcb86aa218e9@oracle.com>

On 20/03/2020 07:19, Ivan Gerasimov wrote:
> Hello!
>
> An OOM error is intermittently observed on MacOS when joining a 
> multicast group.
>
> A workaround was implemented as part of the fix for JDK-8236925.
>
> It is proposed to backport a portion of that fix, which helps to 
> mitigate the issue on MacOS.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044365
> WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/
This looks okay to me. We need to get a bug submitted to Apple on this.

-Alan

From vyommani at gmail.com  Fri Mar 20 10:33:28 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 20 Mar 2020 16:03:28 +0530
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
In-Reply-To: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
References: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
Message-ID: <CAKysZ8ztrTfaDEDbUK0xk73JPqRW0Q=6TE+5pCJZAF7GfjO56A@mail.gmail.com>

Looks good to me.
Vyom

On Fri, Mar 20, 2020 at 12:49 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> An OOM error is intermittently observed on MacOS when joining a
> multicast group.
>
> A workaround was implemented as part of the fix for JDK-8236925.
>
> It is proposed to backport a portion of that fix, which helps to
> mitigate the issue on MacOS.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044365
> WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/
>
> Mach5 control build in progress.
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200320/f189e9aa/attachment.htm>

From daniel.fuchs at oracle.com  Fri Mar 20 12:22:25 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Mar 2020 12:22:25 +0000
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
In-Reply-To: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
References: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
Message-ID: <c3c62db8-dd17-64da-e4a7-f74ce85689c1@oracle.com>

Hi Ivan,

Looks good to me. I wonder if you should add
@bug 8044365
to the MulticastSendReceiveTests.java while you're at it.

best regards,

-- daniel

On 20/03/2020 07:19, Ivan Gerasimov wrote:
> Hello!
> 
> An OOM error is intermittently observed on MacOS when joining a 
> multicast group.
> 
> A workaround was implemented as part of the fix for JDK-8236925.
> 
> It is proposed to backport a portion of that fix, which helps to 
> mitigate the issue on MacOS.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044365
> WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/
> 
> Mach5 control build in progress.
> 


From Alan.Bateman at oracle.com  Fri Mar 20 12:39:06 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2020 12:39:06 +0000
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
In-Reply-To: <c3c62db8-dd17-64da-e4a7-f74ce85689c1@oracle.com>
References: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
 <c3c62db8-dd17-64da-e4a7-f74ce85689c1@oracle.com>
Message-ID: <a6e399f2-8096-15df-7262-b9779fc9ede4@oracle.com>

On 20/03/2020 12:22, Daniel Fuchs wrote:
> Hi Ivan,
>
> Looks good to me. I wonder if you should add
> @bug 8044365
> to the MulticastSendReceiveTests.java while you're at it.
Every test that joins a multicast has the potential of hitting this, 
it's very random, so probably not useful to put it on this specific 
test. I think we need to put time into writing a native reproducer for 
Apple and get a bug submitted.

-Alan

From ivan.gerasimov at oracle.com  Sat Mar 21 02:55:33 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 20 Mar 2020 19:55:33 -0700
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
In-Reply-To: <a6e399f2-8096-15df-7262-b9779fc9ede4@oracle.com>
References: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>
 <c3c62db8-dd17-64da-e4a7-f74ce85689c1@oracle.com>
 <a6e399f2-8096-15df-7262-b9779fc9ede4@oracle.com>
Message-ID: <4f59e911-58d7-1587-f733-83ede1649b0f@oracle.com>

Thanks everyone for reviewing!

On 3/20/20 5:39 AM, Alan Bateman wrote:
> On 20/03/2020 12:22, Daniel Fuchs wrote:
>> Hi Ivan,
>>
>> Looks good to me. I wonder if you should add
>> @bug 8044365
>> to the MulticastSendReceiveTests.java while you're at it.
> Every test that joins a multicast has the potential of hitting this, 
> it's very random, so probably not useful to put it on this specific 
> test. I think we need to put time into writing a native reproducer for 
> Apple and get a bug submitted.


Right.? The fix is not relevant to a particular test, so I'll set the 
noreg-hard label.

Recently I've hit it with a non-test application.

With kind regards,

Ivan



From daniel.fuchs at oracle.com  Mon Mar 23 13:22:07 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Mar 2020 13:22:07 +0000
Subject: 8241443: Problem list some java.net tests failing with
 NoRouteToHostException on macOS with special network configuration
Message-ID: <4eab8272-3daf-0ab3-c7ac-042971688faa@oracle.com>

Hi,

Please find below a changeset for:

8241443: Problem list some java.net tests failing with
          NoRouteToHostException on macOS with special
          network configuration

We are observing some net/nio tests failing on some of our mac
machines. While we investigate the issue we would like to
problem list those tests for macosx-all:

best regards,

-- daniel

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -614,6 +614,11 @@

  # jdk_net

+java/net/Socket/LinkLocal.java                                  8241336 
macosx-all
+java/net/MulticastSocket/SetOutgoingIf.java                     8241336 
macosx-all
+java/net/MulticastSocket/Promiscuous.java                       8241336 
macosx-all
+java/net/InetAddress/CheckJNI.java                              8241336 
macosx-all
+
  java/net/MulticastSocket/NoLoopbackPackets.java 
7122846 macosx-all
  java/net/MulticastSocket/SetLoopbackMode.java 
7122846 macosx-all

@@ -630,6 +635,9 @@

  # jdk_nio

+java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 
8241336 macosx-all
+java/nio/channels/DatagramChannel/AdaptorMulticasting.java 
8241336 macosx-all
+
  java/nio/Buffer/EqualsCompareTest.java 
8193917 solaris-all

  java/nio/channels/DatagramChannel/ChangingAddress.java 
7141822 macosx-all

From Alan.Bateman at oracle.com  Mon Mar 23 13:32:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 13:32:45 +0000
Subject: 8241443: Problem list some java.net tests failing with
 NoRouteToHostException on macOS with special network configuration
In-Reply-To: <4eab8272-3daf-0ab3-c7ac-042971688faa@oracle.com>
References: <4eab8272-3daf-0ab3-c7ac-042971688faa@oracle.com>
Message-ID: <63d802af-93bc-f038-923e-ef9afcc7b41d@oracle.com>

The approach seems okay until the test infrastructure is fixed to ignore 
the problematic interfaces. Would you mind listing the DatagramChannel 
tests with the other DatagramChannel tests that are already excluded so 
they aren't in random order.

-Alan


On 23/03/2020 13:22, Daniel Fuchs wrote:
> Hi,
>
> Please find below a changeset for:
>
> 8241443: Problem list some java.net tests failing with
> ???????? NoRouteToHostException on macOS with special
> ???????? network configuration
>
> We are observing some net/nio tests failing on some of our mac
> machines. While we investigate the issue we would like to
> problem list those tests for macosx-all:
>
> best regards,
>
> -- daniel
>
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -614,6 +614,11 @@
>
> ?# jdk_net
>
> +java/net/Socket/LinkLocal.java 8241336 macosx-all
> +java/net/MulticastSocket/SetOutgoingIf.java 8241336 macosx-all
> +java/net/MulticastSocket/Promiscuous.java 8241336 macosx-all
> +java/net/InetAddress/CheckJNI.java 8241336 macosx-all
> +
> ?java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all
> ?java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all
>
> @@ -630,6 +635,9 @@
>
> ?# jdk_nio
>
> +java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 
> 8241336 macosx-all
> +java/nio/channels/DatagramChannel/AdaptorMulticasting.java 8241336 
> macosx-all
> +
> ?java/nio/Buffer/EqualsCompareTest.java 8193917 solaris-all
>
> ?java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 
> macosx-all


From daniel.fuchs at oracle.com  Mon Mar 23 14:19:47 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Mar 2020 14:19:47 +0000
Subject: 8241443: Problem list some java.net tests failing with
 NoRouteToHostException on macOS with special network configuration
In-Reply-To: <63d802af-93bc-f038-923e-ef9afcc7b41d@oracle.com>
References: <4eab8272-3daf-0ab3-c7ac-042971688faa@oracle.com>
 <63d802af-93bc-f038-923e-ef9afcc7b41d@oracle.com>
Message-ID: <c5703580-33f0-2594-a695-4e5a29740396@oracle.com>

On 23/03/2020 13:32, Alan Bateman wrote:
> The approach seems okay until the test infrastructure is fixed to ignore 
> the problematic interfaces. Would you mind listing the DatagramChannel 
> tests with the other DatagramChannel tests that are already excluded so 
> they aren't in random order.

Thanks Alan! I'll reorder before pushing.

-- daniel

> 
> -Alan
> 
> 
> On 23/03/2020 13:22, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a changeset for:
>>
>> 8241443: Problem list some java.net tests failing with
>> ???????? NoRouteToHostException on macOS with special
>> ???????? network configuration
>>
>> We are observing some net/nio tests failing on some of our mac
>> machines. While we investigate the issue we would like to
>> problem list those tests for macosx-all:
>>
>> best regards,
>>
>> -- daniel
>>
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -614,6 +614,11 @@
>>
>> ?# jdk_net
>>
>> +java/net/Socket/LinkLocal.java 8241336 macosx-all
>> +java/net/MulticastSocket/SetOutgoingIf.java 8241336 macosx-all
>> +java/net/MulticastSocket/Promiscuous.java 8241336 macosx-all
>> +java/net/InetAddress/CheckJNI.java 8241336 macosx-all
>> +
>> ?java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all
>> ?java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all
>>
>> @@ -630,6 +635,9 @@
>>
>> ?# jdk_nio
>>
>> +java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 
>> 8241336 macosx-all
>> +java/nio/channels/DatagramChannel/AdaptorMulticasting.java 8241336 
>> macosx-all
>> +
>> ?java/nio/Buffer/EqualsCompareTest.java 8193917 solaris-all
>>
>> ?java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 
>> macosx-all
> 


From patrick.concannon at oracle.com  Mon Mar 23 16:37:09 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Mon, 23 Mar 2020 16:37:09 +0000
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
Message-ID: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>

This is a request for review for the implementation changes for JEP 373: 
'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been created 
[2].

The implementation of JEP 373 can be viewed on the JDK-8230211-branch in 
the sandbox [3].

A link to the webrev with the cumulated changes is available below [4].

The sources changes are limited to five files. The webrev also adds 
additional tests while a selection of existing tests have been updated 
to run with both the old and new implementation. Please refer to the JEP 
[1] for more information.

-Patrick


[1] https://openjdk.java.net/jeps/373

[2] https://bugs.openjdk.java.net/browse/JDK-8241188

[3] http://hg.openjdk.java.net/jdk/sandbox/shortlog/8176cc48cc78

[4] http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.00/


From julia.boes at oracle.com  Mon Mar 23 17:51:48 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Mon, 23 Mar 2020 17:51:48 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
Message-ID: <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>

Hi Daniel,

> We should try to call Path::toFile first - whether there is a security
> manager or not. In the case where that succeeds, we can use
> new FileInputStream(), otherwise, we use Files.newInputStream.
>
> It's unfortunate that new FileInputStream() and Files.newInputStream()
> use different sets of exceptions, and that our public signature use
> the exception thrown by the former.
>
> Keeping using new FileInputStream() for the case where the Path::toFile
> returns a file will ensure that we preserve backward compatibility
> with existing code, but the current implementation of create() is
> missing the case where there is no security manager and
> Path::toFile doesn't throw.

Thanks for the input, I adjusted the changes to FilePublisher 
accordingly. All relevant tests pass on repeat 50.

Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/

Regards,

Julia


From Alan.Bateman at oracle.com  Mon Mar 23 18:59:58 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 18:59:58 +0000
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
Message-ID: <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>

On 23/03/2020 16:37, Patrick Concannon wrote:
> This is a request for review for the implementation changes for JEP 
> 373: 'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been 
> created [2].
>
> The implementation of JEP 373 can be viewed on the JDK-8230211-branch 
> in the sandbox [3].
>
> A link to the webrev with the cumulated changes is available below [4].
>
> The sources changes are limited to five files. The webrev also adds 
> additional tests while a selection of existing tests have been updated 
> to run with both the old and new implementation. Please refer to the 
> JEP [1] for more information.
This is a good work and easy to review.

As you know, I would have preferred to see the creation of the delegate 
separated from the configuration (like we do with impls) but I think you 
and Daniel want to keep the version you have, okay. I'm also not too 
keen on another temporary solution in advance of any discussion on 
JDK-8237352 but I guess what you have is okay as it's benign.

Small comments:

DatagramSocket
- the comments at L117-120, L123-124, and L143-L147 need a tidy up, 
probably most of them can be replaced with simple one-liners.
- the use of type.cast at L119 and L1125 looks odd. It might be simpler 
to just replace L1156 with "return (T) delegate". That would allow you 
to assign delegate (no need for "adaptor" or oddly named "plainDelegate").
- I assume the new static final fields can be private too.
- usePlainDatagramSocketImpl is inconsistent with the equivalent in 
SocketImpl for the garbage value case. We should try to get those 
consistent at some point.
- createDelegate's method description has inconsistent formatting.
- L1145 should be "initialized = true".

MulticastSocket and NetMulticastSocket look okay. There are probably 
better names for "NetMulticastSocket" but it's not public so okay. Happy 
to see NetMulticastSocket.options is an instance field, seems like that 
bug was lurking for a long time.

DatagramSocketAdaptor - if we are keeping this change then I'd prefer if 
the comment was cleaned up to be consistent with the other support 
classes. A one-liner is okay. The "Temporary solution" comment can go 
away. Also would be good to use 4-space indentation to be consistent 
with the other support classes.

The changes to run the tests twice is good. The UnreferencedXXX tests 
are a bit messy and I'm concerned that the changes to these tests make 
them too hard to maintain. I think we need to find better ways to test 
that unreferenced sockets are closed so that these tests can be replaced 
with tests that easy to maintain.

SendBufCheck is puzzling to see in this webrev as it's not part of the 
JEP. An equivalent of JDK-8239355 that only tests the new implementation 
(not the old because it's not quite right) would be okay. Alternatively 
re-visit it as part of JDK-8240901 to test that large datagrams can be 
sent on the network.

I think that is all I have.

-Alan

From amy.lu at oracle.com  Tue Mar 24 05:57:58 2020
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 24 Mar 2020 13:57:58 +0800
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
Message-ID: <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>

On 3/24/20 1:51 AM, Julia Boes wrote:
> Updated webrev: 
> http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/

Hi, Julia

Just a minor comment on the test usage of

/othervm/java.security.policy=FilePublisherPermsTest3.policy 
-Djava.security.manager

As jtreg tag-spec [1] suggested:
 ? The setting of the system properties "java.security.manager" and 
"java.security.policy" in main/othervm actions is also discouraged; the 
/policy and /secure options should be used instead.


Thanks,
Amy

[1] http://openjdk.java.net/jtreg/tag-spec.html

From akashche at redhat.com  Tue Mar 24 11:28:45 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 24 Mar 2020 11:28:45 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy
Message-ID: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>

Hi,

Please review the backport of JDK-8183369 to 11u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8183369

Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0

11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/

Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy 
test was adjusted because mainline changes depend on JDK-8227539 that 
was added in 14.

-- 
-Alex


From christoph.langer at sap.com  Tue Mar 24 12:36:50 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 12:36:50 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
Message-ID: <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alex,

I think this looks good overall.

There's one line in test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where you got the indentation wrong. Please check and fix that.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Alex Kashchenko
> Sent: Dienstag, 24. M?rz 2020 12:29
> To: jdk-updates-dev at openjdk.java.net
> Cc: net-dev at openjdk.java.net
> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
> proxy
> 
> Hi,
> 
> Please review the backport of JDK-8183369 to 11u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
> 
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
> 
> 11u webrev:
> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
> 
> Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy
> test was adjusted because mainline changes depend on JDK-8227539 that
> was added in 14.
> 
> --
> -Alex


From julia.boes at oracle.com  Tue Mar 24 15:01:51 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 24 Mar 2020 15:01:51 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
Message-ID: <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>

Hi Amy,

> Just a minor comment on the test usage of
>
> /othervm/java.security.policy=FilePublisherPermsTest3.policy 
> -Djava.security.manager
>
> As jtreg tag-spec [1] suggested:
> ? The setting of the system properties "java.security.manager" and 
> "java.security.policy" in main/othervm actions is also discouraged; 
> the /policy and /secure options should be used instead.

thanks for spotting that! It's fixed now.

Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/

Cheers,

Julia



From chris.hegarty at oracle.com  Tue Mar 24 15:29:29 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2020 15:29:29 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
 <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
Message-ID: <E84FF78C-E303-4370-ACF4-6F7467A39D9C@oracle.com>


> On 24 Mar 2020, at 15:01, Julia Boes <julia.boes at oracle.com> wrote:
> ...
> 
> Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/

LGTM.

-Chris.

From daniel.fuchs at oracle.com  Tue Mar 24 15:49:08 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Mar 2020 15:49:08 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
 <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
Message-ID: <6f52ebb8-e352-b5c2-80a7-8afa54550307@oracle.com>

Hi Julia,

* @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy

Does this actually work as expected? I thought the syntax was:

@run testng/othervm/policy=<file>

And FWIW there some subtlety with
   othervm/policy=<file>
versus
   othervm/policy==<file>

and I never remember which one should be used.

Here we do want the default.policy files to be extended, and not
replaced. So you may have to go with == (maybe)

cheers,

-- daniel

On 24/03/2020 15:01, Julia Boes wrote:
> Updated webrev: 
> http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/
> 
> Cheers,
> 
> Julia
> 
> 


From julia.boes at oracle.com  Tue Mar 24 16:33:49 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 24 Mar 2020 16:33:49 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <6f52ebb8-e352-b5c2-80a7-8afa54550307@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
 <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
 <6f52ebb8-e352-b5c2-80a7-8afa54550307@oracle.com>
Message-ID: <48c4d881-0b5a-3412-a1e9-5c1812ee3789@oracle.com>

Hi Daniel,

> * @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy
>
> Does this actually work as expected? I thought the syntax was:
>
> @run testng/othervm/policy=<file>

I couldn't get the test to run with the latter but noticed that most 
tests that are run with testng use the 'java.security.policy' option. It 
works as expected.

> And FWIW there some subtlety with
> ? othervm/policy=<file>
> versus
> ? othervm/policy==<file>
>
> and I never remember which one should be used.
>
> Here we do want the default.policy files to be extended, and not
> replaced. So you may have to go with == (maybe)

That's right, any I actually wasn't aware of the '==' option. According 
to [1], ?==? sets a *sole* policy file, whereas ?=? sets an *additional* 
file. So we want to go with ?=?.

Regards,

Julia


[1] 
https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html 
(section: Specifying an Additional Policy File at Runtime)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200324/47415636/attachment.htm>

From daniel.fuchs at oracle.com  Tue Mar 24 17:04:35 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Mar 2020 17:04:35 +0000
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <48c4d881-0b5a-3412-a1e9-5c1812ee3789@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
 <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
 <6f52ebb8-e352-b5c2-80a7-8afa54550307@oracle.com>
 <48c4d881-0b5a-3412-a1e9-5c1812ee3789@oracle.com>
Message-ID: <345d8b7f-2f3b-4da4-c739-1d453eb4e56c@oracle.com>

OK, thanks for double checking Julia.

Looks good to me then!

best regards,

-- daniel

On 24/03/2020 16:33, Julia Boes wrote:
> Hi Daniel,
> 
>> * @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy
>>
>> Does this actually work as expected? I thought the syntax was:
>>
>> @run testng/othervm/policy=<file>
> 
> I couldn't get the test to run with the latter but noticed that most 
> tests that are run with testng use the 'java.security.policy' option. It 
> works as expected.
> 
>> And FWIW there some subtlety with
>> ? othervm/policy=<file>
>> versus
>> ? othervm/policy==<file>
>>
>> and I never remember which one should be used.
>>
>> Here we do want the default.policy files to be extended, and not
>> replaced. So you may have to go with == (maybe)
> 
> That's right, any I actually wasn't aware of the '==' option. According 
> to [1], ?==? sets a *sole* policy file, whereas ?=? sets an *additional* 
> file. So we want to go with ?=?.
> 
> Regards,
> 
> Julia
> 
> 
> [1] 
> https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html 
> (section: Specifying an Additional Policy File at Runtime)
> 


From akashche at redhat.com  Tue Mar 24 18:09:09 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 24 Mar 2020 18:09:09 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
 <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>

Hi Christoph,

On 03/24/2020 12:36 PM, Langer, Christoph wrote:
> Hi Alex,
> 
> I think this looks good overall.

Thanks for the review!

> 
> There's one line in test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where you got the indentation wrong. Please check and fix that.

Sorry for tabs on that line, not sure how they got there, updated webrev 
after :retab :

http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/

> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
>> Behalf Of Alex Kashchenko
>> Sent: Dienstag, 24. M?rz 2020 12:29
>> To: jdk-updates-dev at openjdk.java.net
>> Cc: net-dev at openjdk.java.net
>> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
>> proxy
>>
>> Hi,
>>
>> Please review the backport of JDK-8183369 to 11u:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
>>
>> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
>>
>> 11u webrev:
>> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
>>
>> Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy
>> test was adjusted because mainline changes depend on JDK-8227539 that
>> was added in 14.
>>
>> --
>> -Alex
> 


-- 
-Alex


From christoph.langer at sap.com  Tue Mar 24 19:49:48 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 19:49:48 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
 <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>
Message-ID: <AM0PR02MB571406679E1135D1478F936E8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alex,

looks good now.

Cheers
Christoph

> -----Original Message-----
> From: Alex Kashchenko <akashche at redhat.com>
> Sent: Dienstag, 24. M?rz 2020 19:09
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: net-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection
> with proxy
> 
> Hi Christoph,
> 
> On 03/24/2020 12:36 PM, Langer, Christoph wrote:
> > Hi Alex,
> >
> > I think this looks good overall.
> 
> Thanks for the review!
> 
> >
> > There's one line in
> test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85,
> where you got the indentation wrong. Please check and fix that.
> 
> Sorry for tabs on that line, not sure how they got there, updated webrev
> after :retab :
> 
> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/
> 
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> >> Behalf Of Alex Kashchenko
> >> Sent: Dienstag, 24. M?rz 2020 12:29
> >> To: jdk-updates-dev at openjdk.java.net
> >> Cc: net-dev at openjdk.java.net
> >> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection
> with
> >> proxy
> >>
> >> Hi,
> >>
> >> Please review the backport of JDK-8183369 to 11u:
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
> >>
> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
> >>
> >> 11u webrev:
> >> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
> >>
> >> Patch to HttpURLConnection applies cleanly, patch to
> HttpURLConWithProxy
> >> test was adjusted because mainline changes depend on JDK-8227539 that
> >> was added in 14.
> >>
> >> --
> >> -Alex
> >
> 
> 
> --
> -Alex


From amy.lu at oracle.com  Wed Mar 25 01:41:55 2020
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 25 Mar 2020 09:41:55 +0800
Subject: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the
 default file system
In-Reply-To: <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
References: <7d1f1ef0-7a99-2da1-bb41-afff4cf81169@oracle.com>
 <E77DFFFB-7E69-40E1-BD4D-AA8776158724@oracle.com>
 <b886cfcb-3d4b-af33-0aa7-be6eba8e0e59@oracle.com>
 <d5a5d910-0604-a6cb-f30f-aa5e99c9ffa2@oracle.com>
 <7cbfdb35-7050-d4a1-be43-0190d98b25ff@oracle.com>
 <da59ce40-f5b2-d50a-665d-ab444fa6ccaa@oracle.com>
 <38db085d-5c60-b083-c582-d1c6b20a60f1@oracle.com>
Message-ID: <4392a5fe-9401-18ed-61b8-ebc09b9abc55@oracle.com>

Thank you Julia!
Looks good to me.

Thanks,
Amy

On 3/24/20 11:01 PM, Julia Boes wrote:
> Hi Amy,
>
>> Just a minor comment on the test usage of
>>
>> /othervm/java.security.policy=FilePublisherPermsTest3.policy 
>> -Djava.security.manager
>>
>> As jtreg tag-spec [1] suggested:
>> ? The setting of the system properties "java.security.manager" and 
>> "java.security.policy" in main/othervm actions is also discouraged; 
>> the /policy and /secure options should be used instead.
>
> thanks for spotting that! It's fixed now.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/
>
> Cheers,
>
> Julia
>
>


From rahul.r.yadav at oracle.com  Thu Mar 26 14:02:06 2020
From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com)
Date: Thu, 26 Mar 2020 14:02:06 +0000
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
Message-ID: <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>

Hello,

Request to have my fix reviewed for issues:

 ??? JDK-8239595 : ssl context version is not respected
 ??? JDK-8239594 : jdk.tls.client.protocols is not respected

The fix updates 
jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
to use ctx.getDefaultSSLParameters()instead of 
ctx.getSupportedSSLParameters(),
as the latter does not respect the context parameters set by the user.

Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
Issue: https://bugs.openjdk.java.net/browse/JDK-8239594

Webrev: 
http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/

-- Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200326/3db18b16/attachment.htm>

From julia.boes at oracle.com  Thu Mar 26 14:32:32 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 26 Mar 2020 14:32:32 +0000
Subject: 8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest
Message-ID: <f4a6f7fb-0afe-b037-f237-223d2ca3e4f1@oracle.com>

Hi,

Could someone please review this small fix of a recently pushed test? 
The option to extend the policy file has to be 'java.security.policy' 
instead of 'policy' -? this was discussed on this mailing list but then 
miraculously ignored by myself...

Bug: https://bugs.openjdk.java.net/browse/JDK-8241674

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8241674/webrev.00/

Regards,

Julia



From daniel.fuchs at oracle.com  Thu Mar 26 14:38:13 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2020 14:38:13 +0000
Subject: 8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest
In-Reply-To: <f4a6f7fb-0afe-b037-f237-223d2ca3e4f1@oracle.com>
References: <f4a6f7fb-0afe-b037-f237-223d2ca3e4f1@oracle.com>
Message-ID: <017be4cc-b9a1-bb3c-e014-8d1e3437194c@oracle.com>

Thanks for jumping on this Julia!

Reviewed. Since this is making some noise in the CI I suggest
to push it asap.

best regards,

-- daniel

On 26/03/2020 14:32, Julia Boes wrote:
> Hi,
> 
> Could someone please review this small fix of a recently pushed test? 
> The option to extend the policy file has to be 'java.security.policy' 
> instead of 'policy' -? this was discussed on this mailing list but then 
> miraculously ignored by myself...
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241674
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8241674/webrev.00/
> 
> Regards,
> 
> Julia
> 
> 


From chris.hegarty at oracle.com  Thu Mar 26 14:48:45 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 26 Mar 2020 14:48:45 +0000
Subject: 8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest
In-Reply-To: <f4a6f7fb-0afe-b037-f237-223d2ca3e4f1@oracle.com>
References: <f4a6f7fb-0afe-b037-f237-223d2ca3e4f1@oracle.com>
Message-ID: <563A9F12-7D27-4E5B-9339-6559F04DF553@oracle.com>

LGTM.

-Chris

> On 26 Mar 2020, at 14:32, Julia Boes <julia.boes at oracle.com> wrote:
> 
> ?Hi,
> 
> Could someone please review this small fix of a recently pushed test? The option to extend the policy file has to be 'java.security.policy' instead of 'policy' -  this was discussed on this mailing list but then miraculously ignored by myself...
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241674
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8241674/webrev.00/
> 
> Regards,
> 
> Julia
> 
> 


From daniel.fuchs at oracle.com  Thu Mar 26 15:36:52 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2020 15:36:52 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException on
 MacOS with special network configuration
Message-ID: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>

Hi,

Please find below a fix for:
8241336: Some java.net tests failed with NoRouteToHostException on
          MacOS with special network configuration
https://bugs.openjdk.java.net/browse/JDK-8241336

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.01/index.html

The crux of the issue is that on some macOS hardware/OS versions
we get network interfaces that look like regular ethernet interfaces
though they are not.
Picking them up while testing make some tests fail.

Most of these tests were already relying on the NetworkConfiguration
test library class - which has now been updated to skip these
problematic interfaces. I have heuristically observed that these
interfaces seemed to only have one link-local IPv6 address, while the
other regular interfaces had at least one IPv4, or one non link-local
IPv6. That seems to be the only observable difference.

The fix also contains some code for AdaptorMulticasting.java aim at
better diagnosing (and possibly fixing?) JDK-8238516 [1] - I might close
JDK-8238516 as a duplicate of JDK-8241336 if the issue doesn't
reproduce.

best regards,

-- daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8238516

From sean.mullan at oracle.com  Thu Mar 26 16:28:05 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 26 Mar 2020 12:28:05 -0400
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
Message-ID: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>

Cross-posting to security-dev as this involves TLS/SSL configuration.

--Sean

On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
> Hello,
> 
> Request to have my fix reviewed for issues:
> 
>  ??? JDK-8239595 : ssl context version is not respected
>  ??? JDK-8239594 : jdk.tls.client.protocols is not respected
> 
> The fix updates 
> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
> to use ctx.getDefaultSSLParameters()instead of 
> ctx.getSupportedSSLParameters(),
> as the latter does not respect the context parameters set by the user.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
> 
> Webrev: 
> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
> 
> -- Rahul

From sean.mullan at oracle.com  Thu Mar 26 16:29:50 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 26 Mar 2020 12:29:50 -0400
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
Message-ID: <d60d219a-6e3e-0397-a4a7-95a2ab33ad99@oracle.com>

I think you should mark one of the two bugs a duplicate. Typically I 
mark the more recent one as a duplicate, unless there is a good reason 
to do otherwise.

--Sean

On 3/26/20 12:28 PM, Sean Mullan wrote:
> Cross-posting to security-dev as this involves TLS/SSL configuration.
> 
> --Sean
> 
> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
>> Hello,
>>
>> Request to have my fix reviewed for issues:
>>
>> ???? JDK-8239595 : ssl context version is not respected
>> ???? JDK-8239594 : jdk.tls.client.protocols is not respected
>>
>> The fix updates 
>> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
>> to use ctx.getDefaultSSLParameters()instead of 
>> ctx.getSupportedSSLParameters(),
>> as the latter does not respect the context parameters set by the user.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
>>
>> -- Rahul

From xuelei.fan at oracle.com  Thu Mar 26 16:58:49 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 26 Mar 2020 09:58:49 -0700
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
Message-ID: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>

With this update, the logic looks like: if TLSv1.3 is not enabled in the 
SSLContext, use TLSv1.2 instead;  Otherwise, use TLSv1.3 and TLSv1.2.

There may be a couple of issues:
1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
For example:
    System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")

2. TLSv1.2 may be not supported in the SSLContext.
For example:
    SSLContext context = SSLContext.getInstance("DTLS");
    HttpClient.newBuilder().sslContext(context)...

3. The application may not want to use TLS 1.2.
For example:
    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")

The System property may be shared by code other than httpclient.  So the 
setting may not consider the impact on httpclient.

I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an 
empty protocol array, and test to see what happens in the httpclient 
implementation stack.

Xuelei

On 3/26/2020 9:28 AM, Sean Mullan wrote:
> Cross-posting to security-dev as this involves TLS/SSL configuration.
> 
> --Sean
> 
> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
>> Hello,
>>
>> Request to have my fix reviewed for issues:
>>
>> ???? JDK-8239595 : ssl context version is not respected
>> ???? JDK-8239594 : jdk.tls.client.protocols is not respected
>>
>> The fix updates 
>> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
>> to use ctx.getDefaultSSLParameters()instead of 
>> ctx.getSupportedSSLParameters(),
>> as the latter does not respect the context parameters set by the user.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
>>
>> -- Rahul

From Alan.Bateman at oracle.com  Thu Mar 26 17:29:33 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Mar 2020 17:29:33 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
Message-ID: <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>

On 26/03/2020 15:36, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
> 8241336: Some java.net tests failed with NoRouteToHostException on
> ???????? MacOS with special network configuration
> https://bugs.openjdk.java.net/browse/JDK-8241336
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.01/index.html
NetworkConfiguration.isTestable - is the hardcoded check for "awdl" 
needed? I don't think I've seen it with non-link local address so I 
can't tell if it is needed. I'm

Promiscuous - can "addr" be renamed to toSocketAddress so the usages are 
a bit clearer?

SetOutgoingIf - the initializer at L38 may not be obvious to some 
readers that aren't used to that syntax, can it use a regular 
constructor instead?

AdaptorMulticasting - I don't mind if it included here or separated into 
its own issue as the changes aren't needed for JDK-8241336. If you are 
including it then the patch should be cleaned up a bit so that it is 
consistent with the existing code. It was an oversight (by me) when I 
added this test. testSendNoReceive should have just ignored datagrams 
that are sent by an unexpected sender or with unexpected bytes. I think 
it complicates things to try to decode the bytes of a random datagram 
and prefer to see that part removed. It's okay to lot a message that an 
expected message has been received but its content it not interesting 
for the test. One thing that we should do some time is change some of 
the multicasting tests to use other multicast groups. I suspect some of 
the tests have copied the multicast address from other tests so we end 
up with several tests using the same group.

-Alan.

From daniel.fuchs at oracle.com  Thu Mar 26 20:35:59 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2020 20:35:59 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
 <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
Message-ID: <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>

Hi Alan.

On 26/03/2020 17:29, Alan Bateman wrote:
> NetworkConfiguration.isTestable - is the hardcoded check for "awdl" 
> needed? I don't think I've seen it with non-link local address so I 
> can't tell if it is needed. I'm

It might no longer be needed, but we know that awdl is always
the wrong choice, so excluding it right away won't harm.
That was part of Chris's fix for 7155591 [1].

I've applied your other comments:

http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/

best regards,

-- daniel

[1] 
http://cr.openjdk.java.net/~msheppar/7155591/webrev/test/java/net/MulticastSocket/SetOutgoingIf.java.frames.html 


> Promiscuous - can "addr" be renamed to toSocketAddress so the usages are 
> a bit clearer? >
> SetOutgoingIf - the initializer at L38 may not be obvious to some 
> readers that aren't used to that syntax, can it use a regular 
> constructor instead?
> 
> AdaptorMulticasting - I don't mind if it included here or separated into 
> its own issue as the changes aren't needed for JDK-8241336. If you are 
> including it then the patch should be cleaned up a bit so that it is 
> consistent with the existing code. It was an oversight (by me) when I 
> added this test. testSendNoReceive should have just ignored datagrams 
> that are sent by an unexpected sender or with unexpected bytes. I think 
> it complicates things to try to decode the bytes of a random datagram 
> and prefer to see that part removed. It's okay to lot a message that an 
> expected message has been received but its content it not interesting 
> for the test. One thing that we should do some time is change some of 
> the multicasting tests to use other multicast groups. I suspect some of 
> the tests have copied the multicast address from other tests so we end 
> up with several tests using the same group.
> 



From Alan.Bateman at oracle.com  Fri Mar 27 09:06:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Mar 2020 09:06:10 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
 <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
 <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>
Message-ID: <d49c976c-85f7-35df-a75c-99d7d41cc93a@oracle.com>



On 26/03/2020 20:35, Daniel Fuchs wrote:
> Hi Alan.
>
> On 26/03/2020 17:29, Alan Bateman wrote:
>> NetworkConfiguration.isTestable - is the hardcoded check for "awdl" 
>> needed? I don't think I've seen it with non-link local address so I 
>> can't tell if it is needed. I'm
>
> It might no longer be needed, but we know that awdl is always
> the wrong choice, so excluding it right away won't harm.
> That was part of Chris's fix for 7155591 [1].
Okay, it was just a question on whether it was needed. I looked at 3 
systems with an awdl interface and all had just an IPv6 link local 
address.? I was also wondering about the Teredo tunnel but I couldn't 
find a system quickly to see what the default configuration. I think the 
main point is that your change will filter out most of the annoying 
tunnels and adaptors that have complicated testing in recent years.


> I've applied your other comments:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
This mostly looks good except that I'd prefer if the the code in 
assertNotSame be moved into testSendNoReceive (it was an oversight in 
the original test that testSendNoReceive didn't have this check).

-Alan

From daniel.fuchs at oracle.com  Fri Mar 27 09:30:17 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 27 Mar 2020 09:30:17 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <d49c976c-85f7-35df-a75c-99d7d41cc93a@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
 <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
 <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>
 <d49c976c-85f7-35df-a75c-99d7d41cc93a@oracle.com>
Message-ID: <a5409520-0437-96ad-29b8-ad76a519add2@oracle.com>

Hi Alan,

On 27/03/2020 09:06, Alan Bateman wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
> This mostly looks good except that I'd prefer if the the code in 
> assertNotSame be moved into testSendNoReceive (it was an oversight in 
> the original test that testSendNoReceive didn't have this check).

Done: http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.03/

best regards,

-- daniel

> 
> -Al


From chris.hegarty at oracle.com  Fri Mar 27 09:42:36 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Mar 2020 09:42:36 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <a5409520-0437-96ad-29b8-ad76a519add2@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
 <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
 <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>
 <d49c976c-85f7-35df-a75c-99d7d41cc93a@oracle.com>
 <a5409520-0437-96ad-29b8-ad76a519add2@oracle.com>
Message-ID: <CAFAC80C-C41F-438D-B8E5-FA3D95BAC06E@oracle.com>


> On 27 Mar 2020, at 09:30, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Alan,
> 
> On 27/03/2020 09:06, Alan Bateman wrote:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
>> This mostly looks good except that I'd prefer if the the code in assertNotSame be moved into testSendNoReceive (it was an oversight in the original test that testSendNoReceive didn't have this check).
> 
> Done: http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.03/

LGTM.

-Chris.

From Alan.Bateman at oracle.com  Fri Mar 27 10:19:51 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Mar 2020 10:19:51 +0000
Subject: 8241336: Some java.net tests failed with NoRouteToHostException
 on MacOS with special network configuration
In-Reply-To: <a5409520-0437-96ad-29b8-ad76a519add2@oracle.com>
References: <ed0cb647-41bd-d02a-8d0e-31041617af8e@oracle.com>
 <2e425942-ab67-7afa-dc6d-ab617e17b9f9@oracle.com>
 <d1d6088f-4f54-9199-2b9e-93a5f56fc24f@oracle.com>
 <d49c976c-85f7-35df-a75c-99d7d41cc93a@oracle.com>
 <a5409520-0437-96ad-29b8-ad76a519add2@oracle.com>
Message-ID: <053c5dc0-19b8-4b30-8e0b-54a3ae1199b8@oracle.com>



On 27/03/2020 09:30, Daniel Fuchs wrote:
> Hi Alan,
>
> On 27/03/2020 09:06, Alan Bateman wrote:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
>> This mostly looks good except that I'd prefer if the the code in 
>> assertNotSame be moved into testSendNoReceive (it was an oversight in 
>> the original test that testSendNoReceive didn't have this check).
>
> Done: http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.03/
Looks good.

From michael.x.mcmahon at oracle.com  Fri Mar 27 10:50:18 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 27 Mar 2020 10:50:18 +0000
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
Message-ID: <56e188c6-725a-e3db-ca39-f5cffb4cca01@oracle.com>

Hi Xuelei,

I have some concerns about these bugs also, though not exactly the same 
as yours:

The "jdk.tls.client.protocols" system property is not part of the HTTP 
client API. So, it's not
clear to me why the HTTP client is expected to enforce it. It is equally 
possible for any code using
SSLContext and SSLParameters to select protocols that appear to 
contradict the protocols set
in the property.

Same goes for the protocol used to initialize the SSLContext itself (bug 
8239595).
If it is an error to initialize the context with TLSv1.2, but then try 
to set TLSv1.3 in the SSLParameters,
then why doesn't the TLS layer enforce that constraint? Is it even 
specified anywhere?

That said, I think there is an issue that needs to be fixed. If a user 
wants to use TLS1.2, we
certainly should not force them to use 1.3.

I am beginning to think that the HTTP client should behave in a way that 
is more clear/transparent
to its users as follows:

1) If the user specifies neither an SSLContext nor an SSLParameters, 
then the HTTP library should
 ??? choose a TLS version that is most likely to work for HTTP (maybe 
choose highest version that is available)

2) If the user specifies an SSLContext then we use the default 
SSLParameters without adding any protocol versions

3) If the user does not specify an SSLContext but does specify an 
SSLParameters then we create a default context
 ?? and apply the given SSLParameters (with no additional protocol 
versions added)

So, for 2) and 3) it is up to the caller to ensure that the resulting 
SSL configuration "works".? It may fail
of course with a handshake error (or runtime error presumably if you try 
to select DTLS for example).

Maybe it would make more sense to fix that behavior through another bug 
id, because in my view these
two issues are more of a spec/impl issue for the TLS layer itself.

What do you think?

Michael.

On 26/03/2020 16:58, Xuelei Fan wrote:
> With this update, the logic looks like: if TLSv1.3 is not enabled in 
> the SSLContext, use TLSv1.2 instead;? Otherwise, use TLSv1.3 and TLSv1.2.
>
> There may be a couple of issues:
> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
> For example:
> ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
> ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
>
> 2. TLSv1.2 may be not supported in the SSLContext.
> For example:
> ?? SSLContext context = SSLContext.getInstance("DTLS");
> ?? HttpClient.newBuilder().sslContext(context)...
>
> 3. The application may not want to use TLS 1.2.
> For example:
> ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
>
> The System property may be shared by code other than httpclient. So 
> the setting may not consider the impact on httpclient.
>
> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an 
> empty protocol array, and test to see what happens in the httpclient 
> implementation stack.
>
> Xuelei
>
> On 3/26/2020 9:28 AM, Sean Mullan wrote:
>> Cross-posting to security-dev as this involves TLS/SSL configuration.
>>
>> --Sean
>>
>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
>>> Hello,
>>>
>>> Request to have my fix reviewed for issues:
>>>
>>> ???? JDK-8239595 : ssl context version is not respected
>>> ???? JDK-8239594 : jdk.tls.client.protocols is not respected
>>>
>>> The fix updates 
>>> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
>>> to use ctx.getDefaultSSLParameters()instead of 
>>> ctx.getSupportedSSLParameters(),
>>> as the latter does not respect the context parameters set by the user.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
>>>
>>> Webrev: 
>>> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
>>>
>>> -- Rahul

From chris.hegarty at oracle.com  Fri Mar 27 12:52:40 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Mar 2020 12:52:40 +0000
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
Message-ID: <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>

Xuelei,

Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. 

Is there a specification or other documentation describing `jdk.tls.client.protocols` ?

It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?

-Chris.

> On 26 Mar 2020, at 16:58, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead;  Otherwise, use TLSv1.3 and TLSv1.2.
> 
> There may be a couple of issues:
> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
> For example:
>   System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
>   System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
> 
> 2. TLSv1.2 may be not supported in the SSLContext.
> For example:
>   SSLContext context = SSLContext.getInstance("DTLS");
>   HttpClient.newBuilder().sslContext(context)...
> 
> 3. The application may not want to use TLS 1.2.
> For example:
>   System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
> 
> The System property may be shared by code other than httpclient.  So the setting may not consider the impact on httpclient.
> 
> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack.
> 
> Xuelei
> 
> On 3/26/2020 9:28 AM, Sean Mullan wrote:
>> Cross-posting to security-dev as this involves TLS/SSL configuration.
>> --Sean
>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
>>> Hello,
>>> 
>>> Request to have my fix reviewed for issues:
>>> 
>>>      JDK-8239595 : ssl context version is not respected
>>>      JDK-8239594 : jdk.tls.client.protocols is not respected
>>> 
>>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
>>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(),
>>> as the latter does not respect the context parameters set by the user.
>>> 
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
>>> 
>>> -- Rahul


From xuelei.fan at oracle.com  Fri Mar 27 16:23:30 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 27 Mar 2020 09:23:30 -0700
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
Message-ID: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>

On 3/27/2020 5:52 AM, Chris Hegarty wrote:
> Xuelei,
> 
> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
> 
> Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
> 
See the jdk.tls.client.protocols line in table 'Table 8-3 System 
Properties and Customized Items" in JSSE Reference Guides:

"https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9

For your quick reference, I copied the note here:

---------------
Customized Item:
Default handshaking protocols for TLS/DTLS clients.

Notes:
To enable specific SunJSSE protocols on the client, specify them in a 
comma-separated list within quotation marks; all other supported 
protocols are not enabled on the client
For example,

     If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default 
protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while 
SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled

     If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting 
on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
---------------


> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
It is correct that the property impact the default SSLContext only.  The 
default SSLContext instance could get from:
     SSLContext.getInstance("Default");
     SSLContext.getInstance("TLS");
     SSLContext.getInstance("DTLS");


> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
Yes.

Xuelei

> -Chris.
> 
>> On 26 Mar 2020, at 16:58, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead;  Otherwise, use TLSv1.3 and TLSv1.2.
>>
>> There may be a couple of issues:
>> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
>> For example:
>>    System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
>>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
>>
>> 2. TLSv1.2 may be not supported in the SSLContext.
>> For example:
>>    SSLContext context = SSLContext.getInstance("DTLS");
>>    HttpClient.newBuilder().sslContext(context)...
>>
>> 3. The application may not want to use TLS 1.2.
>> For example:
>>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
>>
>> The System property may be shared by code other than httpclient.  So the setting may not consider the impact on httpclient.
>>
>> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack.
>>
>> Xuelei
>>
>> On 3/26/2020 9:28 AM, Sean Mullan wrote:
>>> Cross-posting to security-dev as this involves TLS/SSL configuration.
>>> --Sean
>>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Request to have my fix reviewed for issues:
>>>>
>>>>       JDK-8239595 : ssl context version is not respected
>>>>       JDK-8239594 : jdk.tls.client.protocols is not respected
>>>>
>>>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
>>>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(),
>>>> as the latter does not respect the context parameters set by the user.
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
>>>>
>>>> -- Rahul
> 

From chris.hegarty at oracle.com  Fri Mar 27 17:36:46 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Mar 2020 17:36:46 +0000
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
Message-ID: <ECECB32C-0E20-4672-B15D-C8366190EB7D@oracle.com>

Thank you Xuelei, this very helpful.

Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page.

> On 27 Mar 2020, at 16:23, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 3/27/2020 5:52 AM, Chris Hegarty wrote:
>> Xuelei,
>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides:
> 
> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
> 
> For your quick reference, I copied the note here:
> 
> ---------------
> Customized Item:
> Default handshaking protocols for TLS/DTLS clients.
> 
> Notes:
> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client

?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right? 

getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right?

The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols()  only getDefaultSSLParameters().getProtocols(), right? In which case, getDefaultSSLParameters().getProtocols() returns the value of  `jdk.tls.client.protocols`.

> For example,
> 
>    If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
> 
>    If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
> ---------------

Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology.

The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior.

>> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
> It is correct that the property impact the default SSLContext only.  The default SSLContext instance could get from:
>    SSLContext.getInstance("Default");
>    SSLContext.getInstance("TLS");
>    SSLContext.getInstance("DTLS?);

Thanks for this clarification.

> 
>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
> Yes.

Thanks,
-Chris.




From xuelei.fan at oracle.com  Fri Mar 27 17:47:37 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 27 Mar 2020 10:47:37 -0700
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <ECECB32C-0E20-4672-B15D-C8366190EB7D@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <ECECB32C-0E20-4672-B15D-C8366190EB7D@oracle.com>
Message-ID: <e66bfe0e-816a-7678-f7a7-d52cb51f9968@oracle.com>

On 3/27/2020 10:36 AM, Chris Hegarty wrote:
> Thank you Xuelei, this very helpful.
> 
> Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page.
> 
>> On 27 Mar 2020, at 16:23, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> On 3/27/2020 5:52 AM, Chris Hegarty wrote:
>>> Xuelei,
>>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
>>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
>> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides:
>>
>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
>>
>> For your quick reference, I copied the note here:
>>
>> ---------------
>> Customized Item:
>> Default handshaking protocols for TLS/DTLS clients.
>>
>> Notes:
>> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client
> 
> ?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right?
> 
Yes.

> getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right?
> 
Yes.

> The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols()  only getDefaultSSLParameters().getProtocols(), right?
Yes.

> In which case, getDefaultSSLParameters().getProtocols() returns the value of  `jdk.tls.client.protocols`.
> 
>> For example,
>>
>>     If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
>>
>>     If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
>> ---------------
> 
> Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology.
> 
> The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior.
> 
The client refer to the client side SSLSocket or SSLEngine created with 
the default SSLContext.  or example:
     SSLContext sslContext = SSLContext.getInstance("TLS");
     SSLEngine sslEngine = sslContext.createSSLEngine();
     sslEngine.setUseClientMode(true);

The sslEngine object is a client that impacted by the property.

While if
     sslEngine.setUseClientMode(false);

then the object should not be impacted by the property.

Xuelei

>>> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
>> It is correct that the property impact the default SSLContext only.  The default SSLContext instance could get from:
>>     SSLContext.getInstance("Default");
>>     SSLContext.getInstance("TLS");
>>     SSLContext.getInstance("DTLS?);
> 
> Thanks for this clarification.
> 
>>
>>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
>> Yes.
> 
> Thanks,
> -Chris.
> 
> 
> 

From chris.hegarty at oracle.com  Fri Mar 27 17:50:38 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Mar 2020 17:50:38 +0000
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <e66bfe0e-816a-7678-f7a7-d52cb51f9968@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <ECECB32C-0E20-4672-B15D-C8366190EB7D@oracle.com>
 <e66bfe0e-816a-7678-f7a7-d52cb51f9968@oracle.com>
Message-ID: <A60438AE-BA46-49AF-BF6E-0B7FD09C1A3B@oracle.com>

Thank you for these clarifications. We will now consider how these affect, if at all, the HTTP Client.

-Chris.

> On 27 Mar 2020, at 17:47, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 3/27/2020 10:36 AM, Chris Hegarty wrote:
>> Thank you Xuelei, this very helpful.
>> Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page.
>>> On 27 Mar 2020, at 16:23, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> On 3/27/2020 5:52 AM, Chris Hegarty wrote:
>>>> Xuelei,
>>>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
>>>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
>>> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides:
>>> 
>>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
>>> 
>>> For your quick reference, I copied the note here:
>>> 
>>> ---------------
>>> Customized Item:
>>> Default handshaking protocols for TLS/DTLS clients.
>>> 
>>> Notes:
>>> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client
>> ?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right?
> Yes.
> 
>> getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right?
> Yes.
> 
>> The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols()  only getDefaultSSLParameters().getProtocols(), right?
> Yes.
> 
>> In which case, getDefaultSSLParameters().getProtocols() returns the value of  `jdk.tls.client.protocols`.
>>> For example,
>>> 
>>>    If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
>>> 
>>>    If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
>>> ---------------
>> Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology.
>> The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior.
> The client refer to the client side SSLSocket or SSLEngine created with the default SSLContext.  or example:
>    SSLContext sslContext = SSLContext.getInstance("TLS");
>    SSLEngine sslEngine = sslContext.createSSLEngine();
>    sslEngine.setUseClientMode(true);
> 
> The sslEngine object is a client that impacted by the property.
> 
> While if
>    sslEngine.setUseClientMode(false);
> 
> then the object should not be impacted by the property.
> 
> Xuelei
> 
>>>> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
>>> It is correct that the property impact the default SSLContext only.  The default SSLContext instance could get from:
>>>    SSLContext.getInstance("Default");
>>>    SSLContext.getInstance("TLS");
>>>    SSLContext.getInstance("DTLS?);
>> Thanks for this clarification.
>>> 
>>>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
>>> Yes.
>> Thanks,
>> -Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200327/90f899f0/attachment-0001.htm>

From jai.forums2013 at gmail.com  Sat Mar 28 06:43:29 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 28 Mar 2020 12:13:29 +0530
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems to
 be causing issues
Message-ID: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>

There's an issue raised in Quarkus repo[1], where Apache Kafka
(embedded) no longer starts on Java 14. From what I can see the root
cause is this[2].

JDK-8225499[3] changed the implementation (and even the javadoc) of the
InetSocketAddress.toString() which now reads[4]:

"...

If the address is unresolved, <unresolved> is displayed in place of the
address literal.

"

Previously, until as recent as Java 13[5], it used to be:

"...
If the address is unresolved then the part before the colon will only
contain the hostname.

"

So this looks like an intentional(?) breakage in that toString() API
semantics? I do see that it did make it to the release notes of this
version, but given how conservative Java has been in terms of breaking
changes, is this change too quick in introducing such a breaking change?

By the way, keeping aside the breaking nature of this change, the
current javadoc, I think doesn't reflect what the current implementation
returns for unresolved addresses. The javadoc states:

"If the address is unresolved, |<unresolved>| is displayed in place of
the address literal."

Note, the "in place of the address literal" part. However, in the
current implementation[6], it returns something like -
"localhost/<unresolved>:2182". So it doesn't just display the
"<unresolved>" literal in the address part but suffixes it to the
address part. Should that be clarified?


[1] https://github.com/quarkusio/quarkus/issues/8212

[2] https://github.com/quarkusio/quarkus/issues/8212#issuecomment-605403656

[3] https://bugs.openjdk.java.net/browse/JDK-8225499

[4]
https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/InetSocketAddress.html#toString()

[5]
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/net/InetSocketAddress.html#toString()

[6]
https://hg.openjdk.java.net/jdk/jdk/file/f2a0b262efea/src/java.base/share/classes/java/net/InetSocketAddress.java#l108

-Jaikiran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200328/d3d1f617/attachment.htm>

From ivan.gerasimov at oracle.com  Sun Mar 29 04:44:08 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 28 Mar 2020 21:44:08 -0700
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
Message-ID: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>

Hello!

The fix follows up on JDK-8241727 [1].

This is a javadoc/comments only fix in the net and nio areas.

The changes are to remove redundant empty lines, correct indentation, or 
otherwise restore harmony.

Would you please help review this rather technical fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727
WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/

Thank in advance!

[1] https://bugs.openjdk.java.net/browse/JDK-8241727

-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Sun Mar 29 08:02:08 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 29 Mar 2020 09:02:08 +0100
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
Message-ID: <281bf800-77de-2159-4367-0f83182a2753@oracle.com>

On 29/03/2020 05:44, Ivan Gerasimov wrote:
> Hello!
>
> The fix follows up on JDK-8241727 [1].
>
> This is a javadoc/comments only fix in the net and nio areas.
>
> The changes are to remove redundant empty lines, correct indentation, 
> or otherwise restore harmony.
>
> Would you please help review this rather technical fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727
> WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/
I assume you meant this link:

http://cr.openjdk.java.net/~igerasim/8241760/00/webrev/

and the changes there look good.

-Alan

From pavel.rappo at oracle.com  Sun Mar 29 21:43:43 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Sun, 29 Mar 2020 22:43:43 +0100
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
Message-ID: <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>

Ivan,

1. ByteBuffered has an awkwardly looking top-level doc comment markup/formatting.
The "payload" begins on the same line as the /** marker. Also, the <p> tag is
weirdly placed. Since you have fixed similar issues already (URLConnection),
you could probably do the same here. Your call.

2. I know you probably wanted to confine this change to just the formatting,
but... maybe we could fix the "protocol handers" typo as an exception?

Other than that, the changes look good. Thanks for doing this!

-Pavel

> On 29 Mar 2020, at 05:44, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> The fix follows up on JDK-8241727 [1].
> 
> This is a javadoc/comments only fix in the net and nio areas.
> 
> The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony.
> 
> Would you please help review this rather technical fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727
> WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/
> 
> Thank in advance!
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8241727
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From ivan.gerasimov at oracle.com  Mon Mar 30 02:34:00 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 29 Mar 2020 19:34:00 -0700
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
 <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>
Message-ID: <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>

Thank you Alan and Pavel!

My apologies for a wrong link in the initial request.

Here's the new webrev with the changes suggested by Pavel:

http://cr.openjdk.java.net/~igerasim/8241760/01/webrev/

With kind regards,

Ivan G.


On 3/29/20 2:43 PM, Pavel Rappo wrote:
> Ivan,
>
> 1. ByteBuffered has an awkwardly looking top-level doc comment markup/formatting.
> The "payload" begins on the same line as the /** marker. Also, the <p> tag is
> weirdly placed. Since you have fixed similar issues already (URLConnection),
> you could probably do the same here. Your call.
>
> 2. I know you probably wanted to confine this change to just the formatting,
> but... maybe we could fix the "protocol handers" typo as an exception?
>
> Other than that, the changes look good. Thanks for doing this!
>
> -Pavel
>
>> On 29 Mar 2020, at 05:44, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> Hello!
>>
>> The fix follows up on JDK-8241727 [1].
>>
>> This is a javadoc/comments only fix in the net and nio areas.
>>
>> The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony.
>>
>> Would you please help review this rather technical fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/
>>
>> Thank in advance!
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8241727
>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>>
-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Mon Mar 30 08:01:17 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Mar 2020 09:01:17 +0100
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
Message-ID: <7d37a361-6447-f37e-4000-d2acb901a9ef@oracle.com>

On 28/03/2020 06:43, Jaikiran Pai wrote:
>
> There's an issue raised in Quarkus repo[1], where Apache Kafka 
> (embedded) no longer starts on Java 14. From what I can see the root 
> cause is this[2].
>
> JDK-8225499[3] changed the implementation (and even the javadoc) of 
> the InetSocketAddress.toString()
>
For the Quarkus/Kafka issue, do you know if it really needs to parse the 
String representation? Just curious why it doesn't use getHostString. To 
my knowledge anyway, this is the first report of an issue with this 
spec/implementation change. It's a reminder that we need a lot more 
testing of the JDK early access builds to gauge the impact of fixes like 
this.

As I think you've found, the spec/implementation change in Java SE 14 
has two parts.

The change to surround an IPv6 literal address (and maybe the scope ID) 
in square brackets. Anything that parses a string that encodes an IP 
address and port, say the host component in a URI string, will have seen 
this already.

The change to concatenate "/<unresolved>" to unresolved addresses. I 
think it's important to observe that an InetSocketAddress can be created 
with nonsensical input so it's easy to confuse code that parses the 
string representation, e.g. new InetSocketAddress("java.com/1.2.3.4", 
80) creates an InetSocketAddress that is unresolved but its string 
representation (when run on JDK 13 or older) would suggest otherwise. 
I'll have to defer to Julia, Daniel and Chris to see what other options 
were considered. I could imagine conditionally adding ""/<unresolved>"? 
based on whether host string contains slash and/or colon characters. 
That might reduce the compatibility impact but at the cost of additional 
complexity and/or non-obvious failures in code that encounter 
nonsensical string on rare occasions.

-Alan

From chris.hegarty at oracle.com  Mon Mar 30 08:19:21 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 30 Mar 2020 09:19:21 +0100
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
Message-ID: <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>

Hi Jaikiran,

Thank you for posting this message to net-dev.

TL;DR seems like the specific issue raised against Quarkus has been resolved ( by upgrading to a more recent version of ZooKeeper ). 

> On 28 Mar 2020, at 06:43, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> There's an issue raised in Quarkus repo[1], where Apache Kafka (embedded) no longer starts on Java 14. From what I can see the root cause is this[2].
> 
> JDK-8225499[3] changed the implementation (and even the javadoc) of the InetSocketAddress.toString() which now reads[4]:
> 
> "... 
> 
> If the address is unresolved, <unresolved> is displayed in place of the address literal.
> 
> "
> 
> Previously, until as recent as Java 13[5], it used to be:
> 
> "...
> If the address is unresolved then the part before the colon will only contain the hostname.
> 
> "
> 
> So this looks like an intentional(?)
> 
Correct. This is an intentional change, to improve the string representation. See the following CSR https://bugs.openjdk.java.net/browse/JDK-8232002 
> breakage in that toString() API semantics?
> 
FTR - I take exception with the term ?breakage? - The change is intentional, consideration given to the compatibility impact, and a release note published. InetSocketAddress::getHostString was added in Java 7 to retrieve the host, or address, string representation.

> I do see that it did make it to the release notes of this version, but given how conservative Java has been in terms of breaking changes, is this change too quick in introducing such a breaking change?
> 
No. As above, code should really be using getHostString, which has been available since July 2011. I do not consider this too quick.
> By the way, keeping aside the breaking nature of this change, the current javadoc, I think doesn't reflect what the current implementation returns for unresolved addresses. The javadoc states:
> 
> "If the address is unresolved, <unresolved> is displayed in place of the address literal."
> 
> Note, the "in place of the address literal" part. However, in the current implementation[6], it returns something like - "localhost/<unresolved>:2182". So it doesn't just display the "<unresolved>" literal in the address part but suffixes it to the address part. Should that be clarified?
> 
The InetSocketAddress string representation defers, partly, to InetAddress::toString, which specifies the ?hostname / literal IP address? form. It is this address literal that is replaced with ?<unresolved>?. If this is not clear from this spec, then it can be clarified.

Can we check if the most recent ZooKeeper is still calling toString, using getHostString, or doing something else?

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200330/dd29e152/attachment.htm>

From pavel.rappo at oracle.com  Mon Mar 30 09:47:56 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 30 Mar 2020 10:47:56 +0100
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
 <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>
 <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>
Message-ID: <12DCDBDA-542B-4DAC-8685-E02006F932E6@oracle.com>

Looks good. Thanks.

> On 30 Mar 2020, at 03:34, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Thank you Alan and Pavel!
> 
> My apologies for a wrong link in the initial request.
> 
> Here's the new webrev with the changes suggested by Pavel:
> 
> http://cr.openjdk.java.net/~igerasim/8241760/01/webrev/
> 
> With kind regards,
> 
> Ivan G.
> 
> 
> On 3/29/20 2:43 PM, Pavel Rappo wrote:
>> Ivan,
>> 
>> 1. ByteBuffered has an awkwardly looking top-level doc comment markup/formatting.
>> The "payload" begins on the same line as the /** marker. Also, the <p> tag is
>> weirdly placed. Since you have fixed similar issues already (URLConnection),
>> you could probably do the same here. Your call.
>> 
>> 2. I know you probably wanted to confine this change to just the formatting,
>> but... maybe we could fix the "protocol handers" typo as an exception?
>> 
>> Other than that, the changes look good. Thanks for doing this!
>> 
>> -Pavel
>> 
>>> On 29 Mar 2020, at 05:44, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>> 
>>> Hello!
>>> 
>>> The fix follows up on JDK-8241727 [1].
>>> 
>>> This is a javadoc/comments only fix in the net and nio areas.
>>> 
>>> The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony.
>>> 
>>> Would you please help review this rather technical fix?
>>> 
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241727
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8241727/00/webrev/
>>> 
>>> Thank in advance!
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8241727
>>> 
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>>> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From daniel.fuchs at oracle.com  Mon Mar 30 12:27:00 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 30 Mar 2020 13:27:00 +0100
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
 <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>
 <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>
Message-ID: <a07a301b-5211-4257-bfdf-c912b7968a8c@oracle.com>

Looks good to me Ivan.

Thanks for this cleanup!


best regards,

-- daniel

On 30/03/2020 03:34, Ivan Gerasimov wrote:
> Thank you Alan and Pavel!
> 
> My apologies for a wrong link in the initial request.
> 
> Here's the new webrev with the changes suggested by Pavel:
> 
> http://cr.openjdk.java.net/~igerasim/8241760/01/webrev/
> 
> With kind regards,
> 
> Ivan G.

From rahul.r.yadav at oracle.com  Mon Mar 30 14:32:03 2020
From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com)
Date: Mon, 30 Mar 2020 15:32:03 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <A60438AE-BA46-49AF-BF6E-0B7FD09C1A3B@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <ECECB32C-0E20-4672-B15D-C8366190EB7D@oracle.com>
 <e66bfe0e-816a-7678-f7a7-d52cb51f9968@oracle.com>
 <A60438AE-BA46-49AF-BF6E-0B7FD09C1A3B@oracle.com>
Message-ID: <4a9ef2b6-f5d1-2b0b-709e-c6a45a22d5be@oracle.com>

The current fix does not affect the scenarios discussed earlier(that is 
a broader discussion,may be a different bug/enhancement).
The scenarios would be vaild even if the fix would not have been in place.

-Rahul

On 27/03/2020 17:50, Chris Hegarty wrote:
> Thank you for these clarifications. We will now consider how these 
> affect, if at all, the HTTP Client.
>
> -Chris.
>
>> On 27 Mar 2020, at 17:47, Xuelei Fan <xuelei.fan at oracle.com 
>> <mailto:xuelei.fan at oracle.com>> wrote:
>>
>> On 3/27/2020 10:36 AM, Chris Hegarty wrote:
>>> Thank you Xuelei, this very helpful.
>>> Sorry, but I am going to ask just a few more clarifying questions to 
>>> make sure that we?re on the same page.
>>>> On 27 Mar 2020, at 16:23, Xuelei Fan <xuelei.fan at oracle.com 
>>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>>
>>>> On 3/27/2020 5:52 AM, Chris Hegarty wrote:
>>>>> Xuelei,
>>>>> Before commenting further on the interaction of the HTTP Client 
>>>>> with various contorted configurations, I would like to get a 
>>>>> better understanding of the `jdk.tls.client.protocols` property.
>>>>> Is there a specification or other documentation describing 
>>>>> `jdk.tls.client.protocols` ?
>>>> See the jdk.tls.client.protocols line in table 'Table 8-3 System 
>>>> Properties and Customized Items" in JSSE Reference Guides:
>>>>
>>>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
>>>>
>>>> For your quick reference, I copied the note here:
>>>>
>>>> ---------------
>>>> Customized Item:
>>>> Default handshaking protocols for TLS/DTLS clients.
>>>>
>>>> Notes:
>>>> To enable specific SunJSSE protocols on the client, specify them in 
>>>> a comma-separated list within quotation marks; all other supported 
>>>> protocols are not enabled on the client
>>> ?supported? here means protocols that are supported by the provider, 
>>> and may be used within a specific context. This translates, for the 
>>> default SSLContext, to the API call 
>>> getSupportedSSLParameters().getProtocols(), right?
>> Yes.
>>
>>> getSupportedSSLParameters().getProtocols() returns a superset of 
>>> getDefaultSSLParameters().getProtocols(). Conversely, 
>>> getDefaultSSLParameters().getProtocols() is a strict subset of 
>>> getSupportedSSLParameters().getProtocols(), right?
>> Yes.
>>
>>> The `jdk.tls.client.protocols` property has no affect on 
>>> getSupportedSSLParameters().getProtocols() ?only 
>>> getDefaultSSLParameters().getProtocols(), right?
>> Yes.
>>
>>> In which case, getDefaultSSLParameters().getProtocols() returns the 
>>> value of ?`jdk.tls.client.protocols`.
>>>> For example,
>>>>
>>>> ???If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default 
>>>> protocol settings on the client for TLSv1 and TLSv1.1 are enabled, 
>>>> while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
>>>>
>>>> ???If jdk.tls.client.protocols="DTLSv1.2" , then the protocol 
>>>> setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not 
>>>> enabled
>>>> ---------------
>>> Seems that the term ?client? here is referring to client-initiated 
>>> exchanges, rather than any specific technology.
>>> The assumption, which is reasonable, is that ?clients? will use the 
>>> default context. Again, this is reasonable default out-of-the-box 
>>> behavior.
>> The client refer to the client side SSLSocket or SSLEngine created 
>> with the default SSLContext. ?or example:
>> ???SSLContext sslContext = SSLContext.getInstance("TLS");
>> ???SSLEngine sslEngine = sslContext.createSSLEngine();
>> ???sslEngine.setUseClientMode(true);
>>
>> The sslEngine object is a client that impacted by the property.
>>
>> While if
>> ???sslEngine.setUseClientMode(false);
>>
>> then the object should not be impacted by the property.
>>
>> Xuelei
>>
>>>>> It is my understanding that the property only affects the 
>>>>> *default* protocol?s ( not the supported protocols ) of the 
>>>>> *default* context. That is, the context returned by 
>>>>> `SSLContext.getInstance("Default?)`,
>>>> It is correct that the property impact the default SSLContext only. 
>>>> ?The default SSLContext instance could get from:
>>>> ???SSLContext.getInstance("Default");
>>>> ???SSLContext.getInstance("TLS");
>>>> ???SSLContext.getInstance("DTLS?);
>>> Thanks for this clarification.
>>>>
>>>>> and the protocol values returned by the following invocation on 
>>>>> that context `getDefaultSSLParameters().getProtocols()`. Is this 
>>>>> correct? If not, what does it do?
>>>> Yes.
>>> Thanks,
>>> -Chris.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200330/1b6794a2/attachment-0001.htm>

From patrick.concannon at oracle.com  Mon Mar 30 18:27:23 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Mon, 30 Mar 2020 19:27:23 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
Message-ID: <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>

Hi Alan,

Thanks for your feedback.

I've incorporated your comments into the revised webrev below.

http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/


With regards to the UnreferencedXXX tests, I can take a look at these 
separately.

-Patrick

On 23/03/2020 18:59, Alan Bateman wrote:
> On 23/03/2020 16:37, Patrick Concannon wrote:
>> This is a request for review for the implementation changes for JEP 
>> 373: 'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been 
>> created [2].
>>
>> The implementation of JEP 373 can be viewed on the JDK-8230211-branch 
>> in the sandbox [3].
>>
>> A link to the webrev with the cumulated changes is available below [4].
>>
>> The sources changes are limited to five files. The webrev also adds 
>> additional tests while a selection of existing tests have been 
>> updated to run with both the old and new implementation. Please refer 
>> to the JEP [1] for more information.
> This is a good work and easy to review.
>
> As you know, I would have preferred to see the creation of the 
> delegate separated from the configuration (like we do with impls) but 
> I think you and Daniel want to keep the version you have, okay. I'm 
> also not too keen on another temporary solution in advance of any 
> discussion on JDK-8237352 but I guess what you have is okay as it's 
> benign.
>
> Small comments:
>
> DatagramSocket
> - the comments at L117-120, L123-124, and L143-L147 need a tidy up, 
> probably most of them can be replaced with simple one-liners.
> - the use of type.cast at L119 and L1125 looks odd. It might be 
> simpler to just replace L1156 with "return (T) delegate". That would 
> allow you to assign delegate (no need for "adaptor" or oddly named 
> "plainDelegate").
> - I assume the new static final fields can be private too.
> - usePlainDatagramSocketImpl is inconsistent with the equivalent in 
> SocketImpl for the garbage value case. We should try to get those 
> consistent at some point.
> - createDelegate's method description has inconsistent formatting.
> - L1145 should be "initialized = true".
>
> MulticastSocket and NetMulticastSocket look okay. There are probably 
> better names for "NetMulticastSocket" but it's not public so okay. 
> Happy to see NetMulticastSocket.options is an instance field, seems 
> like that bug was lurking for a long time.
>
> DatagramSocketAdaptor - if we are keeping this change then I'd prefer 
> if the comment was cleaned up to be consistent with the other support 
> classes. A one-liner is okay. The "Temporary solution" comment can go 
> away. Also would be good to use 4-space indentation to be consistent 
> with the other support classes.
>
> The changes to run the tests twice is good. The UnreferencedXXX tests 
> are a bit messy and I'm concerned that the changes to these tests make 
> them too hard to maintain. I think we need to find better ways to test 
> that unreferenced sockets are closed so that these tests can be 
> replaced with tests that easy to maintain.
>
> SendBufCheck is puzzling to see in this webrev as it's not part of the 
> JEP. An equivalent of JDK-8239355 that only tests the new 
> implementation (not the old because it's not quite right) would be 
> okay. Alternatively re-visit it as part of JDK-8240901 to test that 
> large datagrams can be sent on the network.
>
> I think that is all I have.
>
> -Alan

From ivan.gerasimov at oracle.com  Mon Mar 30 21:37:32 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 30 Mar 2020 14:37:32 -0700
Subject: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (net and nio)
In-Reply-To: <a07a301b-5211-4257-bfdf-c912b7968a8c@oracle.com>
References: <f8d01f73-a44c-2679-c35f-3f72ae83f80e@oracle.com>
 <FE1F35D9-7449-4439-8BB0-5038C250092C@oracle.com>
 <6124a19e-6205-f278-68f6-ef07093d200e@oracle.com>
 <a07a301b-5211-4257-bfdf-c912b7968a8c@oracle.com>
Message-ID: <1c2250ef-d86f-7c40-40d5-054466909c35@oracle.com>

Thank you guy for your reviews!

Pushed.

On 3/30/20 5:27 AM, Daniel Fuchs wrote:
> Looks good to me Ivan.
>
> Thanks for this cleanup!
>
>
> best regards,
>
> -- daniel
>
> On 30/03/2020 03:34, Ivan Gerasimov wrote:
>> Thank you Alan and Pavel!
>>
>> My apologies for a wrong link in the initial request.
>>
>> Here's the new webrev with the changes suggested by Pavel:
>>
>> http://cr.openjdk.java.net/~igerasim/8241760/01/webrev/
>>
>> With kind regards,
>>
>> Ivan G.

-- 
With kind regards,
Ivan Gerasimov


From patrick.concannon at oracle.com  Tue Mar 31 10:15:44 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 31 Mar 2020 11:15:44 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket
 and DatagramChannel when sending a DatagramPacket to port 0.'
Message-ID: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>

Hi,

Could someone please review my fix for JDK-8240533 'Inconsistent 
Exceptions are thrown by DatagramSocket and DatagramChannel when sending 
a DatagramPacket to port 0.' ?

Currently, DatagramSocket throws an IOException when sending to port 0, 
and doesn't throw when connecting. DatagramChannel currently throws a 
BindException in both cases.
The fix adds checks for port == 0 to the send and connect methods in 
DatagramSocket and DatagramChannelImpl. This is to ensure that 
consistent Exceptions i.e. SocketExceptions are thrown when trying to 
connect or send to port 0.


bug: https://bugs.openjdk.java.net/browse/JDK-8240533
webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/


Kind regards,

Patrick

From jai.forums2013 at gmail.com  Tue Mar 31 12:17:21 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 31 Mar 2020 17:47:21 +0530
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <7d37a361-6447-f37e-4000-d2acb901a9ef@oracle.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <7d37a361-6447-f37e-4000-d2acb901a9ef@oracle.com>
Message-ID: <2d49743b-7cd7-5732-ed0b-046b6d108f4e@gmail.com>

Hello Alan,

On 30/03/20 1:31 pm, Alan Bateman wrote:
> On 28/03/2020 06:43, Jaikiran Pai wrote:
>>
>> There's an issue raised in Quarkus repo[1], where Apache Kafka
>> (embedded) no longer starts on Java 14. From what I can see the root
>> cause is this[2].
>>
>> JDK-8225499[3] changed the implementation (and even the javadoc) of
>> the InetSocketAddress.toString()
>>
> For the Quarkus/Kafka issue, do you know if it really needs to parse
> the String representation? Just curious why it doesn't use getHostString.

I don't have much knowledge about that library and unfortunately, the
git history on that file where this parsing is happening is very limited
and doesn't show the background about this code.

Either way, looking at the comment in that code which says:

// According to the Java 6 documentation, if the hostname is
??????????? // unresolved, then the string before the colon is the hostname.


it appears that it was added way back during Java 6 days, before the
InetSocketAddress.getHostString() API was introduced in Java 7.

I checked their release page[1] and the 3.4.x series (the one which has
this issue) was released just almost a year back. So I think it might
still be used by many. I'll anyway bring this up in their issue tracker
to get their inputs.

>
> As I think you've found, the spec/implementation change in Java SE 14
> has two parts.
>
> The change to surround an IPv6 literal address (and maybe the scope
> ID) in square brackets. Anything that parses a string that encodes an
> IP address and port, say the host component in a URI string, will have
> seen this already.
>
> The change to concatenate "/<unresolved>" to unresolved addresses. I
> think it's important to observe that an InetSocketAddress can be
> created with nonsensical input so it's easy to confuse code that
> parses the string representation, e.g. new
> InetSocketAddress("java.com/1.2.3.4", 80) creates an InetSocketAddress
> that is unresolved but its string representation (when run on JDK 13
> or older) would suggest otherwise. 

Understood. Thank you!

[1] https://zookeeper.apache.org/releases.html

-Jaikiran



From lance.andersen at oracle.com  Tue Mar 31 12:31:13 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Mar 2020 08:31:13 -0400
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
Message-ID: <039F6BED-AA3B-4406-B7DB-23AEEA7D1FCB@oracle.com>

Hi Patrick,

I think this looks OK.

I might suggest using assertThrows vs expectThrows.  While they are the same,  assertThrows seems more natural and consistent with the other testNG assert methods.

HTH

Best
Lance

> On Mar 31, 2020, at 6:15 AM, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> Hi,
> 
> Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ?
> 
> Currently, DatagramSocket throws an IOException when sending to port 0, and doesn't throw when connecting. DatagramChannel currently throws a BindException in both cases.
> The fix adds checks for port == 0 to the send and connect methods in DatagramSocket and DatagramChannelImpl. This is to ensure that consistent Exceptions i.e. SocketExceptions are thrown when trying to connect or send to port 0.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8240533
> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/
> 
> 
> Kind regards,
> 
> Patrick

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200331/dd149af0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200331/dd149af0/oracle_sig_logo.gif>

From jai.forums2013 at gmail.com  Tue Mar 31 13:06:42 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 31 Mar 2020 18:36:42 +0530
Subject: Java 14 - Change in InetSocketAddress.toString() behaviour seems
 to be causing issues
In-Reply-To: <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
References: <1f7c7405-18b7-8648-5e23-997a2d916b58@gmail.com>
 <2E8A8522-1466-434E-900D-506D9BFC64D7@oracle.com>
Message-ID: <37287689-eab9-9c35-7bf7-96cde44b25c2@gmail.com>

Hello Chris,

On 30/03/20 1:49 pm, Chris Hegarty wrote:
> Hi Jaikiran,
>
> Thank you for posting this message to net-dev.
>
> TL;DR seems like the specific issue raised against Quarkus has been
> resolved ( by upgrading to a more recent version of ZooKeeper ).

That's correct.

>
>> So this looks like an intentional(?)
>>
> Correct. This is an intentional change, to improve the string
> representation. See the following CSR
> https://bugs.openjdk.java.net/browse/JDK-8232002?
>>
>> breakage in that toString() API semantics?
>>
> FTR - I take exception with the term ?breakage? - The change is
> intentional, consideration given to the compatibility impact, and a
> release note published. InetSocketAddress::getHostString was added in
> Java 7 to retrieve the host, or address, string representation.

Sorry about that term, I didn't mean to say that not enough thought was
spent on this change. I merely meant it to mean that the API behaviour
has changed.

>
>> I do see that it did make it to the release notes of this version,
>> but given how conservative Java has been in terms of breaking
>> changes, is this change too quick in introducing such a breaking change?
>>
> No. As above, code should really be using getHostString, which has
> been available since July 2011. I do not consider this too quick.

I agree about the getHostString() API being available since Java 7 days.
What I meant about this possibly being a bit too quick of change is
that, the toString() API of this class, even till Java 13, clearly
states that the part before the colon, of an unresolved address is a
host name. It doesn't however recommend using the getHostString(). So
there could be code which might still be using this API for the
semantics noted in Java 13.

Having said that, I would like to clarify that I don't have anything
against this change. I like that the unresolved address is now more
"visible".

>> By the way, keeping aside the breaking nature of this change, the
>> current javadoc, I think doesn't reflect what the current
>> implementation returns for unresolved addresses. The javadoc states:
>>
>> "If the address is unresolved, |<unresolved>| is displayed in place
>> of the address literal."
>>
>> Note, the "in place of the address literal" part. However, in the
>> current implementation[6], it returns something like -
>> "localhost/<unresolved>:2182". So it doesn't just display the
>> "<unresolved>" literal in the address part but suffixes it to the
>> address part. Should that be clarified?
>>
> The InetSocketAddress string representation defers, partly, to
> InetAddress::toString, which specifies the ?hostname / literal IP
> address? form. It is this address literal that is replaced with
> ?<unresolved>?. If this is not clear from this spec, then it can be
> clarified.
>
Now that you explained it to me, I see what you mean and what that
javadoc means. I hadn't paid attention to the "This String is
constructed by calling toString() on the InetAddress and concatenating
the port number (with a colon)". Looking at the javadoc on
InetAddress.toString(), it does state the returned string to be of the
form "hostname/literal IP address" (example:
google.com/172.217.160.142). So when it says that "<unresolved> is
displayed in place of the address literal", it actually is talking about
the part that follows the "/" character in the output returned by the
InetAddress.toString().

I'll be honest - I didn't even know that up until this release, the
output of this API was something like google.com/172.217.160.142:80. I
had it in my mind that the output was google.com:80. That's why when the
new javadoc said "in place of the address literal", I thought it was
talking about replacing "google.com" with "<unresolved>"

I don't know if it's just me who couldn't fully understand it until this
was explained. For me, a {@link InetSocket.toString()} in the javadoc
and a couple of example representations of what the output of toString()
would look like would have made it easier. But I do understand that the
javadoc may not be the right place for such level of details.

> Can we check if the most recent ZooKeeper is still calling toString,
> using getHostString, or doing something else?
>
My quick look shows that in the newer version of that library there is
no such call (at least not in the context of using the return value to
get hold of the host string). However, I don't have enough experience
with that library. So I'll raise this in their issue tracker and point
them to this thread and see what they say.

-Jaikiran


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200331/d1ac4bbf/attachment-0001.htm>

From Alan.Bateman at oracle.com  Tue Mar 31 13:56:28 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Mar 2020 14:56:28 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
Message-ID: <480a9a69-67df-f9e5-71d2-2d298b4353f1@oracle.com>

On 31/03/2020 11:15, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8240533 'Inconsistent 
> Exceptions are thrown by DatagramSocket and DatagramChannel when 
> sending a DatagramPacket to port 0.' ?
>
> Currently, DatagramSocket throws an IOException when sending to port 
> 0, and doesn't throw when connecting. DatagramChannel currently throws 
> a BindException in both cases.
> The fix adds checks for port == 0 to the send and connect methods in 
> DatagramSocket and DatagramChannelImpl. This is to ensure that 
> consistent Exceptions i.e. SocketExceptions are thrown when trying to 
> connect or send to port 0.
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8240533
> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/
Attempting to send or connect to port 0 is an error and the long 
standing behavior is to throw an IOException or SocketException so I 
think this looks good.

-Alan.

From daniel.fuchs at oracle.com  Tue Mar 31 14:08:57 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 31 Mar 2020 15:08:57 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
Message-ID: <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>

This looks good to me Patrick.

I'm happy to see that all implementations now have a consistent
and predictable behavior.

Also - as Alan noted - this is not really a behavioral change
as some subclass of IOException (or IOException itself) was
already thrown before.

+1

best regards,

-- daniel

On 31/03/2020 11:15, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my fix for JDK-8240533 'Inconsistent 
> Exceptions are thrown by DatagramSocket and DatagramChannel when sending 
> a DatagramPacket to port 0.' ?
> 
> Currently, DatagramSocket throws an IOException when sending to port 0, 
> and doesn't throw when connecting. DatagramChannel currently throws a 
> BindException in both cases.
> The fix adds checks for port == 0 to the send and connect methods in 
> DatagramSocket and DatagramChannelImpl. This is to ensure that 
> consistent Exceptions i.e. SocketExceptions are thrown when trying to 
> connect or send to port 0.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8240533
> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/
> 
> 
> Kind regards,
> 
> Patrick


From Alan.Bateman at oracle.com  Tue Mar 31 14:22:22 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Mar 2020 15:22:22 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
Message-ID: <6a6884f5-f2b5-2249-5c96-8d0be66d5fd6@oracle.com>



On 30/03/2020 19:27, Patrick Concannon wrote:
> Hi Alan,
>
> Thanks for your feedback.
>
> I've incorporated your comments into the revised webrev below.
>
> http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/
>
>
> With regards to the UnreferencedXXX tests, I can take a look at these 
> separately.
I skimmed through webrev.01 and just have a few comments:

NetMulticastSocket.checkOldImpl has been updated to check if the impl is 
null, I assume that is not needed as it is now checked in the constructor.

DatagramSocket.delegate() - I assume the exception message should be 
"Should not get here". An alternative here would be to just assert that 
delegate != null. Either is okay.

DatagramSocket L139-142. This comment/Note seems to be "notes to self" 
for possible future changes and maybe it should be removed to avoid 
confusing readers.

DatagramSocket.createDelegate L1144 can be simplified to "if 
(!initialized && delegate != null)".

DatagramSocketAdaptor uses 4-space indent rather than 8 so probably best 
to keep that style consistent if you can.

The webrev still has SendBufCheck. That is a test for another issue so 
I'll ignore this for now.

The rest looks good and a separate issue to replace the UnreferencedXXX 
tests is okay with me.

-Alan.

From chris.hegarty at oracle.com  Tue Mar 31 14:33:45 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 31 Mar 2020 15:33:45 +0100
Subject: RFR[8240533]: 'Inconsistent Exceptions are thrown by
 DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'
In-Reply-To: <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
References: <6ee50304-1122-64f7-91fe-d3ca6ca33237@oracle.com>
 <6a60e4a1-f9a5-c902-c2be-013d2ed41b40@oracle.com>
Message-ID: <6BC55414-E001-482C-A5B2-F9ACC984A5D0@oracle.com>

Patrick,

> On 31 Mar 2020, at 15:08, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
>> ..
>> bug: https://bugs.openjdk.java.net/browse/JDK-8240533
>> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/

Look good Patrick.

The check is deliberately performed after the security manager checks, right? If so, it is worth asserting this in a test.

-Chris.


From chris.hegarty at oracle.com  Tue Mar 31 17:27:16 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 31 Mar 2020 18:27:16 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
Message-ID: <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>


> On 30 Mar 2020, at 19:27, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> ...
> 
> http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/

This looks very good, a testament to all the prior cleanup work that has already been done.

Just a few comments:

- DatagramSocket::getChannel now stands out a little, since it is one of the few instance methods has still has a non-delegating body. It could optionally delegate, or if not, then NetMulticastSocket doesn?t necessarily need to override it.

- In DatagramSocket::createDelegate, "enable broadcast if possible? - Possibly due to refactoring, but I cannot reconcile this with the old implementation.

  - The createDelegate's @return comment is a bit hard to parse; suggest: "@return {@code null} if {@code bindaddr == NO_DELEGATE}, OTHERWISE returns a delegate for the requested {@code type}"

- The set of socket options is now per datagram/multicast socket instance, rather than on the class of the socket. I don?t think that this is an issue, just an observation and a confirmation that it is deliberate.

-Chris.


From Alan.Bateman at oracle.com  Tue Mar 31 17:46:01 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Mar 2020 18:46:01 +0100
Subject: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'
In-Reply-To: <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
References: <1bd6b5cf-df28-f1ef-45db-722291c8dad1@oracle.com>
 <5e9895b6-3e53-0c53-36ed-73ac9c11bc41@oracle.com>
 <2d283e81-3f0a-2e7c-7346-d7e66cf33cf4@oracle.com>
 <F4316B3E-E027-486B-87B9-6C53B8D3DDC6@oracle.com>
Message-ID: <1fddc076-c824-c9d6-46e8-c07852f71bad@oracle.com>



On 31/03/2020 18:27, Chris Hegarty wrote:
> :
> - In DatagramSocket::createDelegate, "enable broadcast if possible? - Possibly due to refactoring, but I cannot reconcile this with the old implementation.
DatagramSocket is specified to make a best attempt to enable this option 
so I think it's in the right place. At a clean-up, the attempt in 
PDSI.datagramSocketCreate could be removed.

>
> :
>
> - The set of socket options is now per datagram/multicast socket instance, rather than on the class of the socket. I don?t think that this is an issue, just an observation and a confirmation that it is deliberate.
The set of socket options supported by a custom DSI will likely be 
different to the default impl so it needs to be an instance field. I 
suspect this is a long standing bug.

-Alan