From bradford.wetmore at oracle.com  Fri Mar  1 00:26:07 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 28 Feb 2019 16:26:07 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
 <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
Message-ID: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>

AbstractDelegateHttpsURLConnection.java
---------------------------------------
74/88/etc.  I haven't checked for sure, but IIRC we made setNewClient 
public from protected and other such changes in order for these classes 
to use the delegation model and allow calls to both sun/net/www/protocol 
and com/sun/net/ssl/internal/www/protocol...  Should the delegation code 
be stripped out, and these methods be set back to protected?

ProviderConfig.java
-------------------
I think we're over-rotating on this one, I'd be very surprised if anyone 
is still using com.sun.net.ssl.internal.ssl.Provider.  My personal 
preference is to kill it now, but if you really want to keep it, please 
file a bug and commit to a near release so we can finally kill this 
thing off.

test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
--------------------------------------------------------------------
When we opensourced the JSSE code, we left some of the javax and com 
tests in the com/sun/net/ssl test directory.  The test names are very 
similar, with the exception of the Com/Javax prefix.  The tests were 
identical, with the exception of whether they called into the com or 
javax APIs.

Here you are deleting the ComTrustManagerFactoryImpl test which is 
probably correct, but should you also be deleting the 
JavaxTrustManagerFactoryImpl test as well?  Please check that we didn't 
get too carried away and are deleting still valid tests.

Thanks,

Brad


On 2/26/2019 7:33 AM, Chris Hegarty wrote:
> 
>> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> <Loop in net-dev>
>>
>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as public.  We may need to re-org the code later, but it is out of the scope of this update.
>>
>> Here is the new webrev (only AbstractDelegateHttpsURLConnection updated):
>>     http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
> 
> I think that this is probably ok ( since the package is not exported ),
> but it seems a little distasteful to not have the API move through
> the terminal deprecation route before being removed.
> 
> -Chris.
> 

From xuelei.fan at oracle.com  Fri Mar  1 16:27:47 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 1 Mar 2019 08:27:47 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
 <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
 <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>
Message-ID: <906d46a3-b26c-3cae-2e5a-827fbfff7435@oracle.com>

On 2/28/2019 4:26 PM, Bradford Wetmore wrote:
> AbstractDelegateHttpsURLConnection.java
> ---------------------------------------
> 74/88/etc.? I haven't checked for sure, but IIRC we made setNewClient 
> public from protected and other such changes in order for these classes 
> to use the delegation model and allow calls to both sun/net/www/protocol 
> and com/sun/net/ssl/internal/www/protocol...? Should the delegation code 
> be stripped out, and these methods be set back to protected?
> 
It should be safe to use "protected", but it's less risky to keep it 
unchanged.  I agree that the delegation code should be stripped out. 
The HttpsURLConnection implementation could be re-designed.  I filed a 
new bug to track the enhancement (JDK-8219987).

> ProviderConfig.java
> -------------------
> I think we're over-rotating on this one, I'd be very surprised if anyone 
> is still using com.sun.net.ssl.internal.ssl.Provider.? My personal 
> preference is to kill it now, but if you really want to keep it, please 
> file a bug and commit to a near release so we can finally kill this 
> thing off.
> 
I would like do it later as the old java.security use this string, and 
I'm not sure if someone really use it in their application.  It is safer 
to fix in a separate bug.  I filled a new bug to tack the update 
(JDK-8219989).

> test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
> test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
> --------------------------------------------------------------------
> When we opensourced the JSSE code, we left some of the javax and com 
> tests in the com/sun/net/ssl test directory.? The test names are very 
> similar, with the exception of the Com/Javax prefix.? The tests were 
> identical, with the exception of whether they called into the com or 
> javax APIs.
> 
> Here you are deleting the ComTrustManagerFactoryImpl test which is 
> probably correct, but should you also be deleting the 
> JavaxTrustManagerFactoryImpl test as well?? Please check that we didn't 
> get too carried away and are deleting still valid tests.
> 
They are helper classes and used by ProviderTest, which is used to test 
the com.sun.net.ssl wrappers.

Thanks,
Xuelei

> Thanks,
> 
> Brad
> 
> 
> On 2/26/2019 7:33 AM, Chris Hegarty wrote:
>>
>>> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> <Loop in net-dev>
>>>
>>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection 
>>> methods as public.? We may need to re-org the code later, but it is 
>>> out of the scope of this update.
>>>
>>> Here is the new webrev (only AbstractDelegateHttpsURLConnection 
>>> updated):
>>> ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
>>
>> I think that this is probably ok ( since the package is not exported ),
>> but it seems a little distasteful to not have the API move through
>> the terminal deprecation route before being removed.
>>
>> -Chris.
>>

From raell at web.de  Sun Mar 10 19:24:18 2019
From: raell at web.de (raell at web.de)
Date: Sun, 10 Mar 2019 20:24:18 +0100
Subject: Disable TLS 1.3 backward compatibility mode?
Message-ID: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190310/4543562e/attachment.html>

From sean.mullan at oracle.com  Mon Mar 11 12:23:54 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 11 Mar 2019 08:23:54 -0400
Subject: Disable TLS 1.3 backward compatibility mode?
In-Reply-To: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>
References: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>
Message-ID: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com>

-bcc net-dev

Copying security-dev as TLS 1.3 topics are more appropriate for that 
mailing list.

--Sean

On 3/10/19 3:24 PM, raell at web.de wrote:
> Dear,
> the Java TLS 1.3 implementation supports middlebox compatibility (e.g. 
> sends a non-empty session id and a ChangeCipherSpec message). Out of 
> interest: Is it possible to disable this compatibility mode?
> Regards, Ralph

From aeubanks at google.com  Mon Mar 11 16:55:03 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 11 Mar 2019 09:55:03 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
Message-ID: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8220083
webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/

First of a few ipv6 patches to come.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/2dafa7d4/attachment.html>

From chris.hegarty at oracle.com  Mon Mar 11 17:03:59 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 11 Mar 2019 17:03:59 +0000
Subject: RFR 8184315: Typo in java.net.JarURLConnection.getCertificates()
 method documentation
Message-ID: <b8820e12-8b66-9e91-9732-6886db22020a@oracle.com>

Trivial typo fixes to: 1) use the simple present tense of the verb, and
2) correctly pluralize the return value. Similar to that of
JarEntry::getCertificates.

--- a/src/java.base/share/classes/java/net/JarURLConnection.java
+++ b/src/java.base/share/classes/java/net/JarURLConnection.java
@@ -279,35 +279,35 @@
       ....

      /**
-     * Return the Certificate object for this connection if the URL
+     * Returns the Certificate objects for this connection if the URL
       * for it points to a JAR file entry, null otherwise. This method
       * can only be called once
       * the connection has been completely verified by reading
       * from the input stream until the end of the stream has been
       * reached. Otherwise, this method will return {@code null}
       *
       * @return the Certificate object for this connection if the URL
       * for it points to a JAR file entry, null otherwise.
       *
       * @exception IOException if getting the JAR entry causes an
       * IOException to be thrown.
       *
       * @see #getJarEntry
       */
      public java.security.cert.Certificate[] getCertificates()
           throws IOException

-Chris.

From chris.hegarty at oracle.com  Mon Mar 11 17:06:02 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 11 Mar 2019 17:06:02 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
Message-ID: <02cf0009-2d17-3c3e-29bf-839b025628eb@oracle.com>

Arthur,

On 11/03/2019 16:55, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
> webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/

In principle, I think this is good. I want to run some tests with your
patch, and do a detailed review. Will reply with results of such soon.

-Chris.


From daniel.fuchs at oracle.com  Mon Mar 11 17:09:28 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 11 Mar 2019 17:09:28 +0000
Subject: RFR 8184315: Typo in java.net.JarURLConnection.getCertificates()
 method documentation
In-Reply-To: <b8820e12-8b66-9e91-9732-6886db22020a@oracle.com>
References: <b8820e12-8b66-9e91-9732-6886db22020a@oracle.com>
Message-ID: <14a51a14-4d32-f6d1-3065-80936e877068@oracle.com>

Looks good Chris.

best regards,

-- daniel

On 11/03/2019 17:03, Chris Hegarty wrote:
> Trivial typo fixes to: 1) use the simple present tense of the verb, and
> 2) correctly pluralize the return value. Similar to that of
> JarEntry::getCertificates.
> 
> --- a/src/java.base/share/classes/java/net/JarURLConnection.java
> +++ b/src/java.base/share/classes/java/net/JarURLConnection.java
> @@ -279,35 +279,35 @@
>  ????? ....
> 
>  ???? /**
> -???? * Return the Certificate object for this connection if the URL
> +???? * Returns the Certificate objects for this connection if the URL
>  ????? * for it points to a JAR file entry, null otherwise. This method
>  ????? * can only be called once
>  ????? * the connection has been completely verified by reading
>  ????? * from the input stream until the end of the stream has been
>  ????? * reached. Otherwise, this method will return {@code null}
>  ????? *
>  ????? * @return the Certificate object for this connection if the URL
>  ????? * for it points to a JAR file entry, null otherwise.
>  ????? *
>  ????? * @exception IOException if getting the JAR entry causes an
>  ????? * IOException to be thrown.
>  ????? *
>  ????? * @see #getJarEntry
>  ????? */
>  ???? public java.security.cert.Certificate[] getCertificates()
>  ????????? throws IOException
> 
> -Chris.


From daniel.fuchs at oracle.com  Mon Mar 11 17:15:52 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 11 Mar 2019 17:15:52 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
Message-ID: <43473661-f736-7fb1-2f81-f8e8566f01ac@oracle.com>

Hi Arthur,

I believe this is generally good.

The question I have is whether the URLs that use "127.0.0.1"
should also be changed to to use whatever address is returned
InetAddress.getLoopbackAddress(). If it is needed it may
require a bit more coding to ensure that [ ] are correctly
added if the returned address is IPv6.

Also please update the copyright years in the files you're
changing.

best regards,

-- daniel

On 11/03/2019 16:55, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
> webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/
> 
> First of a few ipv6 patches to come.


From martinrb at google.com  Mon Mar 11 17:30:54 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Mar 2019 10:30:54 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <43473661-f736-7fb1-2f81-f8e8566f01ac@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <43473661-f736-7fb1-2f81-f8e8566f01ac@oracle.com>
Message-ID: <CA+kOe09k-r=wWSGurbeO13_mLxAN7e0H4RrkkryhCto9mfbSVw@mail.gmail.com>

On Mon, Mar 11, 2019 at 10:18 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

>
> Also please update the copyright years in the files you're
> changing.
>
> Google policy is to leave Copyright years in source files untouched.
Especially another company's!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/8ff39ee0/attachment-0001.html>

From martinrb at google.com  Mon Mar 11 17:36:23 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Mar 2019 10:36:23 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
Message-ID: <CA+kOe0-7pcJk56WrkYawG1X-6a8-o7zSuGoi3YbZqxb57Y0XgA@mail.gmail.com>

Tested with
$ make test TEST="test/jdk/com/sun/net/httpserver
test/jdk/com/sun/nio/ test/jdk/java/net  test/jdk/java/nio/channels
test/jdk/java/rmi/transport/ test/jdk/jdk/net/ test/jdk/sun/net/"


That's useful information, but unfortunately jcheck will reject it.  Please
edit the commit metadata to contain only the format documented here:
http://openjdk.java.net/guide/producingChangeset.html#create
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/19cee83c/attachment.html>

From michael.x.mcmahon at oracle.com  Mon Mar 11 17:38:08 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 11 Mar 2019 17:38:08 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
Message-ID: <5C869D00.50100@oracle.com>

This looks good to me.

- Michael.

On 11/03/2019, 16:55, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
> webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaeubanks/8220083/webrev.00/>
>
> First of a few ipv6 patches to come.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/d799fb49/attachment.html>

From aeubanks at google.com  Mon Mar 11 17:40:45 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 11 Mar 2019 10:40:45 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <43473661-f736-7fb1-2f81-f8e8566f01ac@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <43473661-f736-7fb1-2f81-f8e8566f01ac@oracle.com>
Message-ID: <CAPW48sqnpa_iXrkW=oSjZDXAwXZtdqgAkVNC4cU3ZJAruPXDpA@mail.gmail.com>

>
> The question I have is whether the URLs that use "127.0.0.1"
> should also be changed to to use whatever address is returned
> InetAddress.getLoopbackAddress(). If it is needed it may
> require a bit more coding to ensure that [ ] are correctly
> added if the returned address is IPv6.
>
Hi Daniel,
Regarding the URLs, those will be changed in a followup change (and "[]" is
handled).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/c74f51f6/attachment.html>

From martinrb at google.com  Mon Mar 11 17:46:47 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Mar 2019 10:46:47 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
Message-ID: <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>

These changes are clean progress and allow tests to pass on any of the 4
(!) combinations of IPV4/IPV6 support available.  LGTM.

BUT ... in the current multi-protocol world it's probably better to test
against all the interfaces available on the host machine.
Maybe there should be a InetAddress.getLoopbackAddresses (note the plural!)
and tests should run against all the InetAddress objects returned by such
an API?
But this is a big task (mostly spec work I would guess) for the net-dev
team.

On Mon, Mar 11, 2019 at 9:55 AM Arthur Eubanks <aeubanks at google.com> wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
> webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/
>
> First of a few ipv6 patches to come.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/544a235a/attachment.html>

From aeubanks at google.com  Mon Mar 11 18:14:32 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 11 Mar 2019 11:14:32 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
Message-ID: <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>

Updated copyright years (I asked around, it should be fine), updated commit
message.
http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01

On Mon, Mar 11, 2019 at 10:46 AM Martin Buchholz <martinrb at google.com>
wrote:

> These changes are clean progress and allow tests to pass on any of the 4
> (!) combinations of IPV4/IPV6 support available.  LGTM.
>
> BUT ... in the current multi-protocol world it's probably better to test
> against all the interfaces available on the host machine.
> Maybe there should be a InetAddress.getLoopbackAddresses (note the
> plural!) and tests should run against all the InetAddress objects returned
> by such an API?
> But this is a big task (mostly spec work I would guess) for the net-dev
> team.
>
> On Mon, Mar 11, 2019 at 9:55 AM Arthur Eubanks <aeubanks at google.com>
> wrote:
>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
>> webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/
>>
>> First of a few ipv6 patches to come.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190311/d80a3dde/attachment.html>

From chris.hegarty at oracle.com  Tue Mar 12 09:05:56 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 12 Mar 2019 09:05:56 +0000
Subject: RFR 8220480: Typo in java.net.http.HttpResponse.BodySubscriber
 documentation
Message-ID: <790F37C9-7D05-4872-9560-4EBEA8B5CC11@oracle.com>

Minor typo in the link target, should be BodySubscribers ( plural ).

--- a/src/java.net.http/share/classes/java/net/http/HttpResponse.java
+++ b/src/java.net.http/share/classes/java/net/http/HttpResponse.java
@@ -1,7 +1,7 @@
 /*
- * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2019, 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
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.  Oracle designates this
@@ -826,11 +826,11 @@
     }
 
     /**
      * A {@code BodySubscriber} consumes response body bytes and converts them
      * into a higher-level Java type.  The class {@link BodySubscribers
-     * BodySubscriber} provides implementations of many common body subscribers.
+     * BodySubscribers} provides implementations of many common body subscribers.
      *
      * <p> The object acts as a {@link Flow.Subscriber}&lt;{@link List}&lt;{@link
      * ByteBuffer}&gt;&gt; to the HTTP Client implementation, which publishes
      * lists of ByteBuffers containing the response body. The Flow of data, as
      * well as the order of ByteBuffers in the Flow lists, is a strictly ordered


-Chris.

From Alan.Bateman at oracle.com  Tue Mar 12 09:19:09 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 12 Mar 2019 09:19:09 +0000
Subject: RFR 8220480: Typo in java.net.http.HttpResponse.BodySubscriber
 documentation
In-Reply-To: <790F37C9-7D05-4872-9560-4EBEA8B5CC11@oracle.com>
References: <790F37C9-7D05-4872-9560-4EBEA8B5CC11@oracle.com>
Message-ID: <08b7d085-ae6a-488f-067e-08d07a229f7f@oracle.com>



On 12/03/2019 09:05, Chris Hegarty wrote:
> Minor typo in the link target, should be BodySubscribers ( plural ).
>
Looks okay.

From daniel.fuchs at oracle.com  Tue Mar 12 10:45:39 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 12 Mar 2019 10:45:39 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
Message-ID: <f5ed8506-a605-056b-3737-06076a6dbd57@oracle.com>

Hi Arthur,

This looks good to me. I have launched the changes in your second
webrev through our test system and not observed any regression.
I don't know if Chris still has some tests running, but from
my standpoint you're good to go!

best regards,

-- daniel

On 11/03/2019 18:14, Arthur Eubanks wrote:
> Updated copyright years (I asked around, it should be fine), updated 
> commit message.
> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
> 
> On Mon, Mar 11, 2019 at 10:46 AM Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
> 
>     These changes are clean progress and allow tests to pass on any of
>     the 4 (!) combinations of IPV4/IPV6 support available.? LGTM.
> 
>     BUT ... in the current multi-protocol world it's probably better to
>     test against all the interfaces available on the host machine.
>     Maybe there should be a InetAddress.getLoopbackAddresses (note the
>     plural!) and tests should run against all the InetAddress objects
>     returned by such an API?
>     But this is a big task (mostly spec work I would guess) for the
>     net-dev team.
> 
>     On Mon, Mar 11, 2019 at 9:55 AM Arthur Eubanks <aeubanks at google.com
>     <mailto:aeubanks at google.com>> wrote:
> 
>         bug: https://bugs.openjdk.java.net/browse/JDK-8220083
>         webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/
> 
>         First of a few ipv6 patches to come.
> 


From chris.hegarty at oracle.com  Tue Mar 12 11:59:58 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 12 Mar 2019 11:59:58 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
Message-ID: <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>

Hi Arthur,

> On 11 Mar 2019, at 18:14, Arthur Eubanks <aeubanks at google.com <mailto:aeubanks at google.com>> wrote:
> 
> Updated copyright years (I asked around, it should be fine), updated commit message.
> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01 <http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01>
This is a welcome improvement to the tests. Reviewed, with some minor
comments and additions below.

It will not be easy to get all the JDK networking tests passing
successfully on IPv6-only environments ( ignoring the other combinations
for now ). But this is a good improvement, and hopefully the start of
a number of changes that add similar incremental improvements. To this
end, I've created an umbrella task, 8220499, to track these test changes
( in one place ), and updated this issue, 8220083, to be a sub-task of
it. Let's add more sub-tasks as needed.

Specific webrev comment:
 * Can you please split the long line in TunnelThroughProxy.java

Suggestion for similar changes while here:
 * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html <http://cr.openjdk.java.net/~chegar/8220083.additional/index.html>

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190312/cf38236d/attachment.html>

From Alan.Bateman at oracle.com  Tue Mar 12 12:30:55 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 12 Mar 2019 12:30:55 +0000
Subject: 8220493: Prepare Socket/ServerSocket for alternative platform
 SocketImpl
Message-ID: <ec73cb97-b61d-9564-4a72-2a4a504ab1dd@oracle.com>


We have a branch in the sandbox named "niosocketimpl-branch" with a 
replacement for the underlying implementation used by java.net.Socket 
and ServerSocket. I've mentioned this in previous mails [1]. We also 
have a draft JEP [2].

I'd like to get the changes that allow for the platform SocketImpl to be 
replaced into jdk/jdk in advance of the JEP. The reasoning is to reduce 
the size of the overall patch, make the changes easier to review, and 
get some of the narly behavior changes out of the way before the main event.

To that end, I've created JDK-8220493 [3] to bring the "preparatory 
changes" into jdk/jdk. A summary of the changes is:

- ServerSocket is changed to use a platform SocketImpl by default, it 
used to use the SOCKS SocketImpl.

- Socket use a SOCKS SocketImpl by default. The SOCKS SocketImpl now 
delegates to a platform SocketImpl rather than extending it. The HTTP 
SocketImpl is also changed to delegate to a platform SocketImpl.

- ServerSocket.accept has been overhauled to disallow nonsensical 
combinations of SocketImpl. For example, it is nuts to create a 
ServerSocket using a custom SocketImpl and have it try to accept a 
connection with a platform SocketImpl. There is a big matrix of possible 
scenarios that are tested with a new combinations test. Chris, Michael 
and I spent time on a white board going through all the possible 
scenarios to make sure that all sane scenarios work as before, only the 
nonsensical comminations are disallowed.

- Socket has been changed to wrap the input/output streams returned by 
the underlying SocketImpl so that closing of these streams will close 
the socket. This is important to allow for socket implementations 
outside of the java.net package but it requires changes to JFR as it 
instruments these changes.

I've created a CSR [4] to document the subtle behavior changes.

The webrev with the corresponding changes is here:
 ? http://cr.openjdk.java.net/~alanb/8220493/0/webrev/

-Alan

[1] 
https://mail.openjdk.java.net/pipermail/net-dev/2019-January/012135.html
[2] http://openjdk.java.net/jeps/8218559
[3] https://bugs.openjdk.java.net/browse/JDK-8220493
[4] https://bugs.openjdk.java.net/browse/JDK-8220494



From aeubanks at google.com  Tue Mar 12 16:59:40 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 12 Mar 2019 09:59:40 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
Message-ID: <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>

Thanks for creating the umbrella bug.

Split long line.
Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
suggestions. The other 2 involve URI/URLs, and there are a lot of those
changes, will group them in a later change.

PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/


On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Hi Arthur,
>
>
> On 11 Mar 2019, at 18:14, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Updated copyright years (I asked around, it should be fine), updated
> commit message.
> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
>
>
> This is a welcome improvement to the tests. Reviewed, with some minor
> comments and additions below.
>
> It will not be easy to get all the JDK networking tests passing
> successfully on IPv6-only environments ( ignoring the other combinations
> for now ). But this is a good improvement, and hopefully the start of
> a number of changes that add similar incremental improvements. To this
> end, I've created an umbrella task, 8220499, to track these test changes
> ( in one place ), and updated this issue, 8220083, to be a sub-task of
> it. Let's add more sub-tasks as needed.
>
> Specific webrev comment:
>  * Can you please split the long line in TunnelThroughProxy.java
>
> Suggestion for similar changes while here:
>  * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190312/c8f221a9/attachment.html>

From chris.hegarty at oracle.com  Tue Mar 12 17:34:45 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 12 Mar 2019 17:34:45 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
Message-ID: <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>

Arthur,

> On 12 Mar 2019, at 16:59, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Thanks for creating the umbrella bug.
> 
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's suggestions.

Thanks.

> The other 2 involve URI/URLs, and there are a lot of those changes, will group them in a later change.

That is true, and it is absolutely fine to leave them until a follow on.

The reason I suggested the change is because almost all of the other
HTTP Client tests run successfully on an IPv6-only environment. The
reason is that the URL-string when converted to a URI has the square
brackets added by URI.create. Anyway, not critical for now.

> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/ <http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/>
Looks good.

You are probably all set, but if you need a sponsor just ask.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190312/facf1d25/attachment.html>

From aeubanks at google.com  Tue Mar 12 17:54:00 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 12 Mar 2019 10:54:00 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
Message-ID: <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>

Thanks!

Just curious, what tests did you run and under what environment?

On Tue, Mar 12, 2019 at 10:34 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> On 12 Mar 2019, at 16:59, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Thanks for creating the umbrella bug.
>
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
> suggestions.
>
>
> Thanks.
>
> The other 2 involve URI/URLs, and there are a lot of those changes, will
> group them in a later change.
>
>
> That is true, and it is absolutely fine to leave them until a follow on.
>
> The reason I suggested the change is because almost all of the other
> HTTP Client tests run successfully on an IPv6-only environment. The
> reason is that the URL-string when converted to a URI has the square
> brackets added by URI.create. Anyway, not critical for now.
>
> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/
>
>
> Looks good.
>
> You are probably all set, but if you need a sponsor just ask.
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190312/9169fbe8/attachment-0001.html>

From chris.hegarty at oracle.com  Tue Mar 12 19:19:07 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 12 Mar 2019 19:19:07 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
 <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>
Message-ID: <3D0B667F-339E-4184-A469-FD04C5310514@oracle.com>

Arthur,

> On 12 Mar 2019, at 17:54, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Thanks!
> 
> Just curious, what tests did you run and under what environment?

I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit
of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and 
preferIPv6Addresses effectively forced. The /etc/hosts on my system
returns IPv6 addresses for `localhost` and the machine host name. This
env reproduces the same set of failures as you ( I assume from your 
webrev ), and more. It's just enough to get me started and able to
review / help out.

-Chris.

From vyommani at gmail.com  Wed Mar 13 03:04:13 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 13 Mar 2019 08:34:13 +0530
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
Message-ID: <CAKysZ8z4VCdmf-6RZKcXJaGN6M6ZDyXb4d58TcVDqYwBDOc0dA@mail.gmail.com>

Hi Arthur,

Changes looks good to me, one minor comment, in HTTPTestServer.java  we can
avoid  new local variable (InetAddress address) .

Thanks,
Vyom

On Tue, Mar 12, 2019 at 10:30 PM Arthur Eubanks <aeubanks at google.com> wrote:

> Thanks for creating the umbrella bug.
>
> Split long line.
> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
> suggestions. The other 2 involve URI/URLs, and there are a lot of those
> changes, will group them in a later change.
>
> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/
>
>
> On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
>
>> Hi Arthur,
>>
>>
>> On 11 Mar 2019, at 18:14, Arthur Eubanks <aeubanks at google.com> wrote:
>>
>> Updated copyright years (I asked around, it should be fine), updated
>> commit message.
>> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
>>
>>
>> This is a welcome improvement to the tests. Reviewed, with some minor
>> comments and additions below.
>>
>> It will not be easy to get all the JDK networking tests passing
>> successfully on IPv6-only environments ( ignoring the other combinations
>> for now ). But this is a good improvement, and hopefully the start of
>> a number of changes that add similar incremental improvements. To this
>> end, I've created an umbrella task, 8220499, to track these test changes
>> ( in one place ), and updated this issue, 8220083, to be a sub-task of
>> it. Let's add more sub-tasks as needed.
>>
>> Specific webrev comment:
>>  * Can you please split the long line in TunnelThroughProxy.java
>>
>> Suggestion for similar changes while here:
>>  * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html
>>
>> -Chris.
>>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/68dea463/attachment.html>

From chris.hegarty at oracle.com  Wed Mar 13 12:09:50 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 12:09:50 +0000
Subject: RFR 8220475: Malformed copyright header in LinuxSocketOptions.java,
 MacOSXSocketOptions.java and MacOSXSocketOptions.c
Message-ID: <8E48CA71-B422-42CC-B9F2-C0FD8CA3635B@oracle.com>

Trivially, there should be a comma after the year. Just add it.

diff --git a/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java b/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java
--- a/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java
+++ b/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2017, 2018 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2017, 2018, 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
diff --git a/src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java b/src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java
--- a/src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java
+++ b/src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2018, 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
diff --git a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c
--- a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c
+++ b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2018, 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

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/aba63df8/attachment.html>

From daniel.fuchs at oracle.com  Wed Mar 13 12:13:59 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 12:13:59 +0000
Subject: RFR 8220475: Malformed copyright header in
 LinuxSocketOptions.java, MacOSXSocketOptions.java and MacOSXSocketOptions.c
In-Reply-To: <8E48CA71-B422-42CC-B9F2-C0FD8CA3635B@oracle.com>
References: <8E48CA71-B422-42CC-B9F2-C0FD8CA3635B@oracle.com>
Message-ID: <830c6aa7-19f1-3aa5-4b5a-f3db89e504c4@oracle.com>

Looks good Chris!

-- daniel

On 13/03/2019 12:09, Chris Hegarty wrote:
> Trivially, there should be a comma after the year. Just add it.

From Alan.Bateman at oracle.com  Wed Mar 13 12:18:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Mar 2019 12:18:18 +0000
Subject: RFR 8220475: Malformed copyright header in
 LinuxSocketOptions.java, MacOSXSocketOptions.java and MacOSXSocketOptions.c
In-Reply-To: <8E48CA71-B422-42CC-B9F2-C0FD8CA3635B@oracle.com>
References: <8E48CA71-B422-42CC-B9F2-C0FD8CA3635B@oracle.com>
Message-ID: <d7293425-a164-8e4f-67ea-459d9d1eabce@oracle.com>



On 13/03/2019 12:09, Chris Hegarty wrote:
> Trivially, there should be a comma after the year. Just add it.
>
Looks okay.

From aeubanks at google.com  Wed Mar 13 16:22:40 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 13 Mar 2019 09:22:40 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CAKysZ8z4VCdmf-6RZKcXJaGN6M6ZDyXb4d58TcVDqYwBDOc0dA@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <CAKysZ8z4VCdmf-6RZKcXJaGN6M6ZDyXb4d58TcVDqYwBDOc0dA@mail.gmail.com>
Message-ID: <CAPW48sqHv9Qq7g+5fSAxfXR1O3qH3UTXzSN9VLOs3jj4CeJWEQ@mail.gmail.com>

Hi Vyom,
Sorry, the change already went in. I can do this in a followup change if
you'd like.

On Tue, Mar 12, 2019 at 8:04 PM Vyom Tiwari <vyommani at gmail.com> wrote:

> Hi Arthur,
>
> Changes looks good to me, one minor comment, in HTTPTestServer.java  we
> can avoid  new local variable (InetAddress address) .
>
> Thanks,
> Vyom
>
> On Tue, Mar 12, 2019 at 10:30 PM Arthur Eubanks <aeubanks at google.com>
> wrote:
>
>> Thanks for creating the umbrella bug.
>>
>> Split long line.
>> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
>> suggestions. The other 2 involve URI/URLs, and there are a lot of those
>> changes, will group them in a later change.
>>
>> PTAL: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.02/
>>
>>
>> On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty <chris.hegarty at oracle.com>
>> wrote:
>>
>>> Hi Arthur,
>>>
>>>
>>> On 11 Mar 2019, at 18:14, Arthur Eubanks <aeubanks at google.com> wrote:
>>>
>>> Updated copyright years (I asked around, it should be fine), updated
>>> commit message.
>>> http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01
>>>
>>>
>>> This is a welcome improvement to the tests. Reviewed, with some minor
>>> comments and additions below.
>>>
>>> It will not be easy to get all the JDK networking tests passing
>>> successfully on IPv6-only environments ( ignoring the other combinations
>>> for now ). But this is a good improvement, and hopefully the start of
>>> a number of changes that add similar incremental improvements. To this
>>> end, I've created an umbrella task, 8220499, to track these test changes
>>> ( in one place ), and updated this issue, 8220083, to be a sub-task of
>>> it. Let's add more sub-tasks as needed.
>>>
>>> Specific webrev comment:
>>>  * Can you please split the long line in TunnelThroughProxy.java
>>>
>>> Suggestion for similar changes while here:
>>>  * http://cr.openjdk.java.net/~chegar/8220083.additional/index.html
>>>
>>> -Chris.
>>>
>>
>
> --
> Thanks,
> Vyom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/667568d7/attachment-0001.html>

From aeubanks at google.com  Wed Mar 13 16:32:10 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 13 Mar 2019 09:32:10 -0700
Subject: RFR: 8220585: Incorrect code in MulticastSocket sample code
Message-ID: <CAPW48spJYM+arNaYZUkjuBVL_+8PSUUvfn7ro0p7XvxBVgfYVQ@mail.gmail.com>

Hi,

A fix for some sample code in MulticastSocket, which assumed that
String.length() == String.getBytes().length, which is not true for
non-ASCII Strings.

http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/6d63cf34/attachment.html>

From chris.hegarty at oracle.com  Wed Mar 13 17:04:57 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 17:04:57 +0000
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
Message-ID: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>

Trivially, there should be a comma after the year. Just add it.


$ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
--- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
+++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2017, 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
diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
--- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
+++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2018, 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
diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
--- a/src/java.base/share/classes/sun/security/util/IOUtils.java
+++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2009, 2017, 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

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/13e3a176/attachment.html>

From horvath.peter.gergely at gmail.com  Wed Mar 13 17:07:26 2019
From: horvath.peter.gergely at gmail.com (=?UTF-8?Q?Horv=C3=A1th_P=C3=A9ter_Gergely?=)
Date: Wed, 13 Mar 2019 18:07:26 +0100
Subject: 8207846 Generalize the jdk.net.includeInExceptions security property:
 documentation?
Message-ID: <CA+UsspBSga-AMb-XKPVGPdbpVOfoyQ6EO3Y3MFzJZDLwcVQcAg@mail.gmail.com>

Hi All,

I think having the enhanced reporting of socket connection failures driven
by "jdk.net.includeInExceptions" property is a huge step forward with
regards to the ability to debug Java networking applications.

For me however one piece seems to be missing: I am not sure if there is any
kind of user documentation available, where this property (and other ones)
are documented.

Do we have any kind of user-visible documentation that mentions these
properties at all? (A quick Google search yields basically only issues
tracked in the JDK Jira and some indexed source codes and that's it.) If
not, do you have any plan to document these properties somewhere?

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/62d20613/attachment.html>

From daniel.fuchs at oracle.com  Wed Mar 13 17:09:55 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 17:09:55 +0000
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
Message-ID: <c692e851-9307-5430-b03b-6999a24420fb@oracle.com>

Looks good to me Chris!

cheers,

-- daniel

On 13/03/2019 17:04, Chris Hegarty wrote:
> Trivially, there should be a comma after the year. Just add it.

From lance.andersen at oracle.com  Wed Mar 13 17:10:57 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Mar 2019 13:10:57 -0400
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
Message-ID: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>

+1
> On Mar 13, 2019, at 1:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Trivially, there should be a comma after the year. Just add it.
> 
> 
> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2017, 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
> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2018, 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
> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java
> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2009, 2017, 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
> 
> -Chris.

 <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/20190313/99023c22/attachment-0001.html>
-------------- 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/20190313/99023c22/oracle_sig_logo-0001.gif>

From martinrb at google.com  Wed Mar 13 17:15:11 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 10:15:11 -0700
Subject: RFR: 8220585: Incorrect code in MulticastSocket sample code
In-Reply-To: <CAPW48spJYM+arNaYZUkjuBVL_+8PSUUvfn7ro0p7XvxBVgfYVQ@mail.gmail.com>
References: <CAPW48spJYM+arNaYZUkjuBVL_+8PSUUvfn7ro0p7XvxBVgfYVQ@mail.gmail.com>
Message-ID: <CA+kOe0_Lp3JgaKiebhyeUn-e9CBSPLvw-R+d34XyCz8P0A5jog@mail.gmail.com>

Looks good to me.

On Wed, Mar 13, 2019 at 9:34 AM Arthur Eubanks <aeubanks at google.com> wrote:

> Hi,
>
> A fix for some sample code in MulticastSocket, which assumed that
> String.length() == String.getBytes().length, which is not true for
> non-ASCII Strings.
>
> http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/5a6d4be2/attachment.html>

From chris.hegarty at oracle.com  Wed Mar 13 17:17:15 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 17:17:15 +0000
Subject: RFR: 8220585: Incorrect code in MulticastSocket sample code
In-Reply-To: <CAPW48spJYM+arNaYZUkjuBVL_+8PSUUvfn7ro0p7XvxBVgfYVQ@mail.gmail.com>
References: <CAPW48spJYM+arNaYZUkjuBVL_+8PSUUvfn7ro0p7XvxBVgfYVQ@mail.gmail.com>
Message-ID: <28ae4898-a63e-a2e8-b293-49aa227435f5@oracle.com>

Arthur,

On 13/03/2019 16:32, Arthur Eubanks wrote:
> Hi,
> 
> A fix for some sample code in MulticastSocket, which assumed that 
> String.length() == String.getBytes().length, which is not true for 
> non-ASCII Strings.
> 
> http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00

Looks good. Thanks.

-Chris.

From martinrb at google.com  Wed Mar 13 17:29:02 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 10:29:02 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <3D0B667F-339E-4184-A469-FD04C5310514@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
 <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>
 <3D0B667F-339E-4184-A469-FD04C5310514@oracle.com>
Message-ID: <CA+kOe0_id8oJYxDM9C3RSJfqC74PGAM7kJWB_LJ=H2VoXvj4JQ@mail.gmail.com>

On Tue, Mar 12, 2019 at 12:21 PM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

>
> > Just curious, what tests did you run and under what environment?
>
> I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit
> of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and
> preferIPv6Addresses effectively forced. The /etc/hosts on my system
> returns IPv6 addresses for `localhost` and the machine host name. This
> env reproduces the same set of failures as you ( I assume from your
> webrev ), and more. It's just enough to get me started and able to
> review / help out.
>

The difficulty of testing networking environments is an impediment to
progress.
Chris, you might want to publish your hacky changes as an experimental
patch in cr.openjdk.

At Google, we have our own hacks to test ipv6-only environments, based on
either LD_PRELOAD or eBPF (but it would take work to share them even in
minimally functional form)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/bb6e41d9/attachment.html>

From chris.hegarty at oracle.com  Wed Mar 13 17:32:27 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 17:32:27 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
Message-ID: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>

I filed the 8220575 [1] that tracks "Correctly format test URI's that
contain a retrieved IPv6 address"

Regarding fixing tests that incorrectly use IPv6 addresses in URL's or
URI's, without enclosing the address within '[' and ']' ( square
brackets ). These IPv6 addresses typically come from either of: 1)
the InetAddress.getLoopbackAddress().getHostAddress(), or 2)
InetAddress.getLocalHost().getHostAddress(). I think that is most cases
it should be possible to just replace the use of `getHostAddress` with
`getHostName`. This defers the actual lookup to the system configured
name service ( rather than trying to encode IPv6 addresses in the
test ).

Also, URL's / URI's that hardcode "127.0.0.1", can ( in most cases )
just be replaced with InetAddress.getLoopbackAddress().getHostName().

I've followed the above advise on a few tests and it seems to be working
out ok, so far.

-Chris.

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

From aeubanks at google.com  Wed Mar 13 17:43:41 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 13 Mar 2019 10:43:41 -0700
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
Message-ID: <CAPW48soqCgsHXg-hxmJ0dVCXFyvWf9sD80eJ2BsoY_BTfhK46Q@mail.gmail.com>

SGTM.

Sort of related:
Some tests specifically test the IP address as opposed to "localhost" (e.g.
some security tests), we'll need to figure out what to do with those.
Martin suggested looping through all available loopback addresses rather
than hardcoding them. In that case we'll need helper test functions to
return loopback addresses (and test that it actually returns all available
loopback addresses).

On Wed, Mar 13, 2019 at 10:33 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> I filed the 8220575 [1] that tracks "Correctly format test URI's that
> contain a retrieved IPv6 address"
>
> Regarding fixing tests that incorrectly use IPv6 addresses in URL's or
> URI's, without enclosing the address within '[' and ']' ( square
> brackets ). These IPv6 addresses typically come from either of: 1)
> the InetAddress.getLoopbackAddress().getHostAddress(), or 2)
> InetAddress.getLocalHost().getHostAddress(). I think that is most cases
> it should be possible to just replace the use of `getHostAddress` with
> `getHostName`. This defers the actual lookup to the system configured
> name service ( rather than trying to encode IPv6 addresses in the
> test ).
>
> Also, URL's / URI's that hardcode "127.0.0.1", can ( in most cases )
> just be replaced with InetAddress.getLoopbackAddress().getHostName().
>
> I've followed the above advise on a few tests and it seems to be working
> out ok, so far.
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8220575
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/4722c578/attachment.html>

From daniel.fuchs at oracle.com  Wed Mar 13 18:22:22 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 18:22:22 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
Message-ID: <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>

Hi Chris,

On 13/03/2019 17:32, Chris Hegarty wrote:
> I think that is most cases
> it should be possible to just replace the use of `getHostAddress` with
> `getHostName`. This defers the actual lookup to the system configured
> name service ( rather than trying to encode IPv6 addresses in the
> test )
I think I'd prefer to use getHostAddress() and one of the multi
arg constructors for  URI/URL instead, as it makes it more explicit
that you're using the same address on both side of the connection.

Are we otherwise sure that the hostname would resolve to the
exact same address?

For instance:

jshell> InetAddress.getLoopbackAddress().getHostName()
$7 ==> "localhost"

jshell> InetAddress.getAllByName("localhost");
$8 ==> InetAddress[3] {
           localhost/127.0.0.1,
           localhost/0:0:0:0:0:0:0:1,
           localhost/fe80:0:0:0:0:0:0:1%1
        }

best regards,

-- daniel

From daniel.fuchs at oracle.com  Wed Mar 13 18:40:18 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 18:40:18 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <CAPW48soqCgsHXg-hxmJ0dVCXFyvWf9sD80eJ2BsoY_BTfhK46Q@mail.gmail.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <CAPW48soqCgsHXg-hxmJ0dVCXFyvWf9sD80eJ2BsoY_BTfhK46Q@mail.gmail.com>
Message-ID: <4303c4a4-381d-f0f7-e66b-27b33aaa8cbf@oracle.com>

Hi Arthur,

On 13/03/2019 17:43, Arthur Eubanks wrote:
> Martin suggested looping through all available loopback addresses rather 
> than hardcoding them. In that case we'll need helper test functions to 
> return loopback addresses (and test that it actually returns all 
> available loopback addresses).

Though I agree that in a ideal world that's what we would like to do,
I am afraid that this would increase the possibility of getting
random intermittent failures when running our tests on tests farms.
It would certainly increase the opportunity of stumbling on some
bad configuration issues.
Also having several tests running concurrently when one
test binds on the wildcard while another test concurrently binds
on the local host address (or the loopback) is a known recipe for
instability due to the underlying system port reuse strategy.

In addition some of our tests (in httpclient) are already pretty greedy
trying to cover the matrix of http / https / http 1.1 / http 2
multiplied by all the different test cases that the test wants to
test - so running them over all possible loopbacks would probably
become a maintenance hassle:
We already had to split several of them (sometimes a bit
artificially) because they were going over the reasonable
resource quota when run on some exotic configuration
(like fastdebug + Xcomp for instance).

So I'm not sure how feasible such an idea would be.

best regards,

-- daniel

From chris.hegarty at oracle.com  Wed Mar 13 18:45:04 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 18:45:04 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
Message-ID: <eecae3fa-72f3-c89b-0aed-81ef24e3b52d@oracle.com>

Daniel,

On 13/03/2019 18:22, Daniel Fuchs wrote:
> Hi Chris,
> 
> On 13/03/2019 17:32, Chris Hegarty wrote:
>> I think that is most cases
>> it should be possible to just replace the use of `getHostAddress` with
>> `getHostName`. This defers the actual lookup to the system configured
>> name service ( rather than trying to encode IPv6 addresses in the
>> test )
> I think I'd prefer to use getHostAddress() and one of the multi
> arg constructors for? URI/URL instead, as it makes it more explicit
> that you're using the same address on both side of the connection.
> 
> Are we otherwise sure that the hostname would resolve to the
> exact same address?
> 
> For instance:
> 
> jshell> InetAddress.getLoopbackAddress().getHostName()
> $7 ==> "localhost"
> 
> jshell> InetAddress.getAllByName("localhost");
> $8 ==> InetAddress[3] {
>  ????????? localhost/127.0.0.1,
>  ????????? localhost/0:0:0:0:0:0:0:1,
>  ????????? localhost/fe80:0:0:0:0:0:0:1%1
>  ?????? }

Good point.

Many test ( that don't explicitly test binding or particulars of
encoding of the address in the URI / URL ), simply don't care about this
detail. They're likely testing something in the internal implementation
of the protocol handler, or something.  But you do raise a good point,
which relates to test stability; the client and server sides of the
tests need to be using the same interface / address ).

While testing, I have observed some URIs similar to
http://[0:0:0:0:0:0:0:1]:46009/zero/xxyy, in the log files. It's
comforting to know the exact address that is in use.

What I dislike about such an approach is its verbosity in the test code,
e.g.

     static URL urlFor(int port, String path) throws Exception {
         return new URI("http",
                        null,
                        loopbackAddress.getHostAddress(),
                        port,
                        path,
                        null,
                        null).toURL();
     }

This is a typical example of usage in tests, where the protocol being
tested is `http`. The host address here will be correctly enclosed by
square brackets if needed.

Alternative ( shorter, hack ):

     String host = loopbackAddress.getHostAddress();
     if (host.contains(":"))
         host = "[" + host + "]";

Regardless of the outcome, the use of a test library function will
likely not help much, as it adds jtreg tag verbosity and build
complexity that is probably more verbose than either of the above.

-Chris.

From chris.hegarty at oracle.com  Wed Mar 13 18:48:29 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 18:48:29 +0000
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <CA+kOe0_id8oJYxDM9C3RSJfqC74PGAM7kJWB_LJ=H2VoXvj4JQ@mail.gmail.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
 <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>
 <3D0B667F-339E-4184-A469-FD04C5310514@oracle.com>
 <CA+kOe0_id8oJYxDM9C3RSJfqC74PGAM7kJWB_LJ=H2VoXvj4JQ@mail.gmail.com>
Message-ID: <caabd35b-f38b-fa26-da3e-727446660511@oracle.com>

Martin,

On 13/03/2019 17:29, Martin Buchholz wrote:
> 
> 
> ...
> 
> The difficulty of testing networking environments is an impediment to 
> progress.
> Chris, you might want to publish your hacky changes as an experimental 
> patch in cr.openjdk.

I will do this, but, as I said, it is just a hack.

> At Google, we have our own hacks to test ipv6-only environments, based 
> on either LD_PRELOAD or eBPF (but it would take work to share them even 
> in minimally functional form)

Maybe I can produce something similar and publish it? So you intercept
setsocktopt, lookups? What else?

-Chris.

From martinrb at google.com  Wed Mar 13 18:57:14 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 11:57:14 -0700
Subject: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of
 127.0.0.1 for some tests
In-Reply-To: <caabd35b-f38b-fa26-da3e-727446660511@oracle.com>
References: <CAPW48spY+zw_wofYoi2EBtq+8e9iPYoiR6eDi4_T0szL_Z205g@mail.gmail.com>
 <CA+kOe0_wGd6RenXynzFvounAjoktd8VJ1T9ttSaanMtnqUcJPg@mail.gmail.com>
 <CAPW48sry_N4D05hiHn7Y3sfm=nYOueLi9F94EhqCfgbs0PzGTw@mail.gmail.com>
 <523F8E8E-B810-410C-8505-75DF9BC43C28@oracle.com>
 <CAPW48srBQFbWRm+NeGOLhKcC330sctwew-yGSchxGzFGV_jqCA@mail.gmail.com>
 <2E5265A6-BE91-4247-9078-7F6027B95CE1@oracle.com>
 <CAPW48sqhpv+0S7oKhcNXpAmytRd_nk=3PkA_LJdZ4gfPHR1OqA@mail.gmail.com>
 <3D0B667F-339E-4184-A469-FD04C5310514@oracle.com>
 <CA+kOe0_id8oJYxDM9C3RSJfqC74PGAM7kJWB_LJ=H2VoXvj4JQ@mail.gmail.com>
 <caabd35b-f38b-fa26-da3e-727446660511@oracle.com>
Message-ID: <CA+kOe092FUpxO15A6dd2HSowqB2dDNihxc3vZ+eYKWjws9MPcQ@mail.gmail.com>

On Wed, Mar 13, 2019 at 11:49 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

>
> > At Google, we have our own hacks to test ipv6-only environments, based
> > on either LD_PRELOAD or eBPF (but it would take work to share them even
> > in minimally functional form)
>
> Maybe I can produce something similar and publish it? So you intercept
> setsocktopt, lookups? What else?
>

Here's a code snippet with the list:

static int (*libc_socket)(int, int, int);
static int (*libc_setsockopt)(int, int, int, const void *, socklen_t);
static int (*libc_getifaddrs)(struct ifaddrs **);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/c71eec4e/attachment.html>

From weijun.wang at oracle.com  Thu Mar 14 01:14:55 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 14 Mar 2019 09:14:55 +0800
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
 <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>
Message-ID: <B9EBBD14-DE59-4F2C-8A0A-6DE5378491B6@oracle.com>

+1 (on the security class).

Thanks,
Max

> On Mar 14, 2019, at 1:10 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> +1
>> On Mar 13, 2019, at 1:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Trivially, there should be a comma after the year. Just add it.
>> 
>> 
>> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
>> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 2017, 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
>> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2003, 2018, 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
>> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
>> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java
>> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2009, 2017, 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
>> 
>> -Chris.
> 
> <oracle_sig_logo.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
> 
> 
> 


From martinrb at google.com  Thu Mar 14 01:45:47 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2019 18:45:47 -0700
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
Message-ID: <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>

On Wed, Mar 13, 2019 at 11:24 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

>
> jshell> InetAddress.getLoopbackAddress().getHostName()
> $7 ==> "localhost"
>
> jshell> InetAddress.getAllByName("localhost");
> $8 ==> InetAddress[3] {
>            localhost/127.0.0.1,
>            localhost/0:0:0:0:0:0:0:1,
>            localhost/fe80:0:0:0:0:0:0:1%1
>         }
>

Thanks for that lesson - TIL.

Despite being unfamiliar with networking code and test machines at Oracle,
I suggest:
- misconfigured test machines that don't work with their advertised
interfaces is unacceptable - just fix them!
- tests that don't care much about which loopback connection they get could
choose one randomly, via a test library method.  I like this sort of test
randomness, despite the possible flakiness.
- for tests where you do want coverage of both ipv4 and ipv6 interfaces, it
seems best to loop over all the available ones.
- I think "localhost" is more than a convention - it's a standard, but is
it recommended in tests to use
InetAddress.getLoopbackAddress().getHostName() instead of hardcoded
"localhost"?

 I know test engineering is hard work!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190313/15dcc1eb/attachment-0001.html>

From chris.hegarty at oracle.com  Thu Mar 14 09:43:56 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 14 Mar 2019 09:43:56 +0000
Subject: RFR 8213912: Semantic typo in HttpExchange.java
Message-ID: <4FE50F37-AB40-4109-AA0B-AC9819A152F0@oracle.com>

In the class-level description for com.sun.net.httpserver.HttpExchange
there is a typo related to the request body input stream, that may cause
confusion. It should be fixed.

The typical life-cycle of an exchange, as described, should advise the
reader that the request body input stream *SHOULD* be closed explicitly.
There is some additional auto-magic that may close the stream when
the exchange or its response body output stream is closed, but the
advise to the reader should be to close the stream explicitly ( as any
other action is more error-prone and adds additional cognitive load on
the reader ).


diff --git a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
--- a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
+++ b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
@@ -41,11 +41,11 @@
  * The typical life-cycle of a HttpExchange is shown in the sequence
  * below.
  * <ol><li>{@link #getRequestMethod()} to determine the command
  * <li>{@link #getRequestHeaders()} to examine the request headers (if needed)
  * <li>{@link #getRequestBody()} returns a {@link java.io.InputStream} for reading the request body.
- *     After reading the request body, the stream is close.
+ *     After reading the request body, the stream should be closed.
  * <li>{@link #getResponseHeaders()} to set any response headers, except content-length
  * <li>{@link #sendResponseHeaders(int,long)} to send the response headers. Must be called before
  * next step.
  * <li>{@link #getResponseBody()} to get a {@link java.io.OutputStream} to send the response body.
  *      When the response body has been written, the stream must be closed to terminate the exchange.

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


From daniel.fuchs at oracle.com  Thu Mar 14 11:10:15 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 14 Mar 2019 11:10:15 +0000
Subject: RFR 8213912: Semantic typo in HttpExchange.java
In-Reply-To: <4FE50F37-AB40-4109-AA0B-AC9819A152F0@oracle.com>
References: <4FE50F37-AB40-4109-AA0B-AC9819A152F0@oracle.com>
Message-ID: <181d0294-1613-0c14-e7f7-a4f45c674006@oracle.com>

Hi Chris,

Thanks for fixing this, it is an important distinction!
(and I like John's description of the issue :-))

I am wondering though - whether there's a relationship with
this bug, and JDK-8180754 [1].

best regards,

-- daniel

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

On 14/03/2019 09:43, Chris Hegarty wrote:
> In the class-level description for com.sun.net.httpserver.HttpExchange
> there is a typo related to the request body input stream, that may cause
> confusion. It should be fixed.
> 
> The typical life-cycle of an exchange, as described, should advise the
> reader that the request body input stream *SHOULD* be closed explicitly.
> There is some additional auto-magic that may close the stream when
> the exchange or its response body output stream is closed, but the
> advise to the reader should be to close the stream explicitly ( as any
> other action is more error-prone and adds additional cognitive load on
> the reader ).
> 
> 
> diff --git a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
> --- a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
> +++ b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
> @@ -41,11 +41,11 @@
>    * The typical life-cycle of a HttpExchange is shown in the sequence
>    * below.
>    * <ol><li>{@link #getRequestMethod()} to determine the command
>    * <li>{@link #getRequestHeaders()} to examine the request headers (if needed)
>    * <li>{@link #getRequestBody()} returns a {@link java.io.InputStream} for reading the request body.
> - *     After reading the request body, the stream is close.
> + *     After reading the request body, the stream should be closed.
>    * <li>{@link #getResponseHeaders()} to set any response headers, except content-length
>    * <li>{@link #sendResponseHeaders(int,long)} to send the response headers. Must be called before
>    * next step.
>    * <li>{@link #getResponseBody()} to get a {@link java.io.OutputStream} to send the response body.
>    *      When the response body has been written, the stream must be closed to terminate the exchange.
> 
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8213912
>    
> -Chris.
> 


From chris.hegarty at oracle.com  Thu Mar 14 11:31:39 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 14 Mar 2019 11:31:39 +0000
Subject: RFR 8213912: Semantic typo in HttpExchange.java
In-Reply-To: <181d0294-1613-0c14-e7f7-a4f45c674006@oracle.com>
References: <4FE50F37-AB40-4109-AA0B-AC9819A152F0@oracle.com>
 <181d0294-1613-0c14-e7f7-a4f45c674006@oracle.com>
Message-ID: <7CD14FFE-1647-45B6-9E5E-B072406B8137@oracle.com>

Daniel,

> On 14 Mar 2019, at 11:10, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> Thanks for fixing this, it is an important distinction!

Thanks for the review.

> (and I like John's description of the issue :-))
> 
> I am wondering though - whether there's a relationship with
> this bug, and JDK-8180754 [1].

The issues are somewhat related, but orthogonal.

It feels like 8180754 should remove the erroneous assertion,
but I would need to spend a little more time on it to know for
sure.

-Chris.

From chris.hegarty at oracle.com  Thu Mar 14 16:40:45 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 14 Mar 2019 16:40:45 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
Message-ID: <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>

It's just a hack, but enough to get me started so I can asses some of
what is needed to support running the tests on an IPv6-only environment.

  http://cr.openjdk.java.net/~chegar/ipv6-only-hack/

  My /etc/hosts file has entries for `localhost` and the _host_, that
  return `::1`.

This is enough to get started, but it will run out of road quite soon.
And it will break some things. Let's work towards getting a better
solution.

Also, we will need test library support for determining whether the
platform supports: 1) IPv4, or 2) IPv6, or 3) IPv4&IPv6. I filed 8220673
[1] to tracks this.

---

Regarding what to do with URL's in test. I tried a few different
approaches, I am leaning towards:

     String host = loopbackAddress.getHostAddress();
     if (host.contains(":"))
         host = "[" + host + "]";

Since it:
 1) is relatively short and concise, and
 2) ensures, in many cases, that the client and server use the same
    IP address, and
 3) clearly shows the actual IP protocol in use, e.g.
    http://[0:0:0:0:0:0:0:1]:46009/zero/xxyy

A sample of some tests that have been updated as above:
  http://cr.openjdk.java.net/~chegar/8220575/webrev.0.1/ (not too bad!)

-Chris.

P.S. I ran into an implementation bug and filed, 8220663: "Incorrect
handling of IPv6 addresses in Socket(Proxy.HTTP)" - the fix is straight
forward.

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

From chris.hegarty at oracle.com  Thu Mar 14 16:47:11 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 14 Mar 2019 16:47:11 +0000
Subject: RFR 8179549: Typo in network properties documentation
Message-ID: <E08DA1B6-416E-4D82-A52B-9E7DE9469372@oracle.com>

Trivial typo fix.

diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html
--- a/src/java.base/share/classes/java/net/doc-files/net-properties.html
+++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html
@@ -1,6 +1,6 @@
 <!DOCTYPE HTML>
 <!--
- Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
+ Copyright (c) 1998, 2019, 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
@@ -208,7 +208,7 @@
 	      username. With this method existing applications that use the
 	      authenticator class do not need to be modified, as long as users
 	      are made aware that this notation must be used.</P>
-	  <LI><P>If a domain name is not specified as in method 2) and these
+	  <LI><P>If a domain name is not specified as in method 2) and this
 	      property is defined, then its value will be used a the domain
 	      name.</P>
 	</OL>


-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190314/1e976d5d/attachment.html>

From aeubanks at google.com  Thu Mar 14 17:44:50 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 14 Mar 2019 10:44:50 -0700
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
Message-ID: <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>

Most of these eventually turn the String into a URL, so using a URL
directly should work?

jshell> URL u = new URL("http", "::1", 9002, "/")
u ==> http://[::1]:9002/
jshell> URL u = new URL("http",
InetAddress.getLoopbackAddress().getHostAddress(), 9002, "/")
u ==> http://127.0.0.1:9002/
jshell> URL u = new URL("http",
InetAddress.getLoopbackAddress().getHostName(), 9002, "/")
u ==> http://localhost:9002/

On Thu, Mar 14, 2019 at 9:40 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> It's just a hack, but enough to get me started so I can asses some of
> what is needed to support running the tests on an IPv6-only environment.
>
>   http://cr.openjdk.java.net/~chegar/ipv6-only-hack/
>
>   My /etc/hosts file has entries for `localhost` and the _host_, that
>   return `::1`.
>
> This is enough to get started, but it will run out of road quite soon.
> And it will break some things. Let's work towards getting a better
> solution.
>
> Also, we will need test library support for determining whether the
> platform supports: 1) IPv4, or 2) IPv6, or 3) IPv4&IPv6. I filed 8220673
> [1] to tracks this.
>
> ---
>
> Regarding what to do with URL's in test. I tried a few different
> approaches, I am leaning towards:
>
>      String host = loopbackAddress.getHostAddress();
>      if (host.contains(":"))
>          host = "[" + host + "]";
>
> Since it:
>  1) is relatively short and concise, and
>  2) ensures, in many cases, that the client and server use the same
>     IP address, and
>  3) clearly shows the actual IP protocol in use, e.g.
>     http://[0:0:0:0:0:0:0:1]:46009/zero/xxyy
>
> A sample of some tests that have been updated as above:
>   http://cr.openjdk.java.net/~chegar/8220575/webrev.0.1/ (not too bad!)
>
> -Chris.
>
> P.S. I ran into an implementation bug and filed, 8220663: "Incorrect
> handling of IPv6 addresses in Socket(Proxy.HTTP)" - the fix is straight
> forward.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8220673
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190314/5c3acdb4/attachment.html>

From chris.hegarty at oracle.com  Thu Mar 14 19:19:11 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 14 Mar 2019 19:19:11 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
 <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
Message-ID: <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>

Arthur,

> On 14 Mar 2019, at 17:44, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Most of these eventually turn the String into a URL, so using a URL directly should work?

URL constructors will work, but I would prefer to not add any more
usages of these than we already have. I plan to start a discussion about
the possibility of deprecating these constructors in the not too distant
future.

-Chris.

> jshell> URL u = new URL("http", "::1", 9002, "/")
> u ==> http://[::1]:9002/ <http://[::1]:9002/>
> jshell> URL u = new URL("http", InetAddress.getLoopbackAddress().getHostAddress(), 9002, "/")
> u ==> http://127.0.0.1:9002/ <http://127.0.0.1:9002/>
> jshell> URL u = new URL("http", InetAddress.getLoopbackAddress().getHostName(), 9002, "/")
> u ==> http://localhost:9002/ <http://localhost:9002/>
> On Thu, Mar 14, 2019 at 9:40 AM Chris Hegarty <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
> It's just a hack, but enough to get me started so I can asses some of
> what is needed to support running the tests on an IPv6-only environment.
> 
>   http://cr.openjdk.java.net/~chegar/ipv6-only-hack/ <http://cr.openjdk.java.net/~chegar/ipv6-only-hack/>
> 
>   My /etc/hosts file has entries for `localhost` and the _host_, that
>   return `::1`.
> 
> This is enough to get started, but it will run out of road quite soon.
> And it will break some things. Let's work towards getting a better
> solution.
> 
> Also, we will need test library support for determining whether the
> platform supports: 1) IPv4, or 2) IPv6, or 3) IPv4&IPv6. I filed 8220673
> [1] to tracks this.
> 
> ---
> 
> Regarding what to do with URL's in test. I tried a few different
> approaches, I am leaning towards:
> 
>      String host = loopbackAddress.getHostAddress();
>      if (host.contains(":"))
>          host = "[" + host + "]";
> 
> Since it:
>  1) is relatively short and concise, and
>  2) ensures, in many cases, that the client and server use the same
>     IP address, and
>  3) clearly shows the actual IP protocol in use, e.g.
>     http://[0:0:0:0:0:0:0:1]:46009/zero/xxyy
> 
> A sample of some tests that have been updated as above:
>   http://cr.openjdk.java.net/~chegar/8220575/webrev.0.1/ <http://cr.openjdk.java.net/~chegar/8220575/webrev.0.1/> (not too bad!)
> 
> -Chris.
> 
> P.S. I ran into an implementation bug and filed, 8220663: "Incorrect
> handling of IPv6 addresses in Socket(Proxy.HTTP)" - the fix is straight
> forward.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8220673 <https://bugs.openjdk.java.net/browse/JDK-8220673>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190314/a17ddf08/attachment-0001.html>

From christoph.langer at sap.com  Thu Mar 14 19:41:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Mar 2019 19:41:46 +0000
Subject: RFR 8179549: Typo in network properties documentation
In-Reply-To: <E08DA1B6-416E-4D82-A52B-9E7DE9469372@oracle.com>
References: <E08DA1B6-416E-4D82-A52B-9E7DE9469372@oracle.com>
Message-ID: <HE1PR0201MB22664BC137897F43A45A64658A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Looks good, +1

/Christoph

From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Chris Hegarty
Sent: Donnerstag, 14. M?rz 2019 17:47
To: net-dev <net-dev at openjdk.java.net>
Subject: RFR 8179549: Typo in network properties documentation

Trivial typo fix.

diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html
--- a/src/java.base/share/classes/java/net/doc-files/net-properties.html
+++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html
@@ -1,6 +1,6 @@
 <!DOCTYPE HTML>
 <!--
- Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
+ Copyright (c) 1998, 2019, 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
@@ -208,7 +208,7 @@
                          username. With this method existing applications that use the
                          authenticator class do not need to be modified, as long as users
                          are made aware that this notation must be used.</P>
-                    <LI><P>If a domain name is not specified as in method 2) and these
+                   <LI><P>If a domain name is not specified as in method 2) and this
                          property is defined, then its value will be used a the domain
                          name.</P>
                    </OL>




-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190314/52a7f6d9/attachment.html>

From chris.hegarty at oracle.com  Fri Mar 15 14:30:39 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 15 Mar 2019 14:30:39 +0000
Subject: RFR [13] 8220719: Allow other named NetPermissions to be used
Message-ID: <15ed4b13-4f40-f644-22fb-2d7b0c9f1339@oracle.com>


This is a review request to resolve an asymmetry that I noticed when
investigating another issue. The NetPermission specification should be
relaxed a little to allow for other target names to be used, similar to
8077055. Really 8077055 should probably have covered NetPermission too,
but was just not noticed at the time.

---

Problem

The current specification of java.net.NetPermission states: "The
following table lists all the possible NetPermission target names ...",
which implies that unless the permission target is listed in the table,
it cannot be used.

However, there is no such enforcement in the implementation, and it is
useful and somewhat common for applications / libraries to create their
own permission target names.

Solution

Relax the specification so that non-listed permissions are allowable.
The table will remain, but will only document Java SE permissions.

Specification

--- a/src/java.base/share/classes/java/net/NetPermission.java
+++ b/src/java.base/share/classes/java/net/NetPermission.java
@@ -43,7 +43,7 @@
   * signify a wildcard match. For example: "foo.*" and "*" signify a 
wildcard
   * match, while "*foo" and "a*b" do not.
   * <P>
- * The following table lists all the possible NetPermission target names,
+ * The following table lists the standard NetPermission target names,
   * and for each provides a description of what the permission allows
   * and a discussion of the risks of granting code the permission.
   *

Bug
   https://bugs.openjdk.java.net/browse/JDK-8220719
CSR
   https://bugs.openjdk.java.net/browse/JDK-8220720

-Chris.

From sean.coffey at oracle.com  Fri Mar 15 14:37:25 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 15 Mar 2019 14:37:25 +0000
Subject: RFR 8179549: Typo in network properties documentation
In-Reply-To: <HE1PR0201MB22664BC137897F43A45A64658A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <E08DA1B6-416E-4D82-A52B-9E7DE9469372@oracle.com>
 <HE1PR0201MB22664BC137897F43A45A64658A4B0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <4f91c553-bb9d-3a8a-c681-a8bd66b06476@oracle.com>

Looks fine to me also!

Regards,
Sean.

On 14/03/19 19:41, Langer, Christoph wrote:
>
> Looks good, +1
>
> /Christoph
>
> *From:*net-dev <net-dev-bounces at openjdk.java.net> *On Behalf Of *Chris 
> Hegarty
> *Sent:* Donnerstag, 14. M?rz 2019 17:47
> *To:* net-dev <net-dev at openjdk.java.net>
> *Subject:* RFR 8179549: Typo in network properties documentation
>
> Trivial typo fix.
>
> diff --git 
> a/src/java.base/share/classes/java/net/doc-files/net-properties.html 
> b/src/java.base/share/classes/java/net/doc-files/net-properties.html
>
> --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html
>
> +++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html
>
> @@ -1,6 +1,6 @@
>
>  <!DOCTYPE HTML>
>
>  <!--
>
> - Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>
> + Copyright (c) 1998, 2019, 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
>
> @@ -208,7 +208,7 @@
>
>       username. With this method existing applications that use the
>
>       authenticator class do not need to be modified, as long as users
>
>       are made aware that this notation must be used.</P>
>
> -  <LI><P>If a domain name is not specified as in method 2) and these
>
> +  <LI><P>If a domain name is not specified as in method 2) and this
>
>       property is defined, then its value will be used a the domain
>
>       name.</P>
>
> </OL>
>
>
>
>
>
> -Chris.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190315/a2550376/attachment.html>

From sean.mullan at oracle.com  Fri Mar 15 15:22:51 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 15 Mar 2019 11:22:51 -0400
Subject: RFR [13] 8220719: Allow other named NetPermissions to be used
In-Reply-To: <15ed4b13-4f40-f644-22fb-2d7b0c9f1339@oracle.com>
References: <15ed4b13-4f40-f644-22fb-2d7b0c9f1339@oracle.com>
Message-ID: <4017f2fd-00d0-34db-d64b-efd1c712e636@oracle.com>

Looks good to me.

--Sean

On 3/15/19 10:30 AM, Chris Hegarty wrote:
> 
> This is a review request to resolve an asymmetry that I noticed when
> investigating another issue. The NetPermission specification should be
> relaxed a little to allow for other target names to be used, similar to
> 8077055. Really 8077055 should probably have covered NetPermission too,
> but was just not noticed at the time.
> 
> ---
> 
> Problem
> 
> The current specification of java.net.NetPermission states: "The
> following table lists all the possible NetPermission target names ...",
> which implies that unless the permission target is listed in the table,
> it cannot be used.
> 
> However, there is no such enforcement in the implementation, and it is
> useful and somewhat common for applications / libraries to create their
> own permission target names.
> 
> Solution
> 
> Relax the specification so that non-listed permissions are allowable.
> The table will remain, but will only document Java SE permissions.
> 
> Specification
> 
> --- a/src/java.base/share/classes/java/net/NetPermission.java
> +++ b/src/java.base/share/classes/java/net/NetPermission.java
> @@ -43,7 +43,7 @@
>  ? * signify a wildcard match. For example: "foo.*" and "*" signify a 
> wildcard
>  ? * match, while "*foo" and "a*b" do not.
>  ? * <P>
> - * The following table lists all the possible NetPermission target names,
> + * The following table lists the standard NetPermission target names,
>  ? * and for each provides a description of what the permission allows
>  ? * and a discussion of the risks of granting code the permission.
>  ? *
> 
> Bug
>  ? https://bugs.openjdk.java.net/browse/JDK-8220719
> CSR
>  ? https://bugs.openjdk.java.net/browse/JDK-8220720
> 
> -Chris.

From chris.hegarty at oracle.com  Sat Mar 16 11:32:45 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 16 Mar 2019 11:32:45 +0000
Subject: RFR [13] 8220719: Allow other named NetPermissions to be used
In-Reply-To: <4017f2fd-00d0-34db-d64b-efd1c712e636@oracle.com>
References: <15ed4b13-4f40-f644-22fb-2d7b0c9f1339@oracle.com>
 <4017f2fd-00d0-34db-d64b-efd1c712e636@oracle.com>
Message-ID: <15917415-1E11-4710-B05B-C8804AD7639A@oracle.com>


> On 15 Mar 2019, at 15:22, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Looks good to me.
> 
> ?Sean

Additionally, as noted in the CSR comments, an implNote ( similar to
that of what was added by 8077055 ) could be added, to clearly spell
out the possibility of, and guidance for, other non-standard target
names. It seems worth adding to `NetPermission`, if only to keep these
`BasicPermission` subclasses consistent.

Here is the updated change ( the implNote is non-normative so not
required to be part of the CSR ).

diff --git a/src/java.base/share/classes/java/net/NetPermission.java b/src/java.base/share/classes/java/net/NetPermission.java
--- a/src/java.base/share/classes/java/net/NetPermission.java
+++ b/src/java.base/share/classes/java/net/NetPermission.java
@@ -43,7 +43,7 @@
  * signify a wildcard match. For example: "foo.*" and "*" signify a wildcard
  * match, while "*foo" and "a*b" do not.
  * <P>
- * The following table lists all the possible NetPermission target names,
+ * The following table lists the standard NetPermission target names,
  * and for each provides a description of what the permission allows
  * and a discussion of the risks of granting code the permission.
  *
@@ -158,6 +158,10 @@
    </tbody>
  * </table>
  *
+ * @implNote
+ * Implementations may define additional target names, but should use naming
+ * conventions such as reverse domain name notation to avoid name clashes.
+ *
  * @see java.security.BasicPermission
  * @see java.security.Permission
  * @see java.security.Permissions

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190316/d69c7d4b/attachment-0001.html>

From chris.hegarty at oracle.com  Sat Mar 16 11:42:01 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 16 Mar 2019 11:42:01 +0000
Subject: 8220493: Prepare Socket/ServerSocket for alternative platform
 SocketImpl  
Message-ID: <031B415F-EDEF-47DC-B951-AF51F9C4E5B7@oracle.com>

> ...
> 
> The webrev with the corresponding changes is here:
>    http://cr.openjdk.java.net/~alanb/8220493/0/webrev/ <http://cr.openjdk.java.net/~alanb/8220493/0/webrev/>I exchanged a few messages offline with Alan regarding review comments
relating to this change. I'm happy to see it move forward and it has my
Review.

Onward, to the new platform SocketImpl and related technical debt
cleanup!

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190316/4193f4a0/attachment.html>

From Alan.Bateman at oracle.com  Sat Mar 16 13:13:30 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 16 Mar 2019 13:13:30 +0000
Subject: RFR [13] 8220719: Allow other named NetPermissions to be used
In-Reply-To: <15917415-1E11-4710-B05B-C8804AD7639A@oracle.com>
References: <15ed4b13-4f40-f644-22fb-2d7b0c9f1339@oracle.com>
 <4017f2fd-00d0-34db-d64b-efd1c712e636@oracle.com>
 <15917415-1E11-4710-B05B-C8804AD7639A@oracle.com>
Message-ID: <dad9c5a7-1a21-56c8-830e-c034e85eccab@oracle.com>



On 16/03/2019 11:32, Chris Hegarty wrote:
> *
> + * @implNote
> + * Implementations may define additional target names, but should use 
> naming
> + * conventions such as reverse domain name notation to avoid name 
> clashes.
> + *
> * @see java.security.BasicPermission
> * @see java.security.Permission
> * @see java.security.Permissions
>
This looks okay to me, it's consistent with the wording in the other 
permission classes.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190316/1fd9d3b5/attachment.html>

From chris.hegarty at oracle.com  Sun Mar 17 08:53:30 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 17 Mar 2019 08:53:30 +0000
Subject: RFR [13] 8170705: sun/net/www/protocol/http/StackTraceTest.java fails
 intermittently with Invalid Http response
Message-ID: <09F87575-22A6-491B-A557-D4D609F13851@oracle.com>

This review is for a test only change. It resolves a rare intermittent
failure.

The issue is that the test creates, retrieves the local port, and
immediately closes a server socket. It then expects this port to refuse
subsequent connections. This is an anti-pattern, since on a busy machine
the port may be reused ( and subsequently accept future connections ),
before this test attempts to connect.

The solution is to use the test library `Utils::refusingEndpoint` to
retrieve a local address that will refuse connections.

http://cr.openjdk.java.net/~chegar/8170705/

-Chris.

From chris.hegarty at oracle.com  Sun Mar 17 09:14:26 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 17 Mar 2019 09:14:26 +0000
Subject: RFR [13] 8220663: Incorrect handling of IPv6 addresses in
 Socket(Proxy.HTTP) 
Message-ID: <A5D0E118-55A0-44DB-B8B5-43DEBFE5ACDF@oracle.com>


This review request resolves an issue where IPv6 socket addresses, used
in socket connect, are not correctly enclosed in square brackets when 
tunneling over HTTP.

http://cr.openjdk.java.net/~chegar/8220663/

-Chris.

From Alan.Bateman at oracle.com  Mon Mar 18 08:06:51 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Mar 2019 08:06:51 +0000
Subject: RFR [13] 8220663: Incorrect handling of IPv6 addresses in
 Socket(Proxy.HTTP)
In-Reply-To: <A5D0E118-55A0-44DB-B8B5-43DEBFE5ACDF@oracle.com>
References: <A5D0E118-55A0-44DB-B8B5-43DEBFE5ACDF@oracle.com>
Message-ID: <536eb8ae-7475-c220-2757-4de21e66b9cc@oracle.com>

On 17/03/2019 09:14, Chris Hegarty wrote:
> This review request resolves an issue where IPv6 socket addresses, used
> in socket connect, are not correctly enclosed in square brackets when
> tunneling over HTTP.
>
> http://cr.openjdk.java.net/~chegar/8220663/
>
This looks okay to me.

-Alan

From daniel.fuchs at oracle.com  Tue Mar 19 10:05:12 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 19 Mar 2019 10:05:12 +0000
Subject: RFR [13] 8170705: sun/net/www/protocol/http/StackTraceTest.java
 fails intermittently with Invalid Http response
In-Reply-To: <09F87575-22A6-491B-A557-D4D609F13851@oracle.com>
References: <09F87575-22A6-491B-A557-D4D609F13851@oracle.com>
Message-ID: <f547d029-b110-b275-4833-9fa3d5df8444@oracle.com>

This looks good to me Chris!

best regards,

-- daniel

On 17/03/2019 08:53, Chris Hegarty wrote:
> This review is for a test only change. It resolves a rare intermittent
> failure.
> 
> The issue is that the test creates, retrieves the local port, and
> immediately closes a server socket. It then expects this port to refuse
> subsequent connections. This is an anti-pattern, since on a busy machine
> the port may be reused ( and subsequently accept future connections ),
> before this test attempts to connect.
> 
> The solution is to use the test library `Utils::refusingEndpoint` to
> retrieve a local address that will refuse connections.
> 
> http://cr.openjdk.java.net/~chegar/8170705/
> 
> -Chris.
> 


From chris.hegarty at oracle.com  Tue Mar 19 10:40:06 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Mar 2019 10:40:06 +0000
Subject: RFR [13] 8153508: ContentHandler API contains link to private
 contentPathProp
Message-ID: <549E8DA3-04C5-48F8-BB50-CCE0A193E9B5@oracle.com>

This review request is to resolve a documentation regression in Java 9,
resulting from part of the changes for 8132478, where {@value
java.net.URLConnection#contentPathProp} was inadvertently replaced with
{@link java.net.URLConnection#contentPathProp}. The former will inline
with the constant field value, where the latter will link to the
( private ) field.

The fix is to just revert the incorrect change.

--- a/src/java.base/share/classes/java/net/ContentHandler.java
+++ b/src/java.base/share/classes/java/net/ContentHandler.java
@@ -47,7 +47,7 @@
  * If no content handler could be {@linkplain URLConnection#getContent() found},
  * URLConnection will look for a content handler in a user-definable set of places.
  * Users can define a vertical-bar delimited set of class prefixes
- * to search through by defining the <i>{@link java.net.URLConnection#contentPathProp}</i>
+ * to search through by defining the <i>{@value java.net.URLConnection#contentPathProp}</i>
  * property. The class name must be of the form:
  * <blockquote>
  *     <i>{package-prefix}.{major}.{minor}</i>

-Chris.

From michael.x.mcmahon at oracle.com  Tue Mar 19 11:58:38 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 19 Mar 2019 11:58:38 +0000
Subject: RFR [13] 8220663: Incorrect handling of IPv6 addresses in
 Socket(Proxy.HTTP)
In-Reply-To: <A5D0E118-55A0-44DB-B8B5-43DEBFE5ACDF@oracle.com>
References: <A5D0E118-55A0-44DB-B8B5-43DEBFE5ACDF@oracle.com>
Message-ID: <5C90D96E.1040601@oracle.com>

This looks good to me too.

- Michael.

On 17/03/2019, 09:14, Chris Hegarty wrote:
> This review request resolves an issue where IPv6 socket addresses, used
> in socket connect, are not correctly enclosed in square brackets when
> tunneling over HTTP.
>
> http://cr.openjdk.java.net/~chegar/8220663/
>
> -Chris.

From vyommani at gmail.com  Tue Mar 19 12:40:36 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Tue, 19 Mar 2019 18:10:36 +0530
Subject: RFR [13] 8153508: ContentHandler API contains link to private
 contentPathProp
In-Reply-To: <549E8DA3-04C5-48F8-BB50-CCE0A193E9B5@oracle.com>
References: <549E8DA3-04C5-48F8-BB50-CCE0A193E9B5@oracle.com>
Message-ID: <CAKysZ8yuy3zWAKdUfLvwsf_6yHihF0d6AYqWgROdewyPUG7HcA@mail.gmail.com>

Hi Chris,

Change looks good to me.
Thanks,
Vyom

On Tue, Mar 19, 2019 at 4:12 PM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> This review request is to resolve a documentation regression in Java 9,
> resulting from part of the changes for 8132478, where {@value
> java.net.URLConnection#contentPathProp} was inadvertently replaced with
> {@link java.net.URLConnection#contentPathProp}. The former will inline
> with the constant field value, where the latter will link to the
> ( private ) field.
>
> The fix is to just revert the incorrect change.
>
> --- a/src/java.base/share/classes/java/net/ContentHandler.java
> +++ b/src/java.base/share/classes/java/net/ContentHandler.java
> @@ -47,7 +47,7 @@
>   * If no content handler could be {@linkplain URLConnection#getContent()
> found},
>   * URLConnection will look for a content handler in a user-definable set
> of places.
>   * Users can define a vertical-bar delimited set of class prefixes
> - * to search through by defining the <i>{@link
> java.net.URLConnection#contentPathProp}</i>
> + * to search through by defining the <i>{@value
> java.net.URLConnection#contentPathProp}</i>
>   * property. The class name must be of the form:
>   * <blockquote>
>   *     <i>{package-prefix}.{major}.{minor}</i>
>
> -Chris.



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

From daniel.fuchs at oracle.com  Tue Mar 19 12:54:36 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 19 Mar 2019 12:54:36 +0000
Subject: RFR [13] 8153508: ContentHandler API contains link to private
 contentPathProp
In-Reply-To: <549E8DA3-04C5-48F8-BB50-CCE0A193E9B5@oracle.com>
References: <549E8DA3-04C5-48F8-BB50-CCE0A193E9B5@oracle.com>
Message-ID: <f59bb3c1-80a9-35f3-1a7a-80f79eb3bc8e@oracle.com>

Hi Chris,

Looks good to me.

@value: this is an interesting tag to know!

Powerful, useful, maybe dangerous too?
In this case the value in question is held in a *private*
static final field.
So {@link } was clearly wrong. But because the field
is private some future maintainer might well be tempted
to change its value without realizing that by doing so
he's (or she's) also changing the spec...

That said this a property name so unlikely to ever
change - and @value does avoid the risk of misspelling
the property name.

best regards,

-- daniel

On 19/03/2019 10:40, Chris Hegarty wrote:
> This review request is to resolve a documentation regression in Java 9,
> resulting from part of the changes for 8132478, where {@value
> java.net.URLConnection#contentPathProp} was inadvertently replaced with
> {@link java.net.URLConnection#contentPathProp}. The former will inline
> with the constant field value, where the latter will link to the
> ( private ) field.
> 
> The fix is to just revert the incorrect change.
> 
> --- a/src/java.base/share/classes/java/net/ContentHandler.java
> +++ b/src/java.base/share/classes/java/net/ContentHandler.java
> @@ -47,7 +47,7 @@
>    * If no content handler could be {@linkplain URLConnection#getContent() found},
>    * URLConnection will look for a content handler in a user-definable set of places.
>    * Users can define a vertical-bar delimited set of class prefixes
> - * to search through by defining the <i>{@link java.net.URLConnection#contentPathProp}</i>
> + * to search through by defining the <i>{@value java.net.URLConnection#contentPathProp}</i>
>    * property. The class name must be of the form:
>    * <blockquote>
>    *     <i>{package-prefix}.{major}.{minor}</i>
> 
> -Chris.
> 


From aeubanks at google.com  Tue Mar 19 15:31:55 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 19 Mar 2019 08:31:55 -0700
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
 <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
 <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>
Message-ID: <CAPW48soQGvfn+VjcVoMb6h2zpTu9pdebLz95nVnjENdb3+K4vw@mail.gmail.com>

(Sorry for the late response, I keep getting sidetracked by other stuff)

Is there a reason you're trying to deprecate the URL constructors?

And if we end up not using the URL constructors, then I still think it
would be nice to have a test library, since it's easy to forget to add the
"[]". Unless we fix up all the existing tests and you'll be sure to catch
any future bad uses of the loopback address in URLs in tests :)

On Thu, Mar 14, 2019 at 12:19 PM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> On 14 Mar 2019, at 17:44, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Most of these eventually turn the String into a URL, so using a URL
> directly should work?
>
>
> URL constructors will work, but I would prefer to not add any more
> usages of these than we already have. I plan to start a discussion about
> the possibility of deprecating these constructors in the not too distant
> future.
>
> -Chris.
>
> jshell> URL u = new URL("http", "::1", 9002, "/")
> u ==> http://[::1]:9002/
> jshell> URL u = new URL("http",
> InetAddress.getLoopbackAddress().getHostAddress(), 9002, "/")
> u ==> http://127.0.0.1:9002/
> jshell> URL u = new URL("http",
> InetAddress.getLoopbackAddress().getHostName(), 9002, "/")
> u ==> http://localhost:9002/
>
> On Thu, Mar 14, 2019 at 9:40 AM Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
>
>> It's just a hack, but enough to get me started so I can asses some of
>> what is needed to support running the tests on an IPv6-only environment.
>>
>>   http://cr.openjdk.java.net/~chegar/ipv6-only-hack/
>>
>>   My /etc/hosts file has entries for `localhost` and the _host_, that
>>   return `::1`.
>>
>> This is enough to get started, but it will run out of road quite soon.
>> And it will break some things. Let's work towards getting a better
>> solution.
>>
>> Also, we will need test library support for determining whether the
>> platform supports: 1) IPv4, or 2) IPv6, or 3) IPv4&IPv6. I filed 8220673
>> [1] to tracks this.
>>
>> ---
>>
>> Regarding what to do with URL's in test. I tried a few different
>> approaches, I am leaning towards:
>>
>>      String host = loopbackAddress.getHostAddress();
>>      if (host.contains(":"))
>>          host = "[" + host + "]";
>>
>> Since it:
>>  1) is relatively short and concise, and
>>  2) ensures, in many cases, that the client and server use the same
>>     IP address, and
>>  3) clearly shows the actual IP protocol in use, e.g.
>>     http://[0:0:0:0:0:0:0:1]:46009/zero/xxyy
>>
>> A sample of some tests that have been updated as above:
>>   http://cr.openjdk.java.net/~chegar/8220575/webrev.0.1/ (not too bad!)
>>
>> -Chris.
>>
>> P.S. I ran into an implementation bug and filed, 8220663: "Incorrect
>> handling of IPv6 addresses in Socket(Proxy.HTTP)" - the fix is straight
>> forward.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8220673
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190319/d0e9ffc1/attachment.html>

From chris.hegarty at oracle.com  Tue Mar 19 20:43:20 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 19 Mar 2019 20:43:20 +0000
Subject: RFR [13] 8221098: Run java/net/URL/HandlerLoop.java in othervm mode
Message-ID: <C5C9F9AF-E4B9-411F-8E34-9B2C3F5F6A72@oracle.com>

HandlerLoop should be run in othervm, as it sets the system-wide URL
protocol handler factory which could inadvertently affect subsequent
tests run in the same agentvm. An example of this is in the bug
description: https://bugs.openjdk.java.net/browse/JDK-8221098

$ hg diff test/jdk/java/net/URL/HandlerLoop.java
diff --git a/test/jdk/java/net/URL/HandlerLoop.java b/test/jdk/java/net/URL/HandlerLoop.java
--- a/test/jdk/java/net/URL/HandlerLoop.java
+++ b/test/jdk/java/net/URL/HandlerLoop.java
@@ -32,7 +32,7 @@
  * @summary Test bootstrap problem when a URLStreamHandlerFactory is loaded
  *          by the application class loader.
  * @modules java.base/sun.net.www.protocol.file
- * @run main HandlerLoop
+ * @run main/othervm HandlerLoop
  */
 public class HandlerLoop {

-Chris.

From Alan.Bateman at oracle.com  Tue Mar 19 20:45:46 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Mar 2019 20:45:46 +0000
Subject: RFR [13] 8221098: Run java/net/URL/HandlerLoop.java in othervm
 mode
In-Reply-To: <C5C9F9AF-E4B9-411F-8E34-9B2C3F5F6A72@oracle.com>
References: <C5C9F9AF-E4B9-411F-8E34-9B2C3F5F6A72@oracle.com>
Message-ID: <2fbf57b4-3bf7-e394-079d-74e27e9d07ee@oracle.com>

Looks okay, surprised this wasn't noticed before.

On 19/03/2019 20:43, Chris Hegarty wrote:
> HandlerLoop should be run in othervm, as it sets the system-wide URL
> protocol handler factory which could inadvertently affect subsequent
> tests run in the same agentvm. An example of this is in the bug
> description: https://bugs.openjdk.java.net/browse/JDK-8221098
>
> $ hg diff test/jdk/java/net/URL/HandlerLoop.java
> diff --git a/test/jdk/java/net/URL/HandlerLoop.java b/test/jdk/java/net/URL/HandlerLoop.java
> --- a/test/jdk/java/net/URL/HandlerLoop.java
> +++ b/test/jdk/java/net/URL/HandlerLoop.java
> @@ -32,7 +32,7 @@
>    * @summary Test bootstrap problem when a URLStreamHandlerFactory is loaded
>    *          by the application class loader.
>    * @modules java.base/sun.net.www.protocol.file
> - * @run main HandlerLoop
> + * @run main/othervm HandlerLoop
>    */
>   public class HandlerLoop {
>
> -Chris.


From martinrb at google.com  Tue Mar 19 21:02:08 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 19 Mar 2019 14:02:08 -0700
Subject: RFR [13] 8221098: Run java/net/URL/HandlerLoop.java in othervm
 mode
In-Reply-To: <2fbf57b4-3bf7-e394-079d-74e27e9d07ee@oracle.com>
References: <C5C9F9AF-E4B9-411F-8E34-9B2C3F5F6A72@oracle.com>
 <2fbf57b4-3bf7-e394-079d-74e27e9d07ee@oracle.com>
Message-ID: <CA+kOe09kuFq6T2h5FN+GFHVuaDwivvqWsgSvV4FASqMPTR2mUQ@mail.gmail.com>

Looks good to me.

On Tue, Mar 19, 2019 at 1:48 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> Looks okay, surprised this wasn't noticed before.
>

It was!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190319/9d541de1/attachment.html>

From ivan.gerasimov at oracle.com  Wed Mar 20 16:18:07 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 20 Mar 2019 09:18:07 -0700
Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
Message-ID: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>

Hello!

The function Java_java_net_NetworkInterface_getByInetAddress0 may throw, 
so after calling it we need to check if an exception is pending.

Would you please help review a one-line fix?

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

Thanks in advance!

-- 
With kind regards,
Ivan Gerasimov


From lundell at amazon.com  Wed Mar 20 16:28:20 2019
From: lundell at amazon.com (Lundell, Jared)
Date: Wed, 20 Mar 2019 16:28:20 +0000
Subject: Implementing a custom SocketImpl
Message-ID: <8ded3106827046fdb271d5359d5cd6fd@EX13D07UWA002.ant.amazon.com>

I have a use case where I need to implement a custom SocketImpl class and I've run into some difficulty caused by the current design of SocketImpl and the related classes in OpenJDK.  My use case is implementing a custom proxy protocol, similar in spirit to what SocksSocketImpl does but using a different wire protocol.  I need to be able to swap this proxy in underneath some existing code that I can't modify, which is why I think a SocketImpl is the appropriate solution rather than a SocketFactory (which would be much easier if I could modify the code in question).
 
SocketImpl is a public class, so I think I'm fairly safe in assuming it's intended as an extension point for application authors, but in practice it seems very difficult to actually extend.  Since I'm trying to accomplish something very similar to what SocksSocketImpl does I'd like to take the same approach that it and HttpConnectSocketImpl use of delegating all of the OS interactions to the base PlainSocketImpl class and just adding the customizations I need on top.  However, I can't extend PlainSocketImpl the way those other classes do because it is package-private and I can't create new classes in java.net.  Encapsulating a PlainSocketImpl doesn't really seem viable either since all of the methods are also protected or package-private.  The alternatives I can see are to either implement a SocketImpl completely from scratch (including all the native code) or to resort to classloader hacks to be able to add a class to java.net which extends PlainSocketImpl.  Neither of those are particularly appealing.
 
I was going to ask whether it would be reasonable to make PlainSocketImpl public, but reading through the net-dev archives[1] I discovered that there's some refactoring[2] of SocketImpl that's happening right now to prepare for Project Loom related work[3].  That change is introducing DelegatingSocketImpl and PlatformSocketImpl classes and changes SocksSocketImpl and HttpConnectSocketImpl to extend DelegatingSocketImpl rather than PlainSocketImpl.  I'd love to be able to extend DelegatingSocketImpl for my use case, but it's package-private too, nor does there appear to be a way to get a PlatformSocketImpl.
 
Is there any way that we could make it easier to implement a custom SocketImpl (or am I missing some other possible approach)?  If so, would it be reasonable to make DelegatingSocketImpl public and introduce a DefaultSocketImplFactory that can be used to construct a PlatformSocketImpl?
 
Thanks,
Jared
 
PS I just joined the net-dev mailing list, so there may be some historical context I've missed.
 
[1] https://mail.openjdk.java.net/pipermail/net-dev/2019-March/012218.html
[2] http://cr.openjdk.java.net/~alanb/8220493/0/webrev/
[3] http://openjdk.java.net/jeps/8218559


From christoph.langer at sap.com  Wed Mar 20 21:31:42 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 21:31:42 +0000
Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
In-Reply-To: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
References: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
Message-ID: <HE1PR0201MB2266F4FCF5071D2AADFFCA7A8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Ivan,

looks good to me.

Best regards
Christoph

> -----Original Message-----
> From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Ivan
> Gerasimov
> Sent: Mittwoch, 20. M?rz 2019 17:18
> To: net-dev <net-dev at openjdk.java.net>
> Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
> 
> Hello!
> 
> The function Java_java_net_NetworkInterface_getByInetAddress0 may
> throw,
> so after calling it we need to check if an exception is pending.
> 
> Would you please help review a one-line fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170494
> WEBREV: http://cr.openjdk.java.net/~igerasim/8170494/00/webrev/
> 
> Thanks in advance!
> 
> --
> With kind regards,
> Ivan Gerasimov


From vyommani at gmail.com  Thu Mar 21 05:13:03 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Thu, 21 Mar 2019 10:43:03 +0530
Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
In-Reply-To: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
References: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
Message-ID: <CAKysZ8zwfYDEXa6PonpRnnps17gLzev0AM_8b8du2E4M9Sf3KA@mail.gmail.com>

Hi Ivan,

Looks OK to me,  in case of exception "ni"  will be null  you can use the
macro(CHECK_NULL_RETURN) if you are not clearing the JNI exception, this
will save at least one additional function( "(*env)->ExceptionOccurred(env)"
) call.

Thanks,
Vyom

On Wed, Mar 20, 2019 at 9:49 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> The function Java_java_net_NetworkInterface_getByInetAddress0 may throw,
> so after calling it we need to check if an exception is pending.
>
> Would you please help review a one-line fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170494
> WEBREV: http://cr.openjdk.java.net/~igerasim/8170494/00/webrev/
>
> Thanks in advance!
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190321/6d215321/attachment.html>

From ivan.gerasimov at oracle.com  Thu Mar 21 05:57:27 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 20 Mar 2019 22:57:27 -0700
Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
In-Reply-To: <CAKysZ8zwfYDEXa6PonpRnnps17gLzev0AM_8b8du2E4M9Sf3KA@mail.gmail.com>
References: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
 <CAKysZ8zwfYDEXa6PonpRnnps17gLzev0AM_8b8du2E4M9Sf3KA@mail.gmail.com>
Message-ID: <51e82b2f-0bac-9849-67b2-7deb7b0d4ada@oracle.com>

Thanks Vyom!


On 3/20/19 10:13 PM, Vyom Tiwari wrote:
> Hi Ivan,
>
> Looks OK to me,  in case of exception "ni"  will be null you can use 
> the macro(CHECK_NULL_RETURN) if you are not clearing the JNI 
> exception, this will save at least one additional function( 
> "(*env)->ExceptionOccurred(env)" ) call.

Java_java_net_NetworkInterface_getByInetAddress0 may return NULL if 
there were no interfaces found.
We should not return from getMulticastInterface() in this case.

With kind regards,
Ivan

>
> Thanks,
> Vyom
>
> On Wed, Mar 20, 2019 at 9:49 PM Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hello!
>
>     The function Java_java_net_NetworkInterface_getByInetAddress0 may
>     throw,
>     so after calling it we need to check if an exception is pending.
>
>     Would you please help review a one-line fix?
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170494
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8170494/00/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8170494/00/webrev/>
>
>     Thanks in advance!
>
>     -- 
>     With kind regards,
>     Ivan Gerasimov
>
>
>
> -- 
> Thanks,
> Vyom

-- 
With kind regards,
Ivan Gerasimov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190320/b5ef9289/attachment-0001.html>

From vyommani at gmail.com  Thu Mar 21 06:33:10 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Thu, 21 Mar 2019 12:03:10 +0530
Subject: RFR 8170494 : JNI exception pending in PlainDatagramSocketImpl.c
In-Reply-To: <51e82b2f-0bac-9849-67b2-7deb7b0d4ada@oracle.com>
References: <56eeb503-e955-16d4-4d65-98f73d7e47dd@oracle.com>
 <CAKysZ8zwfYDEXa6PonpRnnps17gLzev0AM_8b8du2E4M9Sf3KA@mail.gmail.com>
 <51e82b2f-0bac-9849-67b2-7deb7b0d4ada@oracle.com>
Message-ID: <CAKysZ8wtnhMWL-z5S6+Emg9RUx+7dLbJb0_Fjmt-eVAP+ObS+A@mail.gmail.com>

Hi Ivan,

thanks for explanation, code change looks good to me.

Thanks,
Vyom

On Thu, Mar 21, 2019 at 11:26 AM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Thanks Vyom!
>
> On 3/20/19 10:13 PM, Vyom Tiwari wrote:
>
> Hi Ivan,
>
> Looks OK to me,  in case of exception "ni"  will be null  you can use the
> macro(CHECK_NULL_RETURN) if you are not clearing the JNI exception, this
> will save at least one additional function( "
> (*env)->ExceptionOccurred(env)" ) call.
>
>
> Java_java_net_NetworkInterface_getByInetAddress0 may return NULL if there
> were no interfaces found.
> We should not return from getMulticastInterface() in this case.
>
> With kind regards,
> Ivan
>
>
> Thanks,
> Vyom
>
> On Wed, Mar 20, 2019 at 9:49 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
>
>> Hello!
>>
>> The function Java_java_net_NetworkInterface_getByInetAddress0 may throw,
>> so after calling it we need to check if an exception is pending.
>>
>> Would you please help review a one-line fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170494
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8170494/00/webrev/
>>
>> Thanks in advance!
>>
>> --
>> With kind regards,
>> Ivan Gerasimov
>>
>>
>
> --
> Thanks,
> Vyom
>
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190321/4c60536c/attachment.html>

From Alan.Bateman at oracle.com  Thu Mar 21 15:06:19 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2019 15:06:19 +0000
Subject: 8221259: New tests for java.net.Socket to exercise long standing
 behavior
Message-ID: <fb0f356b-d59b-5a1d-f59e-884859245427@oracle.com>

There are a number of tests in niosocketimpl-branch of the sandbox that 
are needed to exercise Socket in ways that aren't fully exercised by the 
existing tests. I'd like to bring some of these tests into jdk/jdk in 
advance of the new NIO based SocketImpl, specifically:

- AsyncShutdown: invoke shutdownInput/shutdownOutput when a thread is 
blocked in read/write
- ConnectionReset: tests the behavior specified by 
Socket::getInputStream for cases where a connection is reset with data 
and no data available
- UdpSocket: uses a deprecated Socket constructor to create UDP socket
- Timeouts: test timed connect, read and accept operations. This tests 
several scenarios that the existing tests using timeouts do not exercise.

The webrev with the tests is here:
 ? http://cr.openjdk.java.net/~alanb/8221259/webrev/

-Alan

From chris.hegarty at oracle.com  Thu Mar 21 16:06:59 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 21 Mar 2019 16:06:59 +0000
Subject: 8221259: New tests for java.net.Socket to exercise long standing
 behavior
In-Reply-To: <fb0f356b-d59b-5a1d-f59e-884859245427@oracle.com>
References: <fb0f356b-d59b-5a1d-f59e-884859245427@oracle.com>
Message-ID: <6bd83419-fece-d573-1137-a95c77e3873a@oracle.com>

Alan,

On 21/03/2019 15:06, Alan Bateman wrote:
> There are a number of tests in niosocketimpl-branch of the sandbox that 
> are needed to exercise Socket in ways that aren't fully exercised by the 
> existing tests. I'd like to bring some of these tests into jdk/jdk in 
> advance of the new NIO based SocketImpl, specifically:
> 
> - AsyncShutdown: invoke shutdownInput/shutdownOutput when a thread is 
> blocked in read/write
> - ConnectionReset: tests the behavior specified by 
> Socket::getInputStream for cases where a connection is reset with data 
> and no data available
> - UdpSocket: uses a deprecated Socket constructor to create UDP socket
> - Timeouts: test timed connect, read and accept operations. This tests 
> several scenarios that the existing tests using timeouts do not exercise.
> 
> The webrev with the tests is here:
>  ? http://cr.openjdk.java.net/~alanb/8221259/webrev/

This is great. Nice compact self-contained tests.

Very timely, I'm just preparing a patch to resolve 8219446: "Specify
behaviour of timeout accepting methods of Socket and ServerSocket if
timeout is negative".  I will drop the tests for IAE, since you already
have it covered.  You can drop the comment in the that test which states
that the behaviour is unspecified, or I will remove it as part of
8219446. Whichever is pushed first I guess.

-Chris.

From Alan.Bateman at oracle.com  Thu Mar 21 17:36:56 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2019 17:36:56 +0000
Subject: 8221259: New tests for java.net.Socket to exercise long standing
 behavior
In-Reply-To: <6bd83419-fece-d573-1137-a95c77e3873a@oracle.com>
References: <fb0f356b-d59b-5a1d-f59e-884859245427@oracle.com>
 <6bd83419-fece-d573-1137-a95c77e3873a@oracle.com>
Message-ID: <e77696ba-12eb-2aea-7188-4d2336ff6e1b@oracle.com>

On 21/03/2019 16:06, Chris Hegarty wrote:
> :
>
> Very timely, I'm just preparing a patch to resolve 8219446: "Specify
> behaviour of timeout accepting methods of Socket and ServerSocket if
> timeout is negative".? I will drop the tests for IAE, since you already
> have it covered.? You can drop the comment in the that test which states
> that the behaviour is unspecified, or I will remove it as part of
> 8219446. Whichever is pushed first I guess.
Thanks, probably better if you drop the comments in the changes for 
JDK-8219446, that way the change-set will make it obvious that there are 
tests for the change.

-Alan

From Alan.Bateman at oracle.com  Fri Mar 22 08:27:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Mar 2019 08:27:15 +0000
Subject: Implementing a custom SocketImpl
In-Reply-To: <8ded3106827046fdb271d5359d5cd6fd@EX13D07UWA002.ant.amazon.com>
References: <8ded3106827046fdb271d5359d5cd6fd@EX13D07UWA002.ant.amazon.com>
Message-ID: <f4c17aaf-a523-2b5b-9450-7c7310f754b6@oracle.com>

On 20/03/2019 16:28, Lundell, Jared wrote:
> I have a use case where I need to implement a custom SocketImpl class and I've run into some difficulty caused by the current design of SocketImpl and the related classes in OpenJDK.  My use case is implementing a custom proxy protocol, similar in spirit to what SocksSocketImpl does but using a different wire protocol.  I need to be able to swap this proxy in underneath some existing code that I can't modify, which is why I think a SocketImpl is the appropriate solution rather than a SocketFactory (which would be much easier if I could modify the code in question).
>   
> SocketImpl is a public class, so I think I'm fairly safe in assuming it's intended as an extension point for application authors, but in practice it seems very difficult to actually extend.  Since I'm trying to accomplish something very similar to what SocksSocketImpl does I'd like to take the same approach that it and HttpConnectSocketImpl use of delegating all of the OS interactions to the base PlainSocketImpl class and just adding the customizations I need on top.  However, I can't extend PlainSocketImpl the way those other classes do because it is package-private and I can't create new classes in java.net.  Encapsulating a PlainSocketImpl doesn't really seem viable either since all of the methods are also protected or package-private.  The alternatives I can see are to either implement a SocketImpl completely from scratch (including all the native code) or to resort to classloader hacks to be able to add a class to java.net which extends PlainSocketImpl.  Neither of those are particularly appealing.
>   
> I was going to ask whether it would be reasonable to make PlainSocketImpl public, but reading through the net-dev archives[1] I discovered that there's some refactoring[2] of SocketImpl that's happening right now to prepare for Project Loom related work[3].  That change is introducing DelegatingSocketImpl and PlatformSocketImpl classes and changes SocksSocketImpl and HttpConnectSocketImpl to extend DelegatingSocketImpl rather than PlainSocketImpl.  I'd love to be able to extend DelegatingSocketImpl for my use case, but it's package-private too, nor does there appear to be a way to get a PlatformSocketImpl.
>   
> Is there any way that we could make it easier to implement a custom SocketImpl (or am I missing some other possible approach)?  If so, would it be reasonable to make DelegatingSocketImpl public and introduce a DefaultSocketImplFactory that can be used to construct a PlatformSocketImpl?
>
SocketImpl is a JDK 1.0 era mechanism. You are right that it's very 
difficult to implement, partly because it requires a complete 
implementation with native code, partly because SocketImpl is very 
under-specified.

The built-in SocketImpls are not public and not intended to be used 
directly. It wouldn't be wrong to introduce a way to create custom 
SocketImplFactory with a reference to a SocketImplFactory that creates 
platform SocketImpl instances - that would amount to providing a way to 
interpose or wrap instances of the platform SocketImpl. The JDK has 
something like this to allow a custom file system provider interpose on 
the built-in file system provider. However, in the case of SocketImpl 
then it would be opening a basket of snakes that would require 
significant specification and security work to contain. So I don't think 
we want to go there.

That said, one approach to explore is changing "new 
Socket(Proxy.NO_PROXY)" to return a Socket with a platform SocketImpl. 
That constructor was added in Java SE 1.5 and I believe, but not 
certain, that the intention was for NO_PROXY to not use a custom 
SocketImpl. If that were changed then it would mean that custom 
SocketImpls could create a Socket to delegate to. They can do this now 
except for the case that Socket.setSocketImplFactory has been called to 
configure the system-wide SocketImplFactory, which I think is what you 
are trying to do.

-Alan




From chris.hegarty at oracle.com  Fri Mar 22 11:44:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 22 Mar 2019 11:44:51 +0000
Subject: RFR [13] 8219446: Specify behaviour of timeout accepting methods of
 Socket and ServerSocket if timeout is negative
Message-ID: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>

This review request is for a specification only change. It clarifies the
behaviour of the timeout accepting methods of Socket and ServerSocket,
when the given a negative timeout. A negative timeout value will result
in an IllegalArgumentException being thrown.

These methods already throw IllegalArgumentException, so this change is
effectively documenting existing long-standing behaviour.

Note: Before this change, ServerSocket::setSoTimeout defers the timeout
argument checking to its socket impl. The default plain socket impl
throws IllegalArgumentException if given a negative timeout. It is
possible, but unlikely, that an alternative custom socket impl could
have accepted a negative timeout, but the effects of such are
unspecified and unknown. After this change, ServerSocket will no longer
defer the timeout argument checking, it will check its own arguments.

Webrev:
   http://cr.openjdk.java.net/~chegar/8219446/webrev.00/
CSR:
   https://bugs.openjdk.java.net/browse/JDK-8221248

-Chris.

From Alan.Bateman at oracle.com  Fri Mar 22 11:54:24 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Mar 2019 11:54:24 +0000
Subject: RFR [13] 8219446: Specify behaviour of timeout accepting methods
 of Socket and ServerSocket if timeout is negative
In-Reply-To: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>
References: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>
Message-ID: <7fc1e229-0d5b-5fd5-1291-889b76313016@oracle.com>

On 22/03/2019 11:44, Chris Hegarty wrote:
> This review request is for a specification only change. It clarifies the
> behaviour of the timeout accepting methods of Socket and ServerSocket,
> when the given a negative timeout. A negative timeout value will result
> in an IllegalArgumentException being thrown.
>
> These methods already throw IllegalArgumentException, so this change is
> effectively documenting existing long-standing behaviour.
>
> Note: Before this change, ServerSocket::setSoTimeout defers the timeout
> argument checking to its socket impl. The default plain socket impl
> throws IllegalArgumentException if given a negative timeout. It is
> possible, but unlikely, that an alternative custom socket impl could
> have accepted a negative timeout, but the effects of such are
> unspecified and unknown. After this change, ServerSocket will no longer
> defer the timeout argument checking, it will check its own arguments.
>
> Webrev:
> ? http://cr.openjdk.java.net/~chegar/8219446/webrev.00/
> CSR:
> ? https://bugs.openjdk.java.net/browse/JDK-8221248
This looks okay to me, I've added myself as Reviewer on the CSR.

One small suggestion for the exception message is use "timeout < 0" to 
avoid needing to use "can't" in the message.

-Alan

From chris.hegarty at oracle.com  Fri Mar 22 11:59:04 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 22 Mar 2019 11:59:04 +0000
Subject: RFR [13] 8219446: Specify behaviour of timeout accepting methods
 of Socket and ServerSocket if timeout is negative
In-Reply-To: <7fc1e229-0d5b-5fd5-1291-889b76313016@oracle.com>
References: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>
 <7fc1e229-0d5b-5fd5-1291-889b76313016@oracle.com>
Message-ID: <dd7fbe17-8e47-b732-a10c-e5c766d86081@oracle.com>


On 22/03/2019 11:54, Alan Bateman wrote:
> ...
>> Webrev:
>> ? http://cr.openjdk.java.net/~chegar/8219446/webrev.00/
>> CSR:
>> ? https://bugs.openjdk.java.net/browse/JDK-8221248
> This looks okay to me, I've added myself as Reviewer on the CSR.
> 
> One small suggestion for the exception message is use "timeout < 0" to 
> avoid needing to use "can't" in the message.

Good point. Updated in place.

( My bad! I cut'n'paste that crummy message from elsewhere
   in Socket, but forgot to update it! )

-Chris.

From daniel.fuchs at oracle.com  Fri Mar 22 12:14:22 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 22 Mar 2019 12:14:22 +0000
Subject: RFR [13] 8219446: Specify behaviour of timeout accepting methods
 of Socket and ServerSocket if timeout is negative
In-Reply-To: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>
References: <7dd36be2-6a2a-b3f0-4c62-c4151a28ecb2@oracle.com>
Message-ID: <22262d58-0d95-dc80-86eb-f32fba23c05f@oracle.com>

Hi Chris,

Looks like the right thing to do.

+1

-- daniel

On 22/03/2019 11:44, Chris Hegarty wrote:
> This review request is for a specification only change. It clarifies the
> behaviour of the timeout accepting methods of Socket and ServerSocket,
> when the given a negative timeout. A negative timeout value will result
> in an IllegalArgumentException being thrown.
> 
> These methods already throw IllegalArgumentException, so this change is
> effectively documenting existing long-standing behaviour.
> 
> Note: Before this change, ServerSocket::setSoTimeout defers the timeout
> argument checking to its socket impl. The default plain socket impl
> throws IllegalArgumentException if given a negative timeout. It is
> possible, but unlikely, that an alternative custom socket impl could
> have accepted a negative timeout, but the effects of such are
> unspecified and unknown. After this change, ServerSocket will no longer
> defer the timeout argument checking, it will check its own arguments.
> 
> Webrev:
>  ? http://cr.openjdk.java.net/~chegar/8219446/webrev.00/
> CSR:
>  ? https://bugs.openjdk.java.net/browse/JDK-8221248
> 
> -Chris.


From chris.hegarty at oracle.com  Fri Mar 22 17:02:41 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 22 Mar 2019 17:02:41 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <CAPW48soQGvfn+VjcVoMb6h2zpTu9pdebLz95nVnjENdb3+K4vw@mail.gmail.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
 <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
 <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>
 <CAPW48soQGvfn+VjcVoMb6h2zpTu9pdebLz95nVnjENdb3+K4vw@mail.gmail.com>
Message-ID: <4BB7CB69-D492-4917-B70C-CFD358E6B1D0@oracle.com>

Arthur,

> On 19 Mar 2019, at 15:31, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> (Sorry for the late response, I keep getting sidetracked by other stuff)
> 
> Is there a reason you're trying to deprecate the URL constructors?

Yes, they are generally more error-prone than using URI, since they
don?t encode illegal characters in the various components.

> And if we end up not using the URL constructors, then I still think it would be nice to have a test library, since it's easy to forget to add the "[]". Unless we fix up all the existing tests and you'll be sure to catch any future bad uses of the loopback address in URLs in tests :)

Test library support would be fine. ( it would require some additional
jtreg tags and imports, but that is not a reason to avoid it )

If we do add test library support, then maybe we could take the
opportunity to construct it in a way where we could gain experience for
future possible projects, e.g.

   URIBuilder.newBuilder()
          .scheme("http")
          .host("www.example.com")
          .path("/sample")
          .query("version=12")
          .build()
          .toURL();
          
With suitable encoding / raw variants. Daniel has prototyped something
similar for the URI update investigation work.
          
-Chris.        

From aeubanks at google.com  Fri Mar 22 17:07:02 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 22 Mar 2019 10:07:02 -0700
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <4BB7CB69-D492-4917-B70C-CFD358E6B1D0@oracle.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
 <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
 <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>
 <CAPW48soQGvfn+VjcVoMb6h2zpTu9pdebLz95nVnjENdb3+K4vw@mail.gmail.com>
 <4BB7CB69-D492-4917-B70C-CFD358E6B1D0@oracle.com>
Message-ID: <CAPW48srBw-xx8A7omL=cU7L9KroNs7RoxQMfaxWhO=A3buXooA@mail.gmail.com>

Sounds good, I'll work on that.

On Fri, Mar 22, 2019 at 10:02 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> > On 19 Mar 2019, at 15:31, Arthur Eubanks <aeubanks at google.com> wrote:
> >
> > (Sorry for the late response, I keep getting sidetracked by other stuff)
> >
> > Is there a reason you're trying to deprecate the URL constructors?
>
> Yes, they are generally more error-prone than using URI, since they
> don?t encode illegal characters in the various components.
>
> > And if we end up not using the URL constructors, then I still think it
> would be nice to have a test library, since it's easy to forget to add the
> "[]". Unless we fix up all the existing tests and you'll be sure to catch
> any future bad uses of the loopback address in URLs in tests :)
>
> Test library support would be fine. ( it would require some additional
> jtreg tags and imports, but that is not a reason to avoid it )
>
> If we do add test library support, then maybe we could take the
> opportunity to construct it in a way where we could gain experience for
> future possible projects, e.g.
>
>    URIBuilder.newBuilder()
>           .scheme("http")
>           .host("www.example.com")
>           .path("/sample")
>           .query("version=12")
>           .build()
>           .toURL();
>
> With suitable encoding / raw variants. Daniel has prototyped something
> similar for the URI update investigation work.
>
> -Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190322/7032349a/attachment.html>

From chris.hegarty at oracle.com  Fri Mar 22 17:19:49 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 22 Mar 2019 17:19:49 +0000
Subject: Regarding 8220575: Correctly format test URI's that contain a
 retrieved IPv6 address
In-Reply-To: <CAPW48srBw-xx8A7omL=cU7L9KroNs7RoxQMfaxWhO=A3buXooA@mail.gmail.com>
References: <79336212-a65a-152e-3a92-8867668c82b0@oracle.com>
 <68cb6665-8c57-0b00-84b7-ae396471092a@oracle.com>
 <CA+kOe097VUyptDRX1LV_J1VYtPiETWSexkCyB_SmZXX5bttUFg@mail.gmail.com>
 <F3D7FAAD-C982-416A-83BE-2973988AFA0C@oracle.com>
 <CAPW48sp6mu4E+sbVZ=eXRNhS5w9hPrrSm=uNQDhivWUtSMqn9w@mail.gmail.com>
 <AA229C35-2323-4474-A303-F00A7F973ABC@oracle.com>
 <CAPW48soQGvfn+VjcVoMb6h2zpTu9pdebLz95nVnjENdb3+K4vw@mail.gmail.com>
 <4BB7CB69-D492-4917-B70C-CFD358E6B1D0@oracle.com>
 <CAPW48srBw-xx8A7omL=cU7L9KroNs7RoxQMfaxWhO=A3buXooA@mail.gmail.com>
Message-ID: <D6DD02C8-4BC7-4F35-B68C-B90284E8E98E@oracle.com>

Arthur,

> On 22 Mar 2019, at 17:07, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Sounds good, I'll work on that.
> 
> On Fri, Mar 22, 2019 at 10:02 AM Chris Hegarty <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
> ...
>  Daniel has prototyped something
> similar for the URI update investigation work.
> 

Here is a link to what I referred to in the previous email.

http://cr.openjdk.java.net/~dfuchs/writeups/updating-uri/iri-prototype/webrev/src/java.base/share/classes/java/net/IRI.java.html <http://cr.openjdk.java.net/~dfuchs/writeups/updating-uri/iri-prototype/webrev/src/java.base/share/classes/java/net/IRI.java.html>

From about line 5287. It?s a good place to start. It will be a
test library class so doesn?t need to be perfect to start, it can
evolve as needed.

I hope that it will result in less error-prone and more readable
test code.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190322/e7266032/attachment.html>

From chris.hegarty at oracle.com  Sat Mar 23 09:07:20 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 23 Mar 2019 09:07:20 +0000
Subject: Implementing a custom SocketImpl
In-Reply-To: <8ded3106827046fdb271d5359d5cd6fd@EX13D07UWA002.ant.amazon.com>
References: <8ded3106827046fdb271d5359d5cd6fd@EX13D07UWA002.ant.amazon.com>
Message-ID: <F0F44FEB-5D72-498C-9289-620E56BC6981@oracle.com>

Jared,

As Alan mentioned, SocketImpl was designed 20+ years ago and has not
kept pace with other areas of the platform. Mainly because it has not
been used all that much. As part of JEP 337 [1] a decision was made to
NOT simply provide a RDMA socket impl for the sockets part of this
work, but rather to subclass all three, j.n.Socket, j.n.ServerSocket,
and j.n.SocketImpl, and take control of their construction ( through
factories ). There are just too many entanglements between these
classes now, and unraveling them without all the history and knowledge
of their original purpose and intent is risky and time consuming.

The current work in this area, that Alan and others are doing, is really
just the minimum possible to lay the foundations for a replacement,
loom-friendly, platform socket impl, and address some small amount of
technical debt along the way. In general, we're not investing in
improving support for plugging in SocketImpls. Our recommendation is to
provide custom socket implementations in a similar way to what is being
done in JEP 337.

If it makes sense for the library or code that you are using to allow
other socket implementations ( which is what you want to do ), then
maybe submit a pull-request to that project to add support for a socket
factory. Socket Factory is a better alternative than trying to provide
a custom socket impl through setSocketImplFactory.

I understand that this may not be the answer that you were hoping for,
but it is highly unlikely that we're going to start investing in this
area any time soon.

-Chris.

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

> On 20 Mar 2019, at 16:28, Lundell, Jared <lundell at amazon.com> wrote:
> 
> I have a use case where I need to implement a custom SocketImpl class and I've run into some difficulty caused by the current design of SocketImpl and the related classes in OpenJDK.  My use case is implementing a custom proxy protocol, similar in spirit to what SocksSocketImpl does but using a different wire protocol.  I need to be able to swap this proxy in underneath some existing code that I can't modify, which is why I think a SocketImpl is the appropriate solution rather than a SocketFactory (which would be much easier if I could modify the code in question).
> 
> SocketImpl is a public class, so I think I'm fairly safe in assuming it's intended as an extension point for application authors, but in practice it seems very difficult to actually extend.  Since I'm trying to accomplish something very similar to what SocksSocketImpl does I'd like to take the same approach that it and HttpConnectSocketImpl use of delegating all of the OS interactions to the base PlainSocketImpl class and just adding the customizations I need on top.  However, I can't extend PlainSocketImpl the way those other classes do because it is package-private and I can't create new classes in java.net.  Encapsulating a PlainSocketImpl doesn't really seem viable either since all of the methods are also protected or package-private.  The alternatives I can see are to either implement a SocketImpl completely from scratch (including all the native code) or to resort to classloader hacks to be able to add a class to java.net which extends PlainSocketImpl.  Neither of those are particularly appealing.
> 
> I was going to ask whether it would be reasonable to make PlainSocketImpl public, but reading through the net-dev archives[1] I discovered that there's some refactoring[2] of SocketImpl that's happening right now to prepare for Project Loom related work[3].  That change is introducing DelegatingSocketImpl and PlatformSocketImpl classes and changes SocksSocketImpl and HttpConnectSocketImpl to extend DelegatingSocketImpl rather than PlainSocketImpl.  I'd love to be able to extend DelegatingSocketImpl for my use case, but it's package-private too, nor does there appear to be a way to get a PlatformSocketImpl.
> 
> Is there any way that we could make it easier to implement a custom SocketImpl (or am I missing some other possible approach)?  If so, would it be reasonable to make DelegatingSocketImpl public and introduce a DefaultSocketImplFactory that can be used to construct a PlatformSocketImpl?
> 
> Thanks,
> Jared
> 
> PS I just joined the net-dev mailing list, so there may be some historical context I've missed.
> 
> [1] https://mail.openjdk.java.net/pipermail/net-dev/2019-March/012218.html
> [2] http://cr.openjdk.java.net/~alanb/8220493/0/webrev/
> [3] http://openjdk.java.net/jeps/8218559
> 


From thomas.stuefe at gmail.com  Mon Mar 25 07:01:08 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 08:01:08 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
Message-ID: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>

Hi David,

(added net-dev, awt-dev, security-dev since part of these fixes are in
their territory)

On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> A few queries, comments and concerns ...
>
> On 25/03/2019 6:58 am, Thomas St?fe wrote:
> > Hi all,
> >
> > After a long time I tried to build a Windows 32bit VM (VS2017) and
> failed;
>
> I'm somewhat surprised as I thought someone was actively doing Windows
> 32-bit builds out there, plus there are shared code changes that should
> also have been caught by non-Windows 32-bit builds. :(
>
>
Not sure what others do. I did a 32bit windows build, slowdebug, warning
enabled, and it failed with those 5+ issues.


> > multiple errors and warnings. Lets reverse the bitrot:
> >
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >
> > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE
> > callbacks), printf specifiers etc.
> >
> > Had to supress a warning in os_windows_x86.cpp - I was surprised by this
> > since this did not look 32bit specifc, do we disable warnings on Windows
> > 64bit builds?
>
> What version of VS2017? We use VS2017 15.9.6 and we don't disable warnings.
>
>
I use VS2017 CE. Not sure which version spcifically, but my compiler is at

Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86


> > The error I had in vmStructs.cpp was a bit weird: compiler complained
> about
> > an assignment of an enum value defined like this:
> >
> > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >
> > to an uint64_t variable, complaining about narrowing. I did not find out
> > what his problem was. In the end, I decided to add an explicit cast to
> > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>
> Not at all sure that's the right fix. In markOop.hpp we see that value
> gets special treatment on Windows-x64:
>

> #ifndef _WIN64
>           ,hash_mask               = right_n_bits(hash_bits),
>           hash_mask_in_place       = (address_word)hash_mask << hash_shift
> #endif
>    };
>
>    // Alignment of JavaThread pointers encoded in object header required
> by biased locking
>    enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
>    };
>
> #ifdef _WIN64
>      // These values are too big for Win64
>      const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      const static uintptr_t hash_mask_in_place  =
>                              (address_word)hash_mask << hash_shift;
> #endif
>
> perhaps something special is needed for Windows-x86. I'm unclear how the
> values can be "too big" ??
>
>
I banged my head against this for an hour or so and I think this is a
compiler bug.

What I get is:

warning C4838: conversion from '' to 'uint64_t' requires a narrowing
conversion

(Note the empty "from" string.)

Here are my tries to provoke the error:

VMLongConstantEntry iii[] = {  { "hallo", markOopDesc::hash_mask_in_place
}, {0,0}};  <<< this fails
VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
 << but this succeeds
uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too

I have no clue what this means. It is difficult to fix since the expression
is hidden in such a macro pile. But I think either we go with my change or
we disable the warning for win32 for the whole section.


> >
> > With this patch we can build with warnings enabled on 32bit and 64bit
> > windows.
> >
> > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev
> and
> > core-libs-dev.
>
> Don't see anything that actually comes under core-libs-dev. Looks like
> one net-dev, one awt-dev and one security-dev. Sorry.
>
>
Okay, I will add them.


> Cheers,
> David
> -----
>
>
Thanks for reviewing,

Thomas


> > Thanks, Thomas
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/19c5a7c1/attachment.html>

From david.holmes at oracle.com  Mon Mar 25 07:17:05 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Mar 2019 17:17:05 +1000
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
Message-ID: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>

Hi Thomas,

On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> Hi David,
> 
> (added net-dev, awt-dev, security-dev since part of these fixes are in 
> their territory)

May be better to split up the reviews, cross-posting that many groups 
gets very messy given most people won't be subscribed to them all - 
myself included.

> On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     A few queries, comments and concerns ...
> 
>     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>      > Hi all,
>      >
>      > After a long time I tried to build a Windows 32bit VM (VS2017)
>     and failed;
> 
>     I'm somewhat surprised as I thought someone was actively doing Windows
>     32-bit builds out there, plus there are shared code changes that should
>     also have been caught by non-Windows 32-bit builds. :(
> 
> 
> Not sure what others?do. I did a 32bit windows build, slowdebug, warning 
> enabled, and it failed with those 5+ issues.
> 
>      > multiple errors and warnings. Lets reverse the bitrot:
>      >
>      > cr:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>      >
>      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>      >
>      > Most of the fixes are trivial: Calling convention mismatches (awt
>     DTRACE
>      > callbacks), printf specifiers etc.
>      >
>      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>     by this
>      > since this did not look 32bit specifc, do we disable warnings on
>     Windows
>      > 64bit builds?
> 
>     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>     warnings.
> 
> 
> I use VS2017 CE. Not sure which version spcifically, but my compiler is at
> 
> Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86

I think that would equate to an older version - 15.7

MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)

Any chance you can upgrade to latest version? (Especially in light of 
the apparent compiler bug you cite below.)

Thanks,
David
-----

>      > The error I had in vmStructs.cpp was a bit weird: compiler
>     complained about
>      > an assignment of an enum value defined like this:
>      >
>      > hash_mask_in_place? ? ? ?= (address_word)hash_mask << hash_shift
>      >
>      > to an uint64_t variable, complaining about narrowing. I did not
>     find out
>      > what his problem was. In the end, I decided to add an explicit
>     cast to
>      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> 
>     Not at all sure that's the right fix. In markOop.hpp we see that value
>     gets special treatment on Windows-x64:
> 
> 
>     #ifndef _WIN64
>      ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?= right_n_bits(hash_bits),
>      ? ? ? ? ? hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>     hash_shift
>     #endif
>      ? ?};
> 
>      ? ?// Alignment of JavaThread pointers encoded in object header
>     required
>     by biased locking
>      ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift + epoch_bits)
>      ? ?};
> 
>     #ifdef _WIN64
>      ? ? ?// These values are too big for Win64
>      ? ? ?const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      ? ? ?const static uintptr_t hash_mask_in_place? =
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(address_word)hash_mask << hash_shift;
>     #endif
> 
>     perhaps something special is needed for Windows-x86. I'm unclear how
>     the
>     values can be "too big" ??
> 
> 
> I banged my head against this for an hour or so and I think this is a 
> compiler bug.
> 
> What I get is:
> 
> warning C4838: conversion from '' to 'uint64_t' requires a narrowing 
> conversion
> 
> (Note the empty "from" string.)
> 
> Here are my tries to provoke the error:
> 
> VMLongConstantEntry iii[] = {? { "hallo", 
> markOopDesc::hash_mask_in_place }, {0,0}};? <<< this fails
> VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };  
>  ?<< but this succeeds
> uint64_t iii = markOopDesc::hash_mask_in_place;? ?<< this succeeds? too
> 
> I have no clue what this means. It is difficult to fix since the 
> expression is hidden in such a macro pile. But I think either we go with 
> my change or we disable the warning for win32 for the whole section.
> 
>      >
>      > With this patch we can build with warnings enabled on 32bit and 64bit
>      > windows.
>      >
>      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>     hs-dev and
>      > core-libs-dev.
> 
>     Don't see anything that actually comes under core-libs-dev. Looks like
>     one net-dev, one awt-dev and one security-dev. Sorry.
> 
> 
> Okay, I will add them.
> 
>     Cheers,
>     David
>     -----
> 
> 
> Thanks for reviewing,
> 
> Thomas
> 
>      > Thanks, Thomas
>      >
> 

From thomas.stuefe at gmail.com  Mon Mar 25 12:44:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:44:21 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
Message-ID: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>

Hi David,

Updating vs2017 did not help :/

Cheers, Thomas

On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> > Hi David,
> >
> > (added net-dev, awt-dev, security-dev since part of these fixes are in
> > their territory)
>
> May be better to split up the reviews, cross-posting that many groups
> gets very messy given most people won't be subscribed to them all -
> myself included.
>


>
> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     Hi Thomas,
> >
> >     A few queries, comments and concerns ...
> >
> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
> >      > Hi all,
> >      >
> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
> >     and failed;
> >
> >     I'm somewhat surprised as I thought someone was actively doing
> Windows
> >     32-bit builds out there, plus there are shared code changes that
> should
> >     also have been caught by non-Windows 32-bit builds. :(
> >
> >
> > Not sure what others do. I did a 32bit windows build, slowdebug, warning
> > enabled, and it failed with those 5+ issues.
> >
> >      > multiple errors and warnings. Lets reverse the bitrot:
> >      >
> >      > cr:
> >      >
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >      >
> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >      >
> >      > Most of the fixes are trivial: Calling convention mismatches (awt
> >     DTRACE
> >      > callbacks), printf specifiers etc.
> >      >
> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
> >     by this
> >      > since this did not look 32bit specifc, do we disable warnings on
> >     Windows
> >      > 64bit builds?
> >
> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
> >     warnings.
> >
> >
> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
> at
> >
> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>
> I think that would equate to an older version - 15.7
>
> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
> Any chance you can upgrade to latest version? (Especially in light of
> the apparent compiler bug you cite below.)
>
> Thanks,
> David
> -----
>
> >      > The error I had in vmStructs.cpp was a bit weird: compiler
> >     complained about
> >      > an assignment of an enum value defined like this:
> >      >
> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >      >
> >      > to an uint64_t variable, complaining about narrowing. I did not
> >     find out
> >      > what his problem was. In the end, I decided to add an explicit
> >     cast to
> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> >
> >     Not at all sure that's the right fix. In markOop.hpp we see that
> value
> >     gets special treatment on Windows-x64:
> >
> >
> >     #ifndef _WIN64
> >                ,hash_mask               = right_n_bits(hash_bits),
> >                hash_mask_in_place       = (address_word)hash_mask <<
> >     hash_shift
> >     #endif
> >         };
> >
> >         // Alignment of JavaThread pointers encoded in object header
> >     required
> >     by biased locking
> >         enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
> >         };
> >
> >     #ifdef _WIN64
> >           // These values are too big for Win64
> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
> >           const static uintptr_t hash_mask_in_place  =
> >                                   (address_word)hash_mask << hash_shift;
> >     #endif
> >
> >     perhaps something special is needed for Windows-x86. I'm unclear how
> >     the
> >     values can be "too big" ??
> >
> >
> > I banged my head against this for an hour or so and I think this is a
> > compiler bug.
> >
> > What I get is:
> >
> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
> > conversion
> >
> > (Note the empty "from" string.)
> >
> > Here are my tries to provoke the error:
> >
> > VMLongConstantEntry iii[] = {  { "hallo",
> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
> >   << but this succeeds
> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
> >
> > I have no clue what this means. It is difficult to fix since the
> > expression is hidden in such a macro pile. But I think either we go with
> > my change or we disable the warning for win32 for the whole section.
> >
> >      >
> >      > With this patch we can build with warnings enabled on 32bit and
> 64bit
> >      > windows.
> >      >
> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
> >     hs-dev and
> >      > core-libs-dev.
> >
> >     Don't see anything that actually comes under core-libs-dev. Looks
> like
> >     one net-dev, one awt-dev and one security-dev. Sorry.
> >
> >
> > Okay, I will add them.
> >
> >     Cheers,
> >     David
> >     -----
> >
> >
> > Thanks for reviewing,
> >
> > Thomas
> >
> >      > Thanks, Thomas
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/b23f0f6d/attachment.html>

From thomas.stuefe at gmail.com  Mon Mar 25 12:45:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:45:21 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
Message-ID: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>

Hi all,

Following David's suggestion, I withdraw this bug and will open issues for
each area separately.

Cheers, Thomas



On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> Updating vs2017 did not help :/
>
> Cheers, Thomas
>
> On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>> > Hi David,
>> >
>> > (added net-dev, awt-dev, security-dev since part of these fixes are in
>> > their territory)
>>
>> May be better to split up the reviews, cross-posting that many groups
>> gets very messy given most people won't be subscribed to them all -
>> myself included.
>>
>
>
>>
>> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
>> > <mailto:david.holmes at oracle.com>> wrote:
>> >
>> >     Hi Thomas,
>> >
>> >     A few queries, comments and concerns ...
>> >
>> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>> >      > Hi all,
>> >      >
>> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
>> >     and failed;
>> >
>> >     I'm somewhat surprised as I thought someone was actively doing
>> Windows
>> >     32-bit builds out there, plus there are shared code changes that
>> should
>> >     also have been caught by non-Windows 32-bit builds. :(
>> >
>> >
>> > Not sure what others do. I did a 32bit windows build, slowdebug,
>> warning
>> > enabled, and it failed with those 5+ issues.
>> >
>> >      > multiple errors and warnings. Lets reverse the bitrot:
>> >      >
>> >      > cr:
>> >      >
>> >
>> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>> >      >
>> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>> >      >
>> >      > Most of the fixes are trivial: Calling convention mismatches (awt
>> >     DTRACE
>> >      > callbacks), printf specifiers etc.
>> >      >
>> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>> >     by this
>> >      > since this did not look 32bit specifc, do we disable warnings on
>> >     Windows
>> >      > 64bit builds?
>> >
>> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>> >     warnings.
>> >
>> >
>> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
>> at
>> >
>> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>>
>> I think that would equate to an older version - 15.7
>>
>> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>>
>> Any chance you can upgrade to latest version? (Especially in light of
>> the apparent compiler bug you cite below.)
>>
>> Thanks,
>> David
>> -----
>>
>> >      > The error I had in vmStructs.cpp was a bit weird: compiler
>> >     complained about
>> >      > an assignment of an enum value defined like this:
>> >      >
>> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
>> >      >
>> >      > to an uint64_t variable, complaining about narrowing. I did not
>> >     find out
>> >      > what his problem was. In the end, I decided to add an explicit
>> >     cast to
>> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>> >
>> >     Not at all sure that's the right fix. In markOop.hpp we see that
>> value
>> >     gets special treatment on Windows-x64:
>> >
>> >
>> >     #ifndef _WIN64
>> >                ,hash_mask               = right_n_bits(hash_bits),
>> >                hash_mask_in_place       = (address_word)hash_mask <<
>> >     hash_shift
>> >     #endif
>> >         };
>> >
>> >         // Alignment of JavaThread pointers encoded in object header
>> >     required
>> >     by biased locking
>> >         enum { biased_lock_alignment    = 2 << (epoch_shift +
>> epoch_bits)
>> >         };
>> >
>> >     #ifdef _WIN64
>> >           // These values are too big for Win64
>> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
>> >           const static uintptr_t hash_mask_in_place  =
>> >                                   (address_word)hash_mask << hash_shift;
>> >     #endif
>> >
>> >     perhaps something special is needed for Windows-x86. I'm unclear how
>> >     the
>> >     values can be "too big" ??
>> >
>> >
>> > I banged my head against this for an hour or so and I think this is a
>> > compiler bug.
>> >
>> > What I get is:
>> >
>> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
>> > conversion
>> >
>> > (Note the empty "from" string.)
>> >
>> > Here are my tries to provoke the error:
>> >
>> > VMLongConstantEntry iii[] = {  { "hallo",
>> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
>> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place
>> };
>> >   << but this succeeds
>> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
>> >
>> > I have no clue what this means. It is difficult to fix since the
>> > expression is hidden in such a macro pile. But I think either we go
>> with
>> > my change or we disable the warning for win32 for the whole section.
>> >
>> >      >
>> >      > With this patch we can build with warnings enabled on 32bit and
>> 64bit
>> >      > windows.
>> >      >
>> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>> >     hs-dev and
>> >      > core-libs-dev.
>> >
>> >     Don't see anything that actually comes under core-libs-dev. Looks
>> like
>> >     one net-dev, one awt-dev and one security-dev. Sorry.
>> >
>> >
>> > Okay, I will add them.
>> >
>> >     Cheers,
>> >     David
>> >     -----
>> >
>> >
>> > Thanks for reviewing,
>> >
>> > Thomas
>> >
>> >      > Thanks, Thomas
>> >      >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/c6690e25/attachment-0001.html>

From thomas.stuefe at gmail.com  Mon Mar 25 13:15:18 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 14:15:18 +0100
Subject: RFR(xxxs): 8221406: Windows 32bit build error in
 NetworkInterface_winXP.c
Message-ID: <CAA-vtUyeGvmUm_Y44n_3qN=sRUasu22U2T5B=YQ+wiry2PsoCw@mail.gmail.com>

Hi all,

please review this tiny fix to a windows 32 build warning:

Issue:  https://bugs.openjdk.java.net/browse/JDK-8221406
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8221406-windows32-buildfixes-networkinterface_winxp.c/webrev.00/webrev/

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/ce3802e4/attachment.html>

From cancomert at gmail.com  Mon Mar 25 15:46:41 2019
From: cancomert at gmail.com (can comert)
Date: Mon, 25 Mar 2019 16:46:41 +0100
Subject: Patch for JDK Bug 8173620
Message-ID: <CAPnQxbZE=TPeAJk8LC07XnJ4XiVsCXuPaeTvjBicB4Avp9Wqjg@mail.gmail.com>

Hello everyone,

I have created a commit for fixing the JDK Bug 8173620 which is documented
here:
https://bugs.openjdk.java.net/browse/JDK-8173620

Here is content for the commit for fixing the "Should not reach here" error
in case of the call to underlying Proxy implementation throws an exception:
https://github.com/AdoptOpenJDK/openjdk-jdk8u/pull/4/commits/d6e6370baad78dfaf34003bb8642f1a5cc9fa064

I have not created a Mercury patch for that but before going down on that
road,
I would like to ask what is the acceptability of this patch and is it
possible to apply this into next Bug fix version for Java 8?

If it is possible and you can accept the change then I can create a Mercury
patch with same or similar content.

Best Regards,
Can C?mert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/4a61eeff/attachment.html>

From Alan.Bateman at oracle.com  Mon Mar 25 15:59:04 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 25 Mar 2019 15:59:04 +0000
Subject: Patch for JDK Bug 8173620
In-Reply-To: <CAPnQxbZE=TPeAJk8LC07XnJ4XiVsCXuPaeTvjBicB4Avp9Wqjg@mail.gmail.com>
References: <CAPnQxbZE=TPeAJk8LC07XnJ4XiVsCXuPaeTvjBicB4Avp9Wqjg@mail.gmail.com>
Message-ID: <6fde6d5f-4353-8eab-3cfd-b2dc95c1830c@oracle.com>

On 25/03/2019 15:46, can comert wrote:
> Hello everyone,
>
> I have created a commit for fixing the JDK Bug 8173620 which is 
> documented here:
> https://bugs.openjdk.java.net/browse/JDK-8173620
>
> Here is content for the commit for fixing the "Should not reach here" 
> error in case of the call to underlying Proxy implementation throws an 
> exception:
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/pull/4/commits/d6e6370baad78dfaf34003bb8642f1a5cc9fa064
>
> I have not created a Mercury patch for that but before going down on 
> that road,
> I would like to ask what is the acceptability of this patch and is it 
> possible to apply this into next Bug fix version for Java 8?
>
> If it is possible and you can accept the change then I can create a 
> Mercury patch with same or similar content.
>
We can't review/accept patches that are not contributed via OpenJDK 
infrastructure.

In any case, can you check jdk/jdk as I suspect this issue has already 
been fixed for JDK 13. Specifically, as part of JDK-8220493, the 
doTunnelling method was changed to handle any IOException thrown by the 
HTTP protocol handler.

-Alan

From alexey.ivanov at oracle.com  Mon Mar 25 14:46:25 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 25 Mar 2019 14:46:25 +0000
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
 <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
Message-ID: <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>

Hi Thomas,

There was a thread about failing build on 32 bit Windows:
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023767.html

It continued in February 2019:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024925.html

Fast debug builds were affected. Likely there was mismatch between 
CALLBACK / JNICALL macro:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024972.html
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024973.html

Magnus suggested a fix:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024996.html

Yet there was no reply as whether it fixed the debug build or not.


Hope these pointers help.

Regards,
Alexey

On 25/03/2019 12:45, Thomas St?fe wrote:
> Hi all,
>
> Following David's suggestion, I withdraw this bug and will open issues 
> for each area separately.
>
> Cheers, Thomas
>
>
>
> On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     Updating vs2017 did not help :/
>
>     Cheers, Thomas
>
>     On Mon, Mar 25, 2019 at 8:17 AM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         Hi Thomas,
>
>         On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>         > Hi David,
>         >
>         > (added net-dev, awt-dev, security-dev since part of these
>         fixes are in
>         > their territory)
>
>         May be better to split up the reviews, cross-posting that many
>         groups
>         gets very messy given most people won't be subscribed to them
>         all -
>         myself included.
>
>
>
>         > On Mon, Mar 25, 2019 at 1:34 AM David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         > <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>         >
>         >? ? ?Hi Thomas,
>         >
>         >? ? ?A few queries, comments and concerns ...
>         >
>         >? ? ?On 25/03/2019 6:58 am, Thomas St?fe wrote:
>         >? ? ? > Hi all,
>         >? ? ? >
>         >? ? ? > After a long time I tried to build a Windows 32bit VM
>         (VS2017)
>         >? ? ?and failed;
>         >
>         >? ? ?I'm somewhat surprised as I thought someone was actively
>         doing Windows
>         >? ? ?32-bit builds out there, plus there are shared code
>         changes that should
>         >? ? ?also have been caught by non-Windows 32-bit builds. :(
>         >
>         >
>         > Not sure what others?do. I did a 32bit windows build,
>         slowdebug, warning
>         > enabled, and it failed with those 5+ issues.
>         >
>         >? ? ? > multiple errors and warnings. Lets reverse the bitrot:
>         >? ? ? >
>         >? ? ? > cr:
>         >? ? ? >
>         >
>         http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>         >? ? ? >
>         >? ? ? > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>         >? ? ? >
>         >? ? ? > Most of the fixes are trivial: Calling convention
>         mismatches (awt
>         >? ? ?DTRACE
>         >? ? ? > callbacks), printf specifiers etc.
>         >? ? ? >
>         >? ? ? > Had to supress a warning in os_windows_x86.cpp - I
>         was surprised
>         >? ? ?by this
>         >? ? ? > since this did not look 32bit specifc, do we disable
>         warnings on
>         >? ? ?Windows
>         >? ? ? > 64bit builds?
>         >
>         >? ? ?What version of VS2017? We use VS2017 15.9.6 and we
>         don't disable
>         >? ? ?warnings.
>         >
>         >
>         > I use VS2017 CE. Not sure which version spcifically, but my
>         compiler is at
>         >
>         > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431
>         for x86
>
>         I think that would equate to an older version - 15.7
>
>         MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
>         Any chance you can upgrade to latest version? (Especially in
>         light of
>         the apparent compiler bug you cite below.)
>
>         Thanks,
>         David
>         -----
>
>         >? ? ? > The error I had in vmStructs.cpp was a bit weird:
>         compiler
>         >? ? ?complained about
>         >? ? ? > an assignment of an enum value defined like this:
>         >? ? ? >
>         >? ? ? > hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>         hash_shift
>         >? ? ? >
>         >? ? ? > to an uint64_t variable, complaining about narrowing.
>         I did not
>         >? ? ?find out
>         >? ? ? > what his problem was. In the end, I decided to add an
>         explicit
>         >? ? ?cast to
>         >? ? ? > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see
>         vmStructs.hpp).
>         >
>         >? ? ?Not at all sure that's the right fix. In markOop.hpp we
>         see that value
>         >? ? ?gets special treatment on Windows-x64:
>         >
>         >
>         >? ? ?#ifndef _WIN64
>         >? ? ? ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?=
>         right_n_bits(hash_bits),
>         >? ? ? ? ? ? ? ? hash_mask_in_place? ? ? ?=
>         (address_word)hash_mask <<
>         >? ? ?hash_shift
>         >? ? ?#endif
>         >? ? ? ? ?};
>         >
>         >? ? ? ? ?// Alignment of JavaThread pointers encoded in
>         object header
>         >? ? ?required
>         >? ? ?by biased locking
>         >? ? ? ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift
>         + epoch_bits)
>         >? ? ? ? ?};
>         >
>         >? ? ?#ifdef _WIN64
>         >? ? ? ? ? ?// These values are too big for Win64
>         >? ? ? ? ? ?const static uintptr_t hash_mask =
>         right_n_bits(hash_bits);
>         >? ? ? ? ? ?const static uintptr_t hash_mask_in_place? =
>         > ?(address_word)hash_mask << hash_shift;
>         >? ? ?#endif
>         >
>         >? ? ?perhaps something special is needed for Windows-x86. I'm
>         unclear how
>         >? ? ?the
>         >? ? ?values can be "too big" ??
>         >
>         >
>         > I banged my head against this for an hour or so and I think
>         this is a
>         > compiler bug.
>         >
>         > What I get is:
>         >
>         > warning C4838: conversion from '' to 'uint64_t' requires a
>         narrowing
>         > conversion
>         >
>         > (Note the empty "from" string.)
>         >
>         > Here are my tries to provoke the error:
>         >
>         > VMLongConstantEntry iii[] = {? { "hallo",
>         > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails
>         > VMLongConstantEntry iii = { "hallo",
>         markOopDesc::hash_mask_in_place };
>         >? ?<< but this succeeds
>         > uint64_t iii = markOopDesc::hash_mask_in_place; ?<< this
>         succeeds? too
>         >
>         > I have no clue what this means. It is difficult to fix since
>         the
>         > expression is hidden in such a macro pile. But I think
>         either we go with
>         > my change or we disable the warning for win32 for the whole
>         section.
>         >
>         >? ? ? >
>         >? ? ? > With this patch we can build with warnings enabled on
>         32bit and 64bit
>         >? ? ? > windows.
>         >? ? ? >
>         >? ? ? > Since patch fixes both hotspot and JDK parts, I'm
>         sending it to
>         >? ? ?hs-dev and
>         >? ? ? > core-libs-dev.
>         >
>         >? ? ?Don't see anything that actually comes under
>         core-libs-dev. Looks like
>         >? ? ?one net-dev, one awt-dev and one security-dev. Sorry.
>         >
>         >
>         > Okay, I will add them.
>         >
>         >? ? ?Cheers,
>         >? ? ?David
>         >? ? ?-----
>         >
>         >
>         > Thanks for reviewing,
>         >
>         > Thomas
>         >
>         >? ? ? > Thanks, Thomas
>         >? ? ? >
>         >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/9e143f6c/attachment-0001.html>

From cancomert at gmail.com  Mon Mar 25 16:42:58 2019
From: cancomert at gmail.com (can comert)
Date: Mon, 25 Mar 2019 17:42:58 +0100
Subject: Patch for JDK Bug 8173620
In-Reply-To: <6fde6d5f-4353-8eab-3cfd-b2dc95c1830c@oracle.com>
References: <CAPnQxbZE=TPeAJk8LC07XnJ4XiVsCXuPaeTvjBicB4Avp9Wqjg@mail.gmail.com>
 <6fde6d5f-4353-8eab-3cfd-b2dc95c1830c@oracle.com>
Message-ID: <CAPnQxbY60N+nB6Q+PKDTcj=ZwV2VShaNaTxkwq3zUF4caBapig@mail.gmail.com>

Hello Alan,

Thanks for your quick reply.

Yes, I have found it in a commit as a part of JDK-8220493 as you said.
http://hg.openjdk.java.net/jdk/jdk/rev/b5a73f22b2bd#l3.134

I think this should fix the issue, thanks for your help.

Best Regards,
Can C?mert


Alan Bateman <Alan.Bateman at oracle.com>, 25 Mar 2019 Pzt, 16:59 tarihinde
?unu yazd?:

> On 25/03/2019 15:46, can comert wrote:
> > Hello everyone,
> >
> > I have created a commit for fixing the JDK Bug 8173620 which is
> > documented here:
> > https://bugs.openjdk.java.net/browse/JDK-8173620
> >
> > Here is content for the commit for fixing the "Should not reach here"
> > error in case of the call to underlying Proxy implementation throws an
> > exception:
> >
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/pull/4/commits/d6e6370baad78dfaf34003bb8642f1a5cc9fa064
> >
> > I have not created a Mercury patch for that but before going down on
> > that road,
> > I would like to ask what is the acceptability of this patch and is it
> > possible to apply this into next Bug fix version for Java 8?
> >
> > If it is possible and you can accept the change then I can create a
> > Mercury patch with same or similar content.
> >
> We can't review/accept patches that are not contributed via OpenJDK
> infrastructure.
>
> In any case, can you check jdk/jdk as I suspect this issue has already
> been fixed for JDK 13. Specifically, as part of JDK-8220493, the
> doTunnelling method was changed to handle any IOException thrown by the
> HTTP protocol handler.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/f23c3645/attachment.html>

From aeubanks at google.com  Mon Mar 25 22:18:29 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 25 Mar 2019 15:18:29 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
Message-ID: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>

Hi,

This patch replaces hardcoded "http://127.0.0.1/" in tests with a new
URIBuilder and InetAddress.getLoopbackAddress().getHostAddress(). Creating
a URIBuilder helper class was discussed in a previous thread on net-dev.

http://cr.openjdk.java.net/~aeubanks/8220575/webrev.00/index.html

One problem I came across was in
test/jdk/sun/net/www/protocol/http/B6890349.java, where "/foo\nbar" in a
URL is not the same as "/foo\nbar" in a URI, so I'd like some help in that
one test (you'll see some print statements in there, which produce
different output). Otherwise, the other tests pass locally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190325/560b85f0/attachment.html>

From christoph.langer at sap.com  Tue Mar 26 08:41:04 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 08:41:04 +0000
Subject: RFR(xxxs): 8221406: Windows 32bit build error in
 NetworkInterface_winXP.c
In-Reply-To: <CAA-vtUyeGvmUm_Y44n_3qN=sRUasu22U2T5B=YQ+wiry2PsoCw@mail.gmail.com>
References: <CAA-vtUyeGvmUm_Y44n_3qN=sRUasu22U2T5B=YQ+wiry2PsoCw@mail.gmail.com>
Message-ID: <HE1PR0201MB22666B63B189524DD43E35B28A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Thomas,

looks good ??

Christoph

From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Thomas St?fe
Sent: Montag, 25. M?rz 2019 14:15
To: net-dev <net-dev at openjdk.java.net>
Subject: RFR(xxxs): 8221406: Windows 32bit build error in NetworkInterface_winXP.c

Hi all,

please review this tiny fix to a windows 32 build warning:

Issue:  https://bugs.openjdk.java.net/browse/JDK-8221406
cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221406-windows32-buildfixes-networkinterface_winxp.c/webrev.00/webrev/

Thanks, Thomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190326/a88b467f/attachment.html>

From thomas.stuefe at gmail.com  Tue Mar 26 08:50:10 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 26 Mar 2019 09:50:10 +0100
Subject: RFR(xxxs): 8221406: Windows 32bit build error in
 NetworkInterface_winXP.c
In-Reply-To: <HE1PR0201MB22666B63B189524DD43E35B28A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <CAA-vtUyeGvmUm_Y44n_3qN=sRUasu22U2T5B=YQ+wiry2PsoCw@mail.gmail.com>
 <HE1PR0201MB22666B63B189524DD43E35B28A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUxHHm5U_0Jy_=ZnG=ysKci+1QkLWhELuqxEJ_+y0knmNA@mail.gmail.com>

Thanks, Christoph!

On Tue, Mar 26, 2019, 9:41 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Thomas,
>
>
>
> looks good ??
>
>
>
> Christoph
>
>
>
> *From:* net-dev <net-dev-bounces at openjdk.java.net> *On Behalf Of *Thomas
> St?fe
> *Sent:* Montag, 25. M?rz 2019 14:15
> *To:* net-dev <net-dev at openjdk.java.net>
> *Subject:* RFR(xxxs): 8221406: Windows 32bit build error in
> NetworkInterface_winXP.c
>
>
>
> Hi all,
>
>
>
> please review this tiny fix to a windows 32 build warning:
>
>
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8221406
>
> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8221406-windows32-buildfixes-networkinterface_winxp.c/webrev.00/webrev/
>
>
>
> Thanks, Thomas
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190326/e13eb38a/attachment-0001.html>

From daniel.fuchs at oracle.com  Tue Mar 26 12:05:10 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 26 Mar 2019 12:05:10 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
Message-ID: <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>

Hi Arthur,

I believe this looks good. Here are my comments so far:

I like the fact that you kept the builder implementation
very minimal, and focused on what these tests actually
need. We can always revisit that later if we come across
new tests that need more than what your proposed implementation
currently offer.

There are a couple of things that would need to be fixed in your
webrev though:

1. There are some places where the root path "/" is replaced by
    no path - so the proposed changes may change the test in
    subtle ways - which I'd rather take out of the picture.

    For instance - the following files seem to
    be missing a `.path("/")` line:

    ExpiredCookieTest.java, NoProxyTest.java, NullSelector.java

    For these three files the orginal URL ended with "/", but
    as per your changes the new URL won't.

2. B6890349.java

    Using URI.toURL() in this test will change the nature of
    the test. I believe that in this specific case using the
    multi-arg URL constuctor should be preferred.
    The reason is that URI as per its specification encodes
    illegal characters, while URL as per its specification,
    does not. So going through URI here will lead to a
    different URL than the one that the test is testing.

    I see from your mail that you have noticed the difference :-)

    For this one test I'd suggest to make an exception and
    change the URL construction to:

    URL u = new URL("http",
                    InetAddress.getLoopbackAddress().getHostAddress(),
                    port,
                    "/foo\nbar");

    Even if we get to deprecating the URL constructors in the
    future this would still be a valid case for using them in
    a test.

3. on the 'nit' side it's a bit strange to see
    the sequence of calls `.host(..).path(..).port(..)`,
    as `.host(..).port(..).path(..)` would feel
    natural - but don't feel obliged to make this change.

best regards,

-- daniel

On 25/03/2019 22:18, Arthur Eubanks wrote:
> Hi,
> 
> This patch replaces hardcoded "http://127.0.0.1/" in tests with a new 
> URIBuilder and InetAddress.getLoopbackAddress().getHostAddress(). 
> Creating a URIBuilder helper class was discussed in a previous thread on 
> net-dev.
> 
> http://cr.openjdk.java.net/~aeubanks/8220575/webrev.00/index.html
> 
> One problem I came across was in 
> test/jdk/sun/net/www/protocol/http/B6890349.java, where "/foo\nbar" in a 
> URL is not the same as "/foo\nbar" in a URI, so I'd like some help in 
> that one test (you'll see some print statements in there, which produce 
> different output). Otherwise, the other tests pass locally.


From pavel.rappo at oracle.com  Tue Mar 26 13:41:25 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 26 Mar 2019 13:41:25 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
Message-ID: <8C37C42A-A267-4F82-80FF-AB22EB10E5F2@oracle.com>

I've applied your patch and run through our test system. The 

    sun/net/www/protocol/http/B6890349.java 
    
test failed just like you said. I'm happy to say that it was the only test in
the whole networking area that failed. So test-wise it looks good.

-Pavel


From chris.hegarty at oracle.com  Tue Mar 26 14:15:14 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 26 Mar 2019 14:15:14 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
Message-ID: <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>

Arthur,

I like the way this is turning out.

> On 26 Mar 2019, at 12:05, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> ...
> 2. B6890349.java
> 
>   Using URI.toURL() in this test will change the nature of
>   the test. I believe that in this specific case using the
>   multi-arg URL constuctor should be preferred.
>   The reason is that URI as per its specification encodes
>   illegal characters, while URL as per its specification,
>   does not. So going through URI here will lead to a
>   different URL than the one that the test is testing.
> 
>   I see from your mail that you have noticed the difference :-)
> 
>   For this one test I'd suggest to make an exception and
>   change the URL construction to:
> 
>   URL u = new URL("http",
>                   InetAddress.getLoopbackAddress().getHostAddress(),
>                   port,
>                   "/foo\nbar");
> 
>   Even if we get to deprecating the URL constructors in the
>   future this would still be a valid case for using them in
>   a test.

Right. The above accepting-illegal-characters behaviour is one of
the reasons, non-test code, should avoid the URL constructors. 

> 3. on the 'nit' side it's a bit strange to see
>   the sequence of calls `.host(..).path(..).port(..)`,
>   as `.host(..).port(..).path(..)` would feel
>   natural - but don't feel obliged to make this change.

URI component-wise ordering makes the code a little easier to 
read. I?d just do it.

I dislike noisy tests, but it would be helpful for these tests to print
the URL that has been constructed ( System.out.println("URL: " + url) ).
It will make it easier to verify the test's behaviour on different
system configuration ( I usually just look in the jtr file )

-Chris.



From aeubanks at google.com  Tue Mar 26 16:51:10 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 26 Mar 2019 09:51:10 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
Message-ID: <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>

Changed B6890349.java to use URL constructor.
Changed sequence of URIBuilder calls to `.host().port().path()`.
Added missing `.path("/")`.
Added logging for most of the constructed URLs.

PTAL:
http://cr.openjdk.java.net/~aeubanks/8220575/webrev.01/test/jdk/com/sun/net/httpserver/bugs/B6373555.java.udiff.html

I was considering adding a buildURL() to URIBuilder since so many of these
URIs end up getting converted to a URL in the end. Not sure if that's a
good idea or not.

On Tue, Mar 26, 2019 at 7:15 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> I like the way this is turning out.
>
> > On 26 Mar 2019, at 12:05, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> >
> > ...
> > 2. B6890349.java
> >
> >   Using URI.toURL() in this test will change the nature of
> >   the test. I believe that in this specific case using the
> >   multi-arg URL constuctor should be preferred.
> >   The reason is that URI as per its specification encodes
> >   illegal characters, while URL as per its specification,
> >   does not. So going through URI here will lead to a
> >   different URL than the one that the test is testing.
> >
> >   I see from your mail that you have noticed the difference :-)
> >
> >   For this one test I'd suggest to make an exception and
> >   change the URL construction to:
> >
> >   URL u = new URL("http",
> >                   InetAddress.getLoopbackAddress().getHostAddress(),
> >                   port,
> >                   "/foo\nbar");
> >
> >   Even if we get to deprecating the URL constructors in the
> >   future this would still be a valid case for using them in
> >   a test.
>
> Right. The above accepting-illegal-characters behaviour is one of
> the reasons, non-test code, should avoid the URL constructors.
>
> > 3. on the 'nit' side it's a bit strange to see
> >   the sequence of calls `.host(..).path(..).port(..)`,
> >   as `.host(..).port(..).path(..)` would feel
> >   natural - but don't feel obliged to make this change.
>
> URI component-wise ordering makes the code a little easier to
> read. I?d just do it.
>
> I dislike noisy tests, but it would be helpful for these tests to print
> the URL that has been constructed ( System.out.println("URL: " + url) ).
> It will make it easier to verify the test's behaviour on different
> system configuration ( I usually just look in the jtr file )
>
> -Chris.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190326/c3eb3547/attachment.html>

From daniel.fuchs at oracle.com  Tue Mar 26 17:23:35 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 26 Mar 2019 17:23:35 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
Message-ID: <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>


Hi Arthur,

On 26/03/2019 16:51, Arthur Eubanks wrote:
> Changed B6890349.java to use URL constructor.
> Changed sequence of URIBuilder calls to `.host().port().path()`.
> Added missing `.path("/")`.
> Added logging for most of the constructed URLs.
> 
> PTAL:
> http://cr.openjdk.java.net/~aeubanks/8220575/webrev.01/test/jdk/com/sun/net/httpserver/bugs/B6373555.java.udiff.html

Looks good! Thanks for doing that.


> I was considering adding a buildURL() to URIBuilder since so many of 
> these URIs end up getting converted to a URL in the end. Not sure if 
> that's a good idea or not.

Your call. If you do then maybe we should be considering adding:

    public URIBuilder loopback() {
       return host(InetAddress.getLoopbackAddress().getHostAddress());
    }

and I can't say I like URIBuilder::buildURL much - maybe
URIBuilder::toURL would be a better name in that case?

best regards,

-- daniel

From aeubanks at google.com  Tue Mar 26 19:06:47 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 26 Mar 2019 12:06:47 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
Message-ID: <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>

>
> > I was considering adding a buildURL() to URIBuilder since so many of
> > these URIs end up getting converted to a URL in the end. Not sure if
> > that's a good idea or not.
>
> Your call. If you do then maybe we should be considering adding:
>
>     public URIBuilder loopback() {
>        return host(InetAddress.getLoopbackAddress().getHostAddress());
>     }
>
> and I can't say I like URIBuilder::buildURL much - maybe
> URIBuilder::toURL would be a better name in that case?
>
> I've added `loopback()` and `toURL()`/`toURLUnchecked()` and used those in
the tests:
http://cr.openjdk.java.net/~aeubanks/8220575/webrev.02/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190326/454b5c9e/attachment.html>

From aeubanks at google.com  Tue Mar 26 22:07:17 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 26 Mar 2019 15:07:17 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
 <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
Message-ID: <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>

Forgot to add URIBuilder, fixed in:
http://cr.openjdk.java.net/~aeubanks/8220575/webrev.03/index.html

On Tue, Mar 26, 2019 at 12:06 PM Arthur Eubanks <aeubanks at google.com> wrote:

> > I was considering adding a buildURL() to URIBuilder since so many of
>> > these URIs end up getting converted to a URL in the end. Not sure if
>> > that's a good idea or not.
>>
>> Your call. If you do then maybe we should be considering adding:
>>
>>     public URIBuilder loopback() {
>>        return host(InetAddress.getLoopbackAddress().getHostAddress());
>>     }
>>
>> and I can't say I like URIBuilder::buildURL much - maybe
>> URIBuilder::toURL would be a better name in that case?
>>
>> I've added `loopback()` and `toURL()`/`toURLUnchecked()` and used those
> in the tests:
> http://cr.openjdk.java.net/~aeubanks/8220575/webrev.02/index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190326/a4ce539d/attachment.html>

From chris.hegarty at oracle.com  Wed Mar 27 11:29:55 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 Mar 2019 11:29:55 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
 <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
 <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>
Message-ID: <f2dad669-f896-0ca5-9aa8-aaa4689e8e32@oracle.com>

Arthur,

On 26/03/2019 22:07, Arthur Eubanks wrote:
> Forgot to add URIBuilder, fixed in:
> http://cr.openjdk.java.net/~aeubanks/8220575/webrev.03/index.html

I am happy with this. Just a few minor comments.

1) test/jdk/java/net/ResponseCache/Test2.java

    83         url = URIBuilder.newBuilder()
    84             .scheme("http")
    85             .loopback()
    86             .port(port)
    87             .path("/test/foo")
    88             .toURLUnchecked();
    89             System.out.println("URL: " + url);   <<<< here

    Can you please remove the extra indentation on L89.

2) Can you please use the standard four-space indentation
    in URIBuilder.

Otherwise, Reviewed.

-Chris.

From aeubanks at google.com  Wed Mar 27 15:53:27 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 27 Mar 2019 08:53:27 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <f2dad669-f896-0ca5-9aa8-aaa4689e8e32@oracle.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
 <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
 <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>
 <f2dad669-f896-0ca5-9aa8-aaa4689e8e32@oracle.com>
Message-ID: <CAPW48so4CsL6pYhWufPFyi6nYrCq2et9b_aN7FPGF1YntHyQ1A@mail.gmail.com>

> 1) test/jdk/java/net/ResponseCache/Test2.java
>
>     83         url = URIBuilder.newBuilder()
>     84             .scheme("http")
>     85             .loopback()
>     86             .port(port)
>     87             .path("/test/foo")
>     88             .toURLUnchecked();
>     89             System.out.println("URL: " + url);   <<<< here
>
>     Can you please remove the extra indentation on L89.
>
> 2) Can you please use the standard four-space indentation
>     in URIBuilder.
>
Done: http://cr.openjdk.java.net/~aeubanks/8220575/webrev.04/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190327/51eb0846/attachment.html>

From daniel.fuchs at oracle.com  Wed Mar 27 17:02:26 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 27 Mar 2019 17:02:26 +0000
Subject: RFR: 8221395: HttpClient leaving connections in CLOSE_WAIT state
 until Java process ends
Message-ID: <5940914e-8e77-ba70-e38b-311100d1739c@oracle.com>

Hi,

Please find below a fix for:

8221395: HttpClient leaving connections in CLOSE_WAIT state until
          Java process ends
https://bugs.openjdk.java.net/browse/JDK-8221395

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

HttpConnection has a high level isOpen() accessor that tells
whether the connection is opened.
However, in the case of HTTPS, isOpen() can be false even though
the underlying socket channel hasn't been closed yet.

When checking whether a connection should be returned to the pool,
we want to check whether the connection is still opened before
returning it to the pool.
That code makes the wrong assumption that if isOpen() returns
false the connection doesn't need to be closed.

This proposed change fixes that.

It includes a whitebox test that checks that the
`HttpConnection::closeOrReturnToPool` method will close
the connection in all the cases were the connection is not
returned to the pool. The test fails with the expected exception
without the fix, and passes with it.

-- daniel

From chris.hegarty at oracle.com  Wed Mar 27 17:38:49 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 Mar 2019 17:38:49 +0000
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <CAPW48so4CsL6pYhWufPFyi6nYrCq2et9b_aN7FPGF1YntHyQ1A@mail.gmail.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
 <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
 <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>
 <f2dad669-f896-0ca5-9aa8-aaa4689e8e32@oracle.com>
 <CAPW48so4CsL6pYhWufPFyi6nYrCq2et9b_aN7FPGF1YntHyQ1A@mail.gmail.com>
Message-ID: <0ecc8058-ae77-5bda-8b39-e441903ae9ba@oracle.com>

Arthur,

On 27/03/2019 15:53, Arthur Eubanks wrote:
>    ....
> Done: http://cr.openjdk.java.net/~aeubanks/8220575/webrev.04/
1) The following test fails with this change, when run on an IPv6-only
    environment. The reason is that it contains a certificate that has
    the IPv4 loopback address, 127.0.0.1.

    sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java

    Caused by: java.security.cert.CertificateException: No subject 
alternative names matching IP address 0:0:0:0:0:0:0:1 found
	at 
java.base/sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:164)
	at 
java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:100)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:447)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:422)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233)
	at 
java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
	at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1315)
	... 26 more
	
    Maybe we re-create the certificate with a SAN of ::1 in a follow-on
    issue.

---

2) It is worth nothing that the following tests do not strictly need to
    be updated, as they either; do not make network connections, or test
    part of the implementation prior to the network connection:

    java/net/HttpCookie/ExpiredCookieTest.java
    java/net/ProxySelector/NullSelector.java
    java/net/HttpURLConnection/NoProxyTest.java
    java/net/URLPermission/OpenURL.java

    That said, it is good to clean these up and remove the hardcoded
    IPv4 address.
---

3) The following tests pass on an ipv6-only environment, even without
    the changes. The tests catch and swallow the IOException "Network is
    unreachable", when they should not.

    com/sun/net/httpserver/bugs/B6401598.java
    com/sun/net/httpserver/bugs/B6373555.java

    I can file a separate issue for these, since it is unrelated.

-Chris.

From aeubanks at google.com  Wed Mar 27 17:58:10 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 27 Mar 2019 10:58:10 -0700
Subject: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI
 builder
In-Reply-To: <0ecc8058-ae77-5bda-8b39-e441903ae9ba@oracle.com>
References: <CAPW48sqH94UHzVB+vuTWUddZbJ2zX0hbBB3vgdbyNKnT=Se=kA@mail.gmail.com>
 <c6474f25-0e36-457c-d839-a344195009ec@oracle.com>
 <75946BB4-67EC-421C-B66B-6349084BF3CA@oracle.com>
 <CAPW48srO8iV7OsXjrEyEMApuJoqNwJRdRpPDtYM95Js106b1WA@mail.gmail.com>
 <6f981790-fd4c-02c9-10e2-c7ae7a0b55b3@oracle.com>
 <CAPW48so2kAE+pmjdchApDacJEONCgsd-gvxZ7VphRzCAZpBUnw@mail.gmail.com>
 <CAPW48sp0UqqcTBG_+XCQRNmWuC29fwrU2=m7USxPhFbEJAMSkw@mail.gmail.com>
 <f2dad669-f896-0ca5-9aa8-aaa4689e8e32@oracle.com>
 <CAPW48so4CsL6pYhWufPFyi6nYrCq2et9b_aN7FPGF1YntHyQ1A@mail.gmail.com>
 <0ecc8058-ae77-5bda-8b39-e441903ae9ba@oracle.com>
Message-ID: <CAPW48sq7+FGcpgvD-Ai0xFPOyZRKfpNa4BUc3CiY9DXWovQ66Q@mail.gmail.com>

>
> 1) The following test fails with this change, when run on an IPv6-only
>     environment. The reason is that it contains a certificate that has
>     the IPv4 loopback address, 127.0.0.1.
>
>
> sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
>
>     Caused by: java.security.cert.CertificateException: No subject
> alternative names matching IP address 0:0:0:0:0:0:0:1 found
>         at
>
> java.base/sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:164)
>         at
> java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:100)
>         at
>
> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:447)
>         at
>
> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:422)
>         at
>
> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233)
>         at
>
> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
>         at
>
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1315)
>         ... 26 more
>
>     Maybe we re-create the certificate with a SAN of ::1 in a follow-on
>     issue.
>
Yes, I was planning on addressing this in a future change.

>
> ---
>
> 2) It is worth nothing that the following tests do not strictly need to
>     be updated, as they either; do not make network connections, or test
>     part of the implementation prior to the network connection:
>
>     java/net/HttpCookie/ExpiredCookieTest.java
>     java/net/ProxySelector/NullSelector.java
>     java/net/HttpURLConnection/NoProxyTest.java
>     java/net/URLPermission/OpenURL.java
>
>     That said, it is good to clean these up and remove the hardcoded
>     IPv4 address.
> ---
>
> 3) The following tests pass on an ipv6-only environment, even without
>     the changes. The tests catch and swallow the IOException "Network is
>     unreachable", when they should not.
>
>     com/sun/net/httpserver/bugs/B6401598.java
>     com/sun/net/httpserver/bugs/B6373555.java
>
>     I can file a separate issue for these, since it is unrelated.

Sounds good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190327/1f899ada/attachment.html>

From michael.x.mcmahon at oracle.com  Wed Mar 27 18:00:07 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 27 Mar 2019 18:00:07 +0000
Subject: RFR: 8221395: HttpClient leaving connections in CLOSE_WAIT state
 until Java process ends
In-Reply-To: <5940914e-8e77-ba70-e38b-311100d1739c@oracle.com>
References: <5940914e-8e77-ba70-e38b-311100d1739c@oracle.com>
Message-ID: <5C9BBA27.7050804@oracle.com>

Fix looks good to me Daniel. Good catch.

- Michael.

On 27/03/2019, 17:02, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> 8221395: HttpClient leaving connections in CLOSE_WAIT state until
>          Java process ends
> https://bugs.openjdk.java.net/browse/JDK-8221395
>
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8221395/webrev.00/
>
> HttpConnection has a high level isOpen() accessor that tells
> whether the connection is opened.
> However, in the case of HTTPS, isOpen() can be false even though
> the underlying socket channel hasn't been closed yet.
>
> When checking whether a connection should be returned to the pool,
> we want to check whether the connection is still opened before
> returning it to the pool.
> That code makes the wrong assumption that if isOpen() returns
> false the connection doesn't need to be closed.
>
> This proposed change fixes that.
>
> It includes a whitebox test that checks that the
> `HttpConnection::closeOrReturnToPool` method will close
> the connection in all the cases were the connection is not
> returned to the pool. The test fails with the expected exception
> without the fix, and passes with it.
>
> -- daniel

From chris.hegarty at oracle.com  Wed Mar 27 18:13:22 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 27 Mar 2019 18:13:22 +0000
Subject: RFR: 8221395: HttpClient leaving connections in CLOSE_WAIT state
 until Java process ends
In-Reply-To: <5940914e-8e77-ba70-e38b-311100d1739c@oracle.com>
References: <5940914e-8e77-ba70-e38b-311100d1739c@oracle.com>
Message-ID: <792aa194-d0fa-6880-2586-09ca8536c09a@oracle.com>


On 27/03/2019 17:02, Daniel Fuchs wrote:
> ...
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8221395/webrev.00/

Looks good. Trivially, add the bugId to @bug in the test.

-Chris.

From chris.hegarty at oracle.com  Fri Mar 29 15:10:44 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 29 Mar 2019 15:10:44 +0000
Subject: [ipv6] Regarding 8220673: Add test library support for determining
 platform IP support
Message-ID: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>

Arthur,

Several tests require the presence of either: 1) IPv4, or 2) IPv6, or
3) IPv4&IPv6. A test library utility class could provide such.

Here is a rough idea about how to determine Internet Protocol support.
   http://cr.openjdk.java.net/~chegar/8220673/webrev.00/

It might be enough to experiment with and see how far it gets us?

-Chris.

P.S. Let's use the `[ipv6]` subject prefix to track related work
in this area.

From aeubanks at google.com  Fri Mar 29 19:59:39 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 29 Mar 2019 12:59:39 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
Message-ID: <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>

I had just started on this yesterday.
I'll look at which of the tests we modified in our patches with ipv4/6
detection. I'm worried that some of them may be disabling test coverage
that shouldn't be disabled, but I'll have to look in more detail. Also, we
don't have a JDK at head which works in our environments, so we might miss
some failures until we've decided to have a JDK at head that works in our
environments and run all of the networking tests.

Thanks for the webrev, I'll definitely use that.

On Fri, Mar 29, 2019 at 8:10 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> Several tests require the presence of either: 1) IPv4, or 2) IPv6, or
> 3) IPv4&IPv6. A test library utility class could provide such.
>
> Here is a rough idea about how to determine Internet Protocol support.
>    http://cr.openjdk.java.net/~chegar/8220673/webrev.00/
>
> It might be enough to experiment with and see how far it gets us?
>
> -Chris.
>
> P.S. Let's use the `[ipv6]` subject prefix to track related work
> in this area.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190329/d7c11a6b/attachment.html>

From alexey.menkov at oracle.com  Fri Mar 29 22:07:20 2019
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 29 Mar 2019 15:07:20 -0700
Subject: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <5C9CDDE6.90608@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com>
Message-ID: <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>

(added net-dev as suggested by Alan)

Net gurus, please assist in reviewing socket-related code.

New webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/


On 03/28/2019 07:44, Gary Adams wrote:
> Is there any documentation that needs to be updated along with the impl 
> changes?

created an issue for this:
https://bugs.openjdk.java.net/browse/JDK-8221707

> 
> Would it make sense to support the preference properties?
>  ? java.net.preferIPv4Stack
>  ? java.net.preferIPv6Addresses

Done (with new test for the functionality)

> 
> Will the previous jdwp tests run with IPv6 or just the new additions?

many tests use "localhost" (or empty string which has the same meaning) 
address. localhost can be resolved to IPv4 or IPv6 address, but by 
default IPv4 is used.
So IPv6 will be used only on IPv6-only systems.

> 
> Should probably have reviewers with networking expertise. core-libs(?)
> 
> Do we know if IPv6 is enabled in our test infrastructure?

Accordingly the logs IPv6 stack is enabled, but no external IPv6 address 
is assigned (i.e. the only IPv6 address is loopback - ::1). This is 
enough for testing.

> 
> A stray "printf" statement in the initial webrev. socketTransport.c

fixed.

--alex

> 
> On 3/27/19, 7:04 PM, Alex Menkov wrote:
>> Hi all,
>>
>> Please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8184770
>> webrev:
>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/
>>
>> Main changes are in socketTransport.c - the code is updated to support 
>> both IPv4 and IPv6.
>> Some details to simplify reviewing:
>> - listening:
>> ? - if IP address is specified (like 127.0.0.1 or ::1), connector 
>> listens only on this address;
>> ? - for backward compatibility if no address (or "localhost") is 
>> specified, IPv4 is used (if supported by the host);
>> ? - if "*" is specified (means "listen on all local interfaces"), dual 
>> mode socket is used to listen on both IPv6 and IPv4 addresses;
>> ? - AllowedPeerInfo structure (for "allow" option) is updated to use 
>> IPv6 address/mask, support for IPv4 is implemented by using "mapped" 
>> IPv4 addresses;
>> - attaching: agent resolves and tries to connect to all (IPv4 and 
>> IPv6) addresses, IPv4 are tried first;
>>
>> SocketListeningConnector.java/SocketTransportService.java are updated 
>> to support IPv6 addresses (the addresses may contain colons);
>>
>> new JdwpAttachTest.java/JdwpListenTest.java test that listening and 
>> attaching works for all available addresses (Ipv4 and IPv6)
>>
>> BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it 
>> tests "allow" functionality), tests for mask (prefix length) 
>> functionality are added (for both IPv4 and IPv6);
>>
>> --alex
> 

From aeubanks at google.com  Sat Mar 30 00:03:20 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 29 Mar 2019 17:03:20 -0700
Subject: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
Message-ID: <CAPW48sozzCgr2bU0xtJmWXG5touEH1XkRkqNYMCXbTKPya_tSQ@mail.gmail.com>

We have some ipv6 patches as well in this area as well (as well as other
patches to support ipv6 only environments) that we're trying to upstream. I
don't understand the code myself, but it might be useful to take a look:
http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html

On Fri, Mar 29, 2019 at 3:09 PM Alex Menkov <alexey.menkov at oracle.com>
wrote:

> (added net-dev as suggested by Alan)
>
> Net gurus, please assist in reviewing socket-related code.
>
> New webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/
>
>
> On 03/28/2019 07:44, Gary Adams wrote:
> > Is there any documentation that needs to be updated along with the impl
> > changes?
>
> created an issue for this:
> https://bugs.openjdk.java.net/browse/JDK-8221707
>
> >
> > Would it make sense to support the preference properties?
> >    java.net.preferIPv4Stack
> >    java.net.preferIPv6Addresses
>
> Done (with new test for the functionality)
>
> >
> > Will the previous jdwp tests run with IPv6 or just the new additions?
>
> many tests use "localhost" (or empty string which has the same meaning)
> address. localhost can be resolved to IPv4 or IPv6 address, but by
> default IPv4 is used.
> So IPv6 will be used only on IPv6-only systems.
>
> >
> > Should probably have reviewers with networking expertise. core-libs(?)
> >
> > Do we know if IPv6 is enabled in our test infrastructure?
>
> Accordingly the logs IPv6 stack is enabled, but no external IPv6 address
> is assigned (i.e. the only IPv6 address is loopback - ::1). This is
> enough for testing.
>
> >
> > A stray "printf" statement in the initial webrev. socketTransport.c
>
> fixed.
>
> --alex
>
> >
> > On 3/27/19, 7:04 PM, Alex Menkov wrote:
> >> Hi all,
> >>
> >> Please review the fix for
> >> https://bugs.openjdk.java.net/browse/JDK-8184770
> >> webrev:
> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/
> >>
> >> Main changes are in socketTransport.c - the code is updated to support
> >> both IPv4 and IPv6.
> >> Some details to simplify reviewing:
> >> - listening:
> >>   - if IP address is specified (like 127.0.0.1 or ::1), connector
> >> listens only on this address;
> >>   - for backward compatibility if no address (or "localhost") is
> >> specified, IPv4 is used (if supported by the host);
> >>   - if "*" is specified (means "listen on all local interfaces"), dual
> >> mode socket is used to listen on both IPv6 and IPv4 addresses;
> >>   - AllowedPeerInfo structure (for "allow" option) is updated to use
> >> IPv6 address/mask, support for IPv4 is implemented by using "mapped"
> >> IPv4 addresses;
> >> - attaching: agent resolves and tries to connect to all (IPv4 and
> >> IPv6) addresses, IPv4 are tried first;
> >>
> >> SocketListeningConnector.java/SocketTransportService.java are updated
> >> to support IPv6 addresses (the addresses may contain colons);
> >>
> >> new JdwpAttachTest.java/JdwpListenTest.java test that listening and
> >> attaching works for all available addresses (Ipv4 and IPv6)
> >>
> >> BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it
> >> tests "allow" functionality), tests for mask (prefix length)
> >> functionality are added (for both IPv4 and IPv6);
> >>
> >> --alex
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190329/65448c9b/attachment.html>

From aeubanks at google.com  Sat Mar 30 00:06:43 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 29 Mar 2019 17:06:43 -0700
Subject: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <CAPW48sozzCgr2bU0xtJmWXG5touEH1XkRkqNYMCXbTKPya_tSQ@mail.gmail.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <CAPW48sozzCgr2bU0xtJmWXG5touEH1XkRkqNYMCXbTKPya_tSQ@mail.gmail.com>
Message-ID: <CAPW48sqbpVy9V_2krrgt12cdO2f-O-xxC3jXHhpe+9c-xZLs+w@mail.gmail.com>

(one more time now that I'm subscribed to serviceability-dev)

On Fri, Mar 29, 2019 at 5:03 PM Arthur Eubanks <aeubanks at google.com> wrote:

> We have some ipv6 patches as well in this area as well (as well as other
> patches to support ipv6 only environments) that we're trying to upstream. I
> don't understand the code myself, but it might be useful to take a look:
> http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html
>
> On Fri, Mar 29, 2019 at 3:09 PM Alex Menkov <alexey.menkov at oracle.com>
> wrote:
>
>> (added net-dev as suggested by Alan)
>>
>> Net gurus, please assist in reviewing socket-related code.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/
>>
>>
>> On 03/28/2019 07:44, Gary Adams wrote:
>> > Is there any documentation that needs to be updated along with the impl
>> > changes?
>>
>> created an issue for this:
>> https://bugs.openjdk.java.net/browse/JDK-8221707
>>
>> >
>> > Would it make sense to support the preference properties?
>> >    java.net.preferIPv4Stack
>> >    java.net.preferIPv6Addresses
>>
>> Done (with new test for the functionality)
>>
>> >
>> > Will the previous jdwp tests run with IPv6 or just the new additions?
>>
>> many tests use "localhost" (or empty string which has the same meaning)
>> address. localhost can be resolved to IPv4 or IPv6 address, but by
>> default IPv4 is used.
>> So IPv6 will be used only on IPv6-only systems.
>>
>> >
>> > Should probably have reviewers with networking expertise. core-libs(?)
>> >
>> > Do we know if IPv6 is enabled in our test infrastructure?
>>
>> Accordingly the logs IPv6 stack is enabled, but no external IPv6 address
>> is assigned (i.e. the only IPv6 address is loopback - ::1). This is
>> enough for testing.
>>
>> >
>> > A stray "printf" statement in the initial webrev. socketTransport.c
>>
>> fixed.
>>
>> --alex
>>
>> >
>> > On 3/27/19, 7:04 PM, Alex Menkov wrote:
>> >> Hi all,
>> >>
>> >> Please review the fix for
>> >> https://bugs.openjdk.java.net/browse/JDK-8184770
>> >> webrev:
>> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/
>> >>
>> >> Main changes are in socketTransport.c - the code is updated to support
>> >> both IPv4 and IPv6.
>> >> Some details to simplify reviewing:
>> >> - listening:
>> >>   - if IP address is specified (like 127.0.0.1 or ::1), connector
>> >> listens only on this address;
>> >>   - for backward compatibility if no address (or "localhost") is
>> >> specified, IPv4 is used (if supported by the host);
>> >>   - if "*" is specified (means "listen on all local interfaces"), dual
>> >> mode socket is used to listen on both IPv6 and IPv4 addresses;
>> >>   - AllowedPeerInfo structure (for "allow" option) is updated to use
>> >> IPv6 address/mask, support for IPv4 is implemented by using "mapped"
>> >> IPv4 addresses;
>> >> - attaching: agent resolves and tries to connect to all (IPv4 and
>> >> IPv6) addresses, IPv4 are tried first;
>> >>
>> >> SocketListeningConnector.java/SocketTransportService.java are updated
>> >> to support IPv6 addresses (the addresses may contain colons);
>> >>
>> >> new JdwpAttachTest.java/JdwpListenTest.java test that listening and
>> >> attaching works for all available addresses (Ipv4 and IPv6)
>> >>
>> >> BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it
>> >> tests "allow" functionality), tests for mask (prefix length)
>> >> functionality are added (for both IPv4 and IPv6);
>> >>
>> >> --alex
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190329/d911f088/attachment-0001.html>