From daniel.fuchs at oracle.com  Wed May  1 10:59:40 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 1 May 2019 11:59:40 +0100
Subject: RFR: 8223145: [teststabilization] Replace wildcard address with
 loopback or local host in test - part 1
In-Reply-To: <DB6P192MB0200F0802903739CDD1F33C5DF3A0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <19405da6-e153-ce73-76e8-82742a296654@oracle.com>
 <DB6P192MB0200F0802903739CDD1F33C5DF3A0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <194fab36-c388-4793-7d7e-133a2a7b71e4@oracle.com>

Hi Mark,

Welcome back to this  list :-)

On 30/04/2019 23:58, mark sheppard wrote:
> <LE NOISE> ?
> Hi Daniel,?
> ?
> interesting set of changes -?
> But could it be the case that, for some tests, you might change the 
> operational semantics of a test, when?
> this applying this change.

I did try to avoid that. Of course I am aware that binding
to the loopback vs binding to wildcard vs binding to the
external host IP means that different code paths will
be involved. In some cases I even went and checked the
history of the test to verify that the use of the wildcard
wasn't made on purpose. I didn't do it for all the tests,
but GetLocalAddress is one I checked - for I had similar
concerns.

> For example, in the case of GetLocalAddress.?
> The original is to use a wild card for the server, and a directed 
> address for the ?
> client connect. Thus the server is listening INADDR_ANY or the IPv6 
> equivalent, accepts?
> a connection, then a check is made to see that socket created is bound 
> to the same address?
> as that specified in the clients connect request.?
> ?
> If the server socket is ?bound to a specific address then the socket 
> created by the accept?
> will (always)? have the same address as that of initial server socket 
> (listener).?

OK. But the first bug tested here was that the returned address
had its byte[] in the right byte order - as it seemed there was
a bug on some platform where the local address returned by
the accepted socket had its bytes in the reversed order.
The second bug tested is that getLocalHost() doesn't crash when
java.net.preferIPv4Stack=true, and the third, is about
testBindNull() which has remained unchanged.

> As the tests are run with 3 different java.net property settings, it is 
> worth asking if the tests behaves as expected?
> for the case when neither java.net property is set.

Well, I haven't seen the test failing since I fixed it - which
is a good sign - so all three @run are passing, including the
one where no property is set, on all platforms that we test.
?
> AFAIK, on windows it shows some ambiguity and difference to the default 
> setting described in?
> [1]. The default run returns IPV4 addresses, creates AF_INTET sockets 
> and binds to IPv4 addresses.?
> This is possibly at odds with the default property settings are 
> described in the docs.?

hmmm... OK.

> java.net.preferIPv4Stack (default: false)?
> If IPv6 is available on the operating system the underlying native 
> socket will be, by default,?
> an IPv6 socket which lets applications connect to, and accept 
> connections from, both IPv4 and IPv6 hosts. ?
> This implies that the first test run, i.e. default property settings, 
> should be an AF_INET6 socket as in new ServerSocket?
> should be bound to the IPv6 unspecified address.?

Yes.

> While?
> java.net.preferIPv6Addresses (default: false)?
> When dealing with a host which has both IPv4 and IPv6 addresses, ?
> and if IPv6 is available on the operating system, the default ?
> behavior is to prefer using IPv4 addresses over IPv6 ones.?

Yes.
  ?
> This implies that the InetAddress.getLocalHost() should in the default case?
> return an IPv4 address.?

Yes. When java.net.preferIPv6Addresses is not set or not true.
  ?
> The client socket connect with IPv4 address to IPv6 wild card resulting 
> in an IPv4 mapped?
> binding in the socket created in the accept. This would mean the first 
> run should fail.?

It didn't fail either before or after my fix though. I mean - it did
fail before my fix but only intermittently and in timeout.

> In any case a test using a server socket listening on a wildcard 
> (INADDR_ANY) address has possibly?
> slightly different semantics than a server socket listening on a 
> specific host address.?

Agreed. And there must be tests that bind to the wildcard address,
if only to verify that binding to the wildcard works. But given
that binding to the wildcard is a proven source of instability, then
I believe that tests that do not explicitly need to bind to the
wildcard should not.

If we have only a limited amount of tests, clearly identified,
that need to use the wildcard address and do - and fail
intermittently - then that's no perfect but it can be
acceptable.
If the majority of the tests are susceptible to fail
randomly and intermittently then that's not acceptable.
Especially if we need to make sure that new changes to the code
base are not introducing any subtle race conditions.

In the case of GetLocalAddress then I'm confident that the
original test could have been written as it is after my
changes: prompted by your question I managed to track down
the SCCS history and see the ntohl() call that was added
to PlainSocketImpl.c.

best regards,

-- daniel


> ?
> regards
> Mark
> ?
> </LE NOISE>?
> ?
> [1] 
> https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html
> 
> 
> ------------------------------------------------------------------------
> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of Daniel 
> Fuchs <daniel.fuchs at oracle.com>
> *Sent:* Tuesday 30 April 2019 11:16
> *To:* OpenJDK Network Dev list
> *Subject:* RFR: 8223145: [teststabilization] Replace wildcard address 
> with loopback or local host in test - part 1
> Hi,
> 
> Please find below a patch for:
> 
> 8223145: [teststabilization] Replace wildcard address with loopback
>  ????????? or local host in test - part 1
> https://bugs.openjdk.java.net/browse/JDK-8223145
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8223145/webrev.00/
> 
> This is the first in a series of patches that will try to
> address intermittent failures which are sometime observed
> when tests use the wildcard address to bind their test servers.
> 
> These changes are IpV6-only friendly.
> 
> best regards,
> 
> -- daniel


From Alan.Bateman at oracle.com  Wed May  1 13:10:13 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 14:10:13 +0100
Subject: 8218559: Reimplement the Legacy Socket API
Message-ID: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>


JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
finalized and the changes reviewed so that it can be targeted.

The webrev with the changes is here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html

The new implementation is one source file; the only other code change is 
to SocketImpl.createPlatformSocketImpl to select the implementation 
based on the system property jdk.net.usePlainSocketImpl. The reason the 
patch isn't too big is that all the "enabling changes" are already in 
jdk/jdk.

We added additional tests a few weeks ago via JDK-8221259 [3] to test 
long standing behavior. The webrev adds a few additional tests, the main 
new one is to test that the SocketImpl is reliable in the fact of usages 
that are not specified by SocketImpl. A selection of existing tests are 
also updated to run with both the old and new implementation - the 
motive of this is to ensure that the old implementation doesn't bit rot 
before it is removed.

Once the changes are in a promoted build then we'll need help testing. 
The best outcome is that nobody notices :-)? Rory O'Donnell, with his 
OpenJDK quality outreach hat on, has agreed to contact the projects 
tracked by that program to test the EA builds when they are available.

-Alan

[1] https://openjdk.java.net/jeps/353
[2] https://bugs.openjdk.java.net/browse/JDK-8222028
[3] https://bugs.openjdk.java.net/browse/JDK-8221259

From chris.hegarty at oracle.com  Wed May  1 16:56:19 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 May 2019 17:56:19 +0100
Subject: RFR: 8223145: [teststabilization] Replace wildcard address with
 loopback or local host in test - part 1
In-Reply-To: <19405da6-e153-ce73-76e8-82742a296654@oracle.com>
References: <19405da6-e153-ce73-76e8-82742a296654@oracle.com>
Message-ID: <6E4D2D9F-93B4-4BF7-A51D-60D05A467EA3@oracle.com>

Daniel,

> On 30 Apr 2019, at 12:16, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch for:
> 
> 8223145: [teststabilization] Replace wildcard address with loopback
>         or local host in test - part 1
> https://bugs.openjdk.java.net/browse/JDK-8223145
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8223145/webrev.00/ <http://cr.openjdk.java.net/~dfuchs/webrev_8223145/webrev.00/>

I think this looks good ( the tests here don?t seem to really care
whether the server socket is bound to the wildcard address or
not, just that the client and server sides can be connected, in
order to test some higher-level protocol abstraction ).

-Chris.

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

From aeubanks at google.com  Wed May  1 22:21:28 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 1 May 2019 15:21:28 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
Message-ID: <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>

Sorry for the delay, but here's the next revision:
http://cr.openjdk.java.net/~aeubanks/8220673/webrev.01

The list of tests modified was found by searching for "preferIPv4Stack" in
the tests. The only one I didn't touch was test/jdk/sun/net/sdp/sanity.sh,
which is a shell test, and is Solaris-only.
For most tests, all I did was add
IPSupport.skipIfCurrentConfigurationIsInvalid(). Some of them also had
custom implementations for detecting if IPv6 was available, so I replaced
those with the new IPSupport version.
Also added a missing "@test" to test/jdk/java/net/Socket/RST.java.

Again, I made sure that the only time the test is skipped
with IPSupport.skipIfCurrentConfigurationIsInvalid() is when IPv4 is not
available (with LD_PRELOAD) and when java.net.preferIPv4Stack is true.

There are still tests that fail/timeout under the LD_PRELOAD that
intercepts and rejects IPv4 calls to getifaddrs(), setsockopt(), and
socket(), but those will be fixed in the future, likely with changes to the
JDK itself.

On Tue, Apr 16, 2019 at 2:14 PM Arthur Eubanks <aeubanks at google.com> wrote:

> > Regarding trusting the IPSupport, I have checked to make sure that it's
>> reasonable. It correctly throws a jtreg.SkippedException when
>> preferIPv4Stack is true and IPv4 is not available, and leaves the other
>> cases alone. This was tested with an LD_PRELOAD that returns an error on
>> `socket()`, `setsockopt()`, and `getifaddrs()` on IPv4 addresses. Under a
>> typical dual stack configuration it doesn't throw anything. This was a good
>> idea, thanks Daniel.
>>
>> Indeed. And thanks for verify its behaviour.
>>
> I lied, it worked on our JDK which has some IPv6 patches, not the upstream
> JDK. I think to properly test this, first I need to upstream a tiny portion
> of the patches we have to the JDK. I'll file a bug and send out a patch.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190501/8fd17505/attachment.html>

From aeubanks at google.com  Wed May  1 22:53:13 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 1 May 2019 15:53:13 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should choose
 loopback address that is available
Message-ID: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>

Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223214

Bug description:
Currently, Inet6AddressImpl.loopbackAddress() will unconditionally choose
the IPv6 loopback address if java.net.preferIPv6Address is set to "system"
or "true", else unconditionally choose the IPv4 loopback address.

Instead it should try out both loopback addresses and return whichever one
works, giving preference to IPv6 if java.net.preferIPv6Address is set to
"system" or "true", else giving preference to IPv4. This way there is no
need to set java.net.preferIPv6Address in an IPv6-only environment to get a
valid loopback address.


Does this need tests? Or is it good enough to assume that existing tests
will cover this, they just need to be run in an IPv6-only environment?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190501/0194f034/attachment.html>

From aeubanks at google.com  Wed May  1 23:00:37 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 1 May 2019 16:00:37 -0700
Subject: RFR: 8223145: [teststabilization] Replace wildcard address with
 loopback or local host in test - part 1
In-Reply-To: <6E4D2D9F-93B4-4BF7-A51D-60D05A467EA3@oracle.com>
References: <19405da6-e153-ce73-76e8-82742a296654@oracle.com>
 <6E4D2D9F-93B4-4BF7-A51D-60D05A467EA3@oracle.com>
Message-ID: <CAPW48spYnFJD7D6u9iXxy7TdUx4hoBnHL0Ju66H66MUrMKtquw@mail.gmail.com>

Thanks for keeping IPv6-only in mind, glad to see URIBuilder is getting
some use!

On Wed, May 1, 2019 at 9:56 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Daniel,
>
> On 30 Apr 2019, at 12:16, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
> Hi,
>
> Please find below a patch for:
>
> 8223145: [teststabilization] Replace wildcard address with loopback
>         or local host in test - part 1
> https://bugs.openjdk.java.net/browse/JDK-8223145
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8223145/webrev.00/
>
>
> I think this looks good ( the tests here don?t seem to really care
> whether the server socket is bound to the wildcard address or
> not, just that the client and server sides can be connected, in
> order to test some higher-level protocol abstraction ).
>
> -Chris.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190501/0de7be92/attachment-0001.html>

From Alan.Bateman at oracle.com  Thu May  2 06:43:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 07:43:02 +0100
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
Message-ID: <fc40c777-c72c-d582-081d-e9e35779f3ca@oracle.com>

On 01/05/2019 23:53, Arthur Eubanks wrote:
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
>
NetworkInterface.getByInetAddress denies knowledge of addresses that you 
don't have a permission to connect to so I think this will need a 
privileged block for cases where you run with a security manager. That 
scenario may need a new test too, if only to make sure that early use 
will untrusted code on the stack will pick up the right loopback.

-Alan

From nautsch2 at gmail.com  Thu May  2 07:44:43 2019
From: nautsch2 at gmail.com (Andre Naujoks)
Date: Thu, 2 May 2019 09:44:43 +0200
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
Message-ID: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>

Hello all.

I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
12. With a new bug JDK-8215294 taking over the issue.

Just to let you know, the issue is not linux specific (as the new bug
states). A test on a windows machine resulted in the same behavior.

  Andre

### win10, openjdk12

Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App printProperties
INFO: awt.toolkit: sun.awt.windows.WToolkit
file.encoding: Cp1252
file.separator: \
java.awt.graphicsenv: sun.awt.Win32GraphicsEnvironment
java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar
java.class.version: 56.0
java.home: C:\Program Files\Java\jdk-12.0.1
java.io.tmpdir: C:\Users\WUENSC~1\AppData\Local\Temp\
java.library.path: C:\Program
Files\Java\jdk-12.0.1\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Users\wuenschmann\bin;C:\Program
Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program
Files\Git\usr\bin;C:\Program Files\Git\usr\bin;C:\Program
Files\Git\mingw64\bin;C:\Program
Files\Git\usr\bin;U:\bin;C:\Users\wuenschmann\coding\cygwin\bin;C:\Users\wuenschmann\coding\apache-maven-3.6.1;C:\Users\wuenschmann\coding\apache-maven-3.6.1\bin;C:\Program
Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\iCLS;C:\Program
Files\Intel\Intel(R) Management Engine
Components\iCLS;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program
Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files
(x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL
Server\110\Tools\Binn;C:\Program Files\Git\cmd;C:\Program
Files\PuTTY;C:\Program
Files\Java\jdk-12.0.1;C:\Users\wuenschmann\AppData\Local\Microsoft\WindowsApps;C:\Users\wuenschmann\AppData\Local\atom\bin;C:\Program
Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl;.
java.runtime.name: OpenJDK Runtime Environment
java.runtime.version: 12.0.1+12
java.specification.name: Java Platform API Specification
java.specification.vendor: Oracle Corporation
java.specification.version: 12
java.vendor: Oracle Corporation
java.vendor.url: https://java.oracle.com/
java.vendor.url.bug: https://bugreport.java.com/bugreport/
java.version: 12.0.1
java.version.date: 2019-04-16
java.vm.compressedOopsMode: Zero based
java.vm.info: mixed mode, sharing
java.vm.name: OpenJDK 64-Bit Server VM
java.vm.specification.name: Java Virtual Machine Specification
java.vm.specification.vendor: Oracle Corporation
java.vm.specification.version: 12
java.vm.vendor: Oracle Corporation
java.vm.version: 12.0.1+12
jdk.debug: release
line.separator:

os.arch: amd64
os.name: Windows 10
os.version: 10.0
path.separator: ;
sun.arch.data.model: 64
sun.boot.library.path: C:\Program Files\Java\jdk-12.0.1\bin
sun.cpu.endian: little
sun.cpu.isalist: amd64
sun.desktop: windows
sun.io.unicode.encoding: UnicodeLittle
sun.java.command: TestIPv6-1.0.0-SNAPSHOT.jar
sun.java.launcher: SUN_STANDARD
sun.jnu.encoding: Cp1252
sun.management.compiler: HotSpot 64-Bit Tiered Compilers
sun.os.patch.level:
user.country: DE
user.dir: C:\Users\wuenschmann\EclipseProject\TestIPv6\target
user.home: C:\Users\wuenschmann
user.language: de
user.name: wuenschmann
user.script:
user.variant:

Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
INFO: Got network interface: eth0 - 2
Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
INFO: ScopeID: 2
Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
INFO: Bind to: /ff12:0:0:0:0:0:4749:4750%eth0:29550
Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
SEVERE: null
java.net.BindException: Cannot assign requested address: bind
 at java.base/sun.nio.ch.Net.bind0(Native Method)
 at java.base/sun.nio.ch.Net.bind(Net.java:455)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
 at de.nordsys.test.testipv6.App.main(App.java:152)

Exception in thread "main" java.lang.Error: java.net.BindException:
Cannot assign requested address: bind
 at de.nordsys.test.testipv6.App.main(App.java:160)
Caused by: java.net.BindException: Cannot assign requested address: bind
 at java.base/sun.nio.ch.Net.bind0(Native Method)
 at java.base/sun.nio.ch.Net.bind(Net.java:455)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
 at de.nordsys.test.testipv6.App.main(App.java:152)




### ubuntu-18.04, openjdk12:

Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App printProperties
INFO: awt.toolkit: sun.awt.X11.XToolkit
file.encoding: UTF-8
file.separator: /
java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment
java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar
java.class.version: 56.0
java.home: /usr/lib/jvm/jdk-12.0.1
java.io.tmpdir: /tmp
java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
java.runtime.name: OpenJDK Runtime Environment
java.runtime.version: 12.0.1+12
java.specification.name: Java Platform API Specification
java.specification.vendor: Oracle Corporation
java.specification.version: 12
java.vendor: Oracle Corporation
java.vendor.url: https://java.oracle.com/
java.vendor.url.bug: https://bugreport.java.com/bugreport/
java.version: 12.0.1
java.version.date: 2019-04-16
java.vm.compressedOopsMode: 32-bit
java.vm.info: mixed mode, sharing
java.vm.name: OpenJDK 64-Bit Server VM
java.vm.specification.name: Java Virtual Machine Specification
java.vm.specification.vendor: Oracle Corporation
java.vm.specification.version: 12
java.vm.vendor: Oracle Corporation
java.vm.version: 12.0.1+12
jdk.debug: release
line.separator:
os.arch: amd64
os.name: Linux
os.version: 4.15.0-20-generic
path.separator: :
sun.arch.data.model: 64
sun.boot.library.path: /usr/lib/jvm/jdk-12.0.1/lib
sun.cpu.endian: little
sun.desktop: gnome
sun.io.unicode.encoding: UnicodeLittle
sun.java.command: TestIPv6-1.0.0-SNAPSHOT.jar
sun.java.launcher: SUN_STANDARD
sun.jnu.encoding: UTF-8
sun.management.compiler: HotSpot 64-Bit Tiered Compilers
user.country: DE
user.dir: /home/nico/EclipseProject/TestIPv6/target
user.home: /home/nico
user.language: de
user.name: nico
Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
INFO: Got network interface: enp0s3 - 2
Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
INFO: ScopeID: 2
Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
INFO: Bind to: /ff12:0:0:0:0:0:4749:4750%enp0s3:29550
Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
SEVERE: null
java.net.SocketException: Das Argument ist ung?ltig
 at java.base/sun.nio.ch.Net.bind0(Native Method)
 at java.base/sun.nio.ch.Net.bind(Net.java:455)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
 at de.nordsys.test.testipv6.App.main(App.java:152)
Exception in thread "main" java.lang.Error: java.net.SocketException:
Das Argument ist ung?ltig
 at de.nordsys.test.testipv6.App.main(App.java:160)
Caused by: java.net.SocketException: Das Argument ist ung?ltig
 at java.base/sun.nio.ch.Net.bind0(Native Method)
 at java.base/sun.nio.ch.Net.bind(Net.java:455)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
 at
java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
 at de.nordsys.test.testipv6.App.main(App.java:152)

From Alan.Bateman at oracle.com  Thu May  2 08:25:32 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 09:25:32 +0100
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
In-Reply-To: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
References: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
Message-ID: <d59a04fa-a5b6-a70d-7864-613634a484f4@oracle.com>

On 02/05/2019 08:44, Andre Naujoks wrote:
> Hello all.
>
> I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
> 12. With a new bug JDK-8215294 taking over the issue.
Yes, it caused problems so had to be reverted. In addition to 
JDK-8215294 there is also JDK-8216417 which we expect to set the scopeID 
when binding a TCP socket to an IPv6 link-local address.

>
> Just to let you know, the issue is not linux specific (as the new bug
> states). A test on a windows machine resulted in the same behavior.
The portability recommendation in the javadoc is to bind to the wildcard 
address. Yes, you might have issues on several platforms when trying to 
bind to an IPv6 multicast address when the scopeID is not set.
(If I recall correctly, the original issue that Hendrik brought up here 
was binding to the multicast address to avoid interference on Linux. We 
thought we had that addressed with IP_MULTICAST_ALL but it turns not to 
be effective with IPv6 sockets. I believe there is a patch for that or a 
proposal to introduce an equivalent IPV6_MULTICAST_ALL).

-Alan.

From daniel.fuchs at oracle.com  Thu May  2 09:28:30 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 May 2019 10:28:30 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
Message-ID: <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>

Hi Arthur,

On the surface, this looks good.
However I have a concern about two things:

1. IPSupport needs to read system properties, attempts
    to bind sockets etc... I wonder how that might interact
    with tests that use a security manager, as some of these
    operations may throw a SecurityException.
    Maybe some double checking would be in order for those.

2. I would also be more comfortable if
    skipIfCurrentConfigurationIsInvalid() (and possibly
    the static initializer too?), could throw an
    AssertionError if it finds that neither IPv4 nor IPv6
    are available on a system. I'm concerned that a bug
    that e.g. prevents to bind any socket would go unnoticed
    if all tests are skipped...

best regards,

-- daniel

PS: Just a heads up that I have a pending fix [1] which I'm intending
to push later today and which also touches some of the tests from
your patch. Hopefully any merge should be trivial.
[1] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012416.html

On 01/05/2019 23:21, Arthur Eubanks wrote:
> Sorry for the delay, but here's the next revision:
> http://cr.openjdk.java.net/~aeubanks/8220673/webrev.01
> 
> The list of tests modified was found by searching for "preferIPv4Stack" 
> in the tests. The only one I didn't touch was 
> test/jdk/sun/net/sdp/sanity.sh, which is a shell test, and is Solaris-only.
> For most tests, all I did was add 
> IPSupport.skipIfCurrentConfigurationIsInvalid(). Some of them also had 
> custom implementations for detecting if IPv6 was available, so I 
> replaced those with the new IPSupport version.
> Also added a missing "@test" to test/jdk/java/net/Socket/RST.java.
> 
> Again, I made sure that the only time the test is skipped 
> with?IPSupport.skipIfCurrentConfigurationIsInvalid() is when IPv4 is not 
> available (with LD_PRELOAD) and when java.net.preferIPv4Stack is true.
> 
> There are still tests that fail/timeout under the LD_PRELOAD that 
> intercepts and rejects IPv4 calls to getifaddrs(), setsockopt(), and 
> socket(), but those will be fixed in the future, likely with changes to 
> the JDK itself.

From nautsch2 at gmail.com  Thu May  2 09:33:31 2019
From: nautsch2 at gmail.com (Andre Naujoks)
Date: Thu, 2 May 2019 11:33:31 +0200
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
In-Reply-To: <d59a04fa-a5b6-a70d-7864-613634a484f4@oracle.com>
References: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
 <d59a04fa-a5b6-a70d-7864-613634a484f4@oracle.com>
Message-ID: <88ef6f36-01f4-5ee6-a0d8-982f45e783e5@gmail.com>

Am 02.05.19 um 10:25 schrieb Alan Bateman:
> On 02/05/2019 08:44, Andre Naujoks wrote:
>> Hello all.
>>
>> I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
>> 12. With a new bug JDK-8215294 taking over the issue.
> Yes, it caused problems so had to be reverted. In addition to
> JDK-8215294 there is also JDK-8216417 which we expect to set the scopeID
> when binding a TCP socket to an IPv6 link-local address.
> 
>>
>> Just to let you know, the issue is not linux specific (as the new bug
>> states). A test on a windows machine resulted in the same behavior.
> The portability recommendation in the javadoc is to bind to the wildcard
> address. Yes, you might have issues on several platforms when trying to
> bind to an IPv6 multicast address when the scopeID is not set.
> (If I recall correctly, the original issue that Hendrik brought up here
> was binding to the multicast address to avoid interference on Linux. We
> thought we had that addressed with IP_MULTICAST_ALL but it turns not to
> be effective with IPv6 sockets. I believe there is a patch for that or a
> proposal to introduce an equivalent IPV6_MULTICAST_ALL).

Yes, I wrote that patch. It is part of Linux 4.20 [1]. It should be a
viable workaround for Java on Linux from that version onward. It just
takes a while until the fix arrives in distributions (I am on Debian
unstable and not yet on a fixed kernel-version.).

I just wanted to notify you, that the whole issue with binding to a
multicast address is not Linux specific.

We are currently trying to reproduce the original issue with the
reception of all multicast traffic on windows and will get back to you
about that.

Andre

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15033f0457dca569b284bef0c8d3ad55fb37eacb

> 
> -Alan.


From sean.coffey at oracle.com  Thu May  2 10:00:59 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 2 May 2019 11:00:59 +0100
Subject: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol
 can override default handler
In-Reply-To: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
References: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
Message-ID: <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>

Been thinking a bit more about this one.

Given that only initialization code will traverse through the "if 
(!isOverrideable(protocol))" check, I think we can add synchronization 
to eliminate any timing scenarios where the handlers Hashtable gets 
populated via another thread after we make the first handers.get call in 
getURLStreamHandler(String protocol)

http://gbr10227.uk.oracle.com/html/ws/jdk-jdk/open/webrev.8217364.02/webrev/

regards,
Sean.

On 30/04/2019 18:19, Se?n Coffey wrote:
> Looking to correct an issue that arose during the JDK-8213942 fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8217364
> https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
>
> regards,
> Sean.
>

From sean.coffey at oracle.com  Thu May  2 10:33:55 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 2 May 2019 11:33:55 +0100
Subject: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol
 can override default handler
In-Reply-To: <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>
References: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
 <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>
Message-ID: <f416cb7e-328d-e532-0954-6e6f3923dfec@oracle.com>

with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/

regards,
Sean.

On 02/05/2019 11:00, Se?n Coffey wrote:
> Been thinking a bit more about this one.
>
> Given that only initialization code will traverse through the "if 
> (!isOverrideable(protocol))" check, I think we can add synchronization 
> to eliminate any timing scenarios where the handlers Hashtable gets 
> populated via another thread after we make the first handers.get call 
> in getURLStreamHandler(String protocol)
>
> regards,
> Sean.
>
> On 30/04/2019 18:19, Se?n Coffey wrote:
>> Looking to correct an issue that arose during the JDK-8213942 fix.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8217364
>> https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
>>
>> regards,
>> Sean.
>>

From claes.redestad at oracle.com  Thu May  2 12:15:27 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 2 May 2019 14:15:27 +0200
Subject: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol
 can override default handler
In-Reply-To: <f416cb7e-328d-e532-0954-6e6f3923dfec@oracle.com>
References: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
 <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>
 <f416cb7e-328d-e532-0954-6e6f3923dfec@oracle.com>
Message-ID: <c277058f-ae05-c257-4b59-ef2bc79347ef@oracle.com>

Hi Se?n,

wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both cases if the protocol is
non-overrideable?

I.e., something like this:

diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
--- a/src/java.base/share/classes/java/net/URL.java	Tue Apr 30 23:47:00 
2019 +0200
+++ b/src/java.base/share/classes/java/net/URL.java	Thu May 02 14:10:57 
2019 +0200
@@ -1403,8 +1403,9 @@

          URLStreamHandlerFactory fac;
          boolean checkedWithFactory = false;
+        boolean overrideableProtocol = isOverrideable(protocol);

-        if (isOverrideable(protocol) && jdk.internal.misc.VM.isBooted()) {
+        if (overrideableProtocol && jdk.internal.misc.VM.isBooted()) {
              // Use the factory (if any). Volatile read makes
              // URLStreamHandlerFactory appear fully initialized to 
current thread.
              fac = factory;
@@ -1440,7 +1441,7 @@

              // Check with factory if another thread set a
              // factory since our last check
-            if (!checkedWithFactory && (fac = factory) != null) {
+            if (overrideableProtocol && !checkedWithFactory && (fac = 
factory) != null) {
                  handler2 = fac.createURLStreamHandler(protocol);
              }

Thanks!

/Claes

On 2019-05-02 12:33, Se?n Coffey wrote:
> with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
> 
> regards,
> Sean.
> 
> On 02/05/2019 11:00, Se?n Coffey wrote:
>> Been thinking a bit more about this one.
>>
>> Given that only initialization code will traverse through the "if 
>> (!isOverrideable(protocol))" check, I think we can add synchronization 
>> to eliminate any timing scenarios where the handlers Hashtable gets 
>> populated via another thread after we make the first handers.get call 
>> in getURLStreamHandler(String protocol)
>>
>> regards,
>> Sean.
>>
>> On 30/04/2019 18:19, Se?n Coffey wrote:
>>> Looking to correct an issue that arose during the JDK-8213942 fix.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8217364
>>> https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
>>>
>>> regards,
>>> Sean.
>>>

From sean.coffey at oracle.com  Thu May  2 13:20:44 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 2 May 2019 14:20:44 +0100
Subject: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol
 can override default handler
In-Reply-To: <c277058f-ae05-c257-4b59-ef2bc79347ef@oracle.com>
References: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
 <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>
 <f416cb7e-328d-e532-0954-6e6f3923dfec@oracle.com>
 <c277058f-ae05-c257-4b59-ef2bc79347ef@oracle.com>
Message-ID: <bd2e631d-b105-e6ae-0160-1e93807f5f5e@oracle.com>

Hi Claes,

Yes - looks like a fine suggestion.
http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/

regards,
Sean.

On 02/05/2019 13:15, Claes Redestad wrote:
> Hi Se?n,
>
> wouldn't it be more straightforward then to keep the logic intact and
> skip the custom factory invocation in both cases if the protocol is
> non-overrideable?
>
> I.e., something like this:
>
> diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
> --- a/src/java.base/share/classes/java/net/URL.java??? Tue Apr 30 
> 23:47:00 2019 +0200
> +++ b/src/java.base/share/classes/java/net/URL.java??? Thu May 02 
> 14:10:57 2019 +0200
> @@ -1403,8 +1403,9 @@
>
> ???????? URLStreamHandlerFactory fac;
> ???????? boolean checkedWithFactory = false;
> +??????? boolean overrideableProtocol = isOverrideable(protocol);
>
> -??????? if (isOverrideable(protocol) && 
> jdk.internal.misc.VM.isBooted()) {
> +??????? if (overrideableProtocol && jdk.internal.misc.VM.isBooted()) {
> ???????????? // Use the factory (if any). Volatile read makes
> ???????????? // URLStreamHandlerFactory appear fully initialized to 
> current thread.
> ???????????? fac = factory;
> @@ -1440,7 +1441,7 @@
>
> ???????????? // Check with factory if another thread set a
> ???????????? // factory since our last check
> -??????????? if (!checkedWithFactory && (fac = factory) != null) {
> +??????????? if (overrideableProtocol && !checkedWithFactory && (fac = 
> factory) != null) {
> ???????????????? handler2 = fac.createURLStreamHandler(protocol);
> ???????????? }
>
> Thanks!
>
> /Claes
>
> On 2019-05-02 12:33, Se?n Coffey wrote:
>> with webrev: 
>> https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
>>
>> regards,
>> Sean.
>>
>> On 02/05/2019 11:00, Se?n Coffey wrote:
>>> Been thinking a bit more about this one.
>>>
>>> Given that only initialization code will traverse through the "if 
>>> (!isOverrideable(protocol))" check, I think we can add 
>>> synchronization to eliminate any timing scenarios where the handlers 
>>> Hashtable gets populated via another thread after we make the first 
>>> handers.get call in getURLStreamHandler(String protocol)
>>>
>>> regards,
>>> Sean.
>>>
>>> On 30/04/2019 18:19, Se?n Coffey wrote:
>>>> Looking to correct an issue that arose during the JDK-8213942 fix.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8217364
>>>> https://cr.openjdk.java.net/~coffeys/webrev.8217364/webrev/
>>>>
>>>> regards,
>>>> Sean.
>>>>

From claes.redestad at oracle.com  Thu May  2 13:45:06 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 2 May 2019 15:45:06 +0200
Subject: RFR: 8217364: Custom URLStreamHandler for jrt or file protocol
 can override default handler
In-Reply-To: <bd2e631d-b105-e6ae-0160-1e93807f5f5e@oracle.com>
References: <1d37762f-7f17-6094-6193-885af8d72b72@oracle.com>
 <e3277eb3-1fcc-849a-f51a-ad431ec7cba7@oracle.com>
 <f416cb7e-328d-e532-0954-6e6f3923dfec@oracle.com>
 <c277058f-ae05-c257-4b59-ef2bc79347ef@oracle.com>
 <bd2e631d-b105-e6ae-0160-1e93807f5f5e@oracle.com>
Message-ID: <f0c060a7-60fd-bcf3-468a-7f9ab5dca149@oracle.com>

On 2019-05-02 15:20, Se?n Coffey wrote:
> Hi Claes,
> 
> Yes - looks like a fine suggestion.
> http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/

Looks good to me.. ;-)

/Claes

From Alan.Bateman at oracle.com  Thu May  2 17:57:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 18:57:26 +0100
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
In-Reply-To: <88ef6f36-01f4-5ee6-a0d8-982f45e783e5@gmail.com>
References: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
 <d59a04fa-a5b6-a70d-7864-613634a484f4@oracle.com>
 <88ef6f36-01f4-5ee6-a0d8-982f45e783e5@gmail.com>
Message-ID: <b8494dbf-aaad-ecef-cdd4-04d73934f478@oracle.com>

On 02/05/2019 10:33, Andre Naujoks wrote:
> :
> I just wanted to notify you, that the whole issue with binding to a
> multicast address is not Linux specific.
Understood as it's always been platform specific as to whether you could 
bind to a multicast address. This is one of the reason why we've had a 
recommendation in the API docs for several years to bind to the wildcard 
address and use the join methods to join the multicast group. This helps 
with the portability but has been problematic on Linux due to the 
"interference" issue. We had hoped that IP_MULTICAST_ALL had solved that 
but alas no. Once IPV6_MULTICAST_ALL is more widely available then we 
should try to make use of it.
>
> We are currently trying to reproduce the original issue with the
> reception of all multicast traffic on windows and will get back to you
> about that.
>
Thanks, I don't think we've seen this issue on any other platforms.

-Alan

From serguei.spitsyn at oracle.com  Sat May  4 01:14:41 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 3 May 2019 18:14:41 -0700
Subject: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
Message-ID: <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>

Hi Alex,

Thank you for creating the CSR!
I've added myself as a reviewer and corrected a couple of places.
Feel free to change my changes if necessary. :)
It would be nice to get one more CSR review if possible, so I've added 
the net-dev mailing list.

I hope to finish the webrev review soon.

Thanks,
Serguei

On 5/1/19 10:54 AM, Alex Menkov wrote:
> Hi all,
>
> I created CSR for the feature:
> https://bugs.openjdk.java.net/browse/JDK-8223104
>
> The latest webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>
> --alex


From aeubanks at google.com  Mon May  6 17:31:52 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 6 May 2019 10:31:52 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <fc40c777-c72c-d582-081d-e9e35779f3ca@oracle.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <fc40c777-c72c-d582-081d-e9e35779f3ca@oracle.com>
Message-ID: <CAPW48soxgcmiFh=kt3c7PhjPtOAP3oAKAc26CFnVrTyqs8Ak1g@mail.gmail.com>

I added a test that set an empty SecurityManager and called
InetAddress.getLoopbackAddress(). It passed, there were no permission
issues.
Then I looked at the code around NetworkInterface.getByInetAddress(), and I
don't see anything related to security managers, either in
NetworkInterface.getByInetAddress() or the native code it calls. There is
also no documentation on permission issues, unlike some of the other
methods in NetworkInterface (e.g. NetworkInterface.getInetAddresses()). So
it looks like there are no security manager issues here?

*From: *Alan Bateman <Alan.Bateman at oracle.com>
*Date: *Wed, May 1, 2019 at 11:43 PM
*To: *Arthur Eubanks, OpenJDK Network Dev list

On 01/05/2019 23:53, Arthur Eubanks wrote:
> > Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
> >
> NetworkInterface.getByInetAddress denies knowledge of addresses that you
> don't have a permission to connect to so I think this will need a
> privileged block for cases where you run with a security manager. That
> scenario may need a new test too, if only to make sure that early use
> will untrusted code on the stack will pick up the right loopback.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190506/d5d5c389/attachment.html>

From Alan.Bateman at oracle.com  Mon May  6 17:49:28 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 May 2019 18:49:28 +0100
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48soxgcmiFh=kt3c7PhjPtOAP3oAKAc26CFnVrTyqs8Ak1g@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <fc40c777-c72c-d582-081d-e9e35779f3ca@oracle.com>
 <CAPW48soxgcmiFh=kt3c7PhjPtOAP3oAKAc26CFnVrTyqs8Ak1g@mail.gmail.com>
Message-ID: <07d09ead-6cd0-5939-6c2a-9ec96231cc17@oracle.com>

On 06/05/2019 18:31, Arthur Eubanks wrote:
> I added a test that set an empty SecurityManager and called 
> InetAddress.getLoopbackAddress(). It passed, there were no permission 
> issues.
> Then I looked at the code around?NetworkInterface.getByInetAddress(), 
> and I don't see anything related to security managers, either in 
> NetworkInterface.getByInetAddress() or the native code it calls. There 
> is also no documentation on permission issues, unlike some of the 
> other methods in NetworkInterface (e.g. 
> NetworkInterface.getInetAddresses()). So it looks like there are no 
> security manager issues here?
>
My apologies, I was thinking NetworkInterface.getInetAddresses() which 
is specified to not leak local address. With 
NetworkInterface.getByInetAddress then you've already got a reference to 
the InetAddress so it's not an issue.

-Alan.

From serguei.spitsyn at oracle.com  Mon May  6 22:27:40 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 6 May 2019 15:27:40 -0700
Subject: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
Message-ID: <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190506/8e4bd7fd/attachment.html>

From martinrb at google.com  Mon May  6 22:55:01 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 May 2019 15:55:01 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
Message-ID: <CA+kOe0-i9K6gacC2EZKA6kai6XvvSW-kZbtxY4U-9MKqwEwEeg@mail.gmail.com>

On Thu, May 2, 2019 at 2:28 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

>
> 1. IPSupport needs to read system properties, attempts
>     to bind sockets etc... I wonder how that might interact
>     with tests that use a security manager, as some of these
>     operations may throw a SecurityException.
>     Maybe some double checking would be in order for those.
>

Reading system properties is such a common operation that test library code
should simply rely on the security manager allowing it.  Yes, it is
sometimes useful to have a DraconianSecurityManager in a test, including
one that disallows System.getProperty (I've written such a test myself!)
but then the use of that security manager should be scoped to a limited
operation that includes no test library code, as in

    /**
     * Runs Runnable r with a security policy that permits precisely
     * the specified permissions.  If there is no current security
     * manager, a temporary one is set for the duration of the
     * Runnable.  We require that any security manager permit
     * getPolicy/setPolicy.
     */
    public void runWithSecurityManagerWithPermissions(Runnable r,
                                                      Permission...
permissions) {

The same argument might apply to socket operations as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190506/107f83f9/attachment-0001.html>

From aeubanks at google.com  Mon May  6 23:50:38 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 6 May 2019 16:50:38 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
Message-ID: <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>

>
> 1. IPSupport needs to read system properties, attempts
>     to bind sockets etc... I wonder how that might interact
>     with tests that use a security manager, as some of these
>     operations may throw a SecurityException.
>     Maybe some double checking would be in order for those.
>
IIUC, a security manager that disallows everything would prevent the code
in IPSupport from working at all, and there's no way to get around it with
doPrivileged() since IPSupport and System.getProperty() are not in the same
protection domain. So something like IPSupport would need to be in
java.base, which doesn't make sense.
None of the tests touched in this change start failing. Given that fact,
does it make sense that tests in the future that test SecurityManagers and
networking should not use IPSupport, since it would be unreliable?
And what do you mean by double checking?

>
> 2. I would also be more comfortable if
>     skipIfCurrentConfigurationIsInvalid() (and possibly
>     the static initializer too?), could throw an
>     AssertionError if it finds that neither IPv4 nor IPv6
>     are available on a system. I'm concerned that a bug
>     that e.g. prevents to bind any socket would go unnoticed
>     if all tests are skipped...
>
hasIPv4 and hasIPv6 will both be false when IPv4 is not available
and java.net.preferIPv4Stack is true. In this case we should throw a
jtreg.SkippedException, not an AssertionError.
We can throw an AssertionError if java.net.preferIPv4Stack is not true and
both IPv4 and IPv6 are not available (meaning there's something wrong with
the system). This should catch things like binds not working.

New webrev (only IPSupport was changed):
http://cr.openjdk.java.net/~aeubanks/8220673/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190506/4acee787/attachment.html>

From nautsch2 at gmail.com  Tue May  7 07:24:42 2019
From: nautsch2 at gmail.com (Andre Naujoks)
Date: Tue, 7 May 2019 09:24:42 +0200
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
In-Reply-To: <b8494dbf-aaad-ecef-cdd4-04d73934f478@oracle.com>
References: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
 <d59a04fa-a5b6-a70d-7864-613634a484f4@oracle.com>
 <88ef6f36-01f4-5ee6-a0d8-982f45e783e5@gmail.com>
 <b8494dbf-aaad-ecef-cdd4-04d73934f478@oracle.com>
Message-ID: <e9eddf7f-730c-3afa-e776-aa8f31df5d84@gmail.com>

Am 02.05.19 um 19:57 schrieb Alan Bateman:
> On 02/05/2019 10:33, Andre Naujoks wrote:
>> :
>> I just wanted to notify you, that the whole issue with binding to a
>> multicast address is not Linux specific.
> Understood as it's always been platform specific as to whether you could
> bind to a multicast address. This is one of the reason why we've had a
> recommendation in the API docs for several years to bind to the wildcard
> address and use the join methods to join the multicast group. This helps
> with the portability but has been problematic on Linux due to the
> "interference" issue. We had hoped that IP_MULTICAST_ALL had solved that
> but alas no. Once IPV6_MULTICAST_ALL is more widely available then we
> should try to make use of it.
>>
>> We are currently trying to reproduce the original issue with the
>> reception of all multicast traffic on windows and will get back to you
>> about that.
>>
> Thanks, I don't think we've seen this issue on any other platforms.

Just to let you know, the original issue does not seem to be a problem
on Windows.

  Andre

> 
> -Alan


From chris.hegarty at oracle.com  Tue May  7 11:09:29 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 12:09:29 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CA+kOe0-i9K6gacC2EZKA6kai6XvvSW-kZbtxY4U-9MKqwEwEeg@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CA+kOe0-i9K6gacC2EZKA6kai6XvvSW-kZbtxY4U-9MKqwEwEeg@mail.gmail.com>
Message-ID: <91266F52-8103-4E7E-A7B7-719FD768A105@oracle.com>



> On 6 May 2019, at 23:55, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Thu, May 2, 2019 at 2:28 AM Daniel Fuchs <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>> wrote:
> 
> 1. IPSupport needs to read system properties, attempts
>     to bind sockets etc... I wonder how that might interact
>     with tests that use a security manager, as some of these
>     operations may throw a SecurityException.
>     Maybe some double checking would be in order for those.
> 
> Reading system properties is such a common operation that test library code should simply rely on the security manager allowing it.  Yes, it is sometimes useful to have a DraconianSecurityManager in a test, including one that disallows System.getProperty (I've written such a test myself!) but then the use of that security manager should be scoped to a limited operation that includes no test library code, as in 
> 
>     /**
>      * Runs Runnable r with a security policy that permits precisely
>      * the specified permissions.  If there is no current security
>      * manager, a temporary one is set for the duration of the
>      * Runnable.  We require that any security manager permit
>      * getPolicy/setPolicy.
>      */
>     public void runWithSecurityManagerWithPermissions(Runnable r,
>                                                       Permission... permissions) {
> 
> The same argument might apply to socket operations as well.


Right. It applies to socket operations also.

While I don't disagree with Martin, and it is a little cumbersome to
use test library code in combination with a security manager and a
fine-grained policy set in the jtreg @run tag, it should still work. For
example, the use of jdk.test.lib.net.SimpleSSlContext in one of the HTTP
Client tests [1] [2] [3].

It is almost trivial to add the appropriate privileged blocks to
IPSupport.
  http://cr.openjdk.java.net/~chegar/8220673/webrev.01_draft/test/lib/jdk/test/lib/net/IPSupport.java.html
  
We should just to it while here to avoid any small / trivial tests that
may want to set a security manager using jtreg's support, from even
considering writing their own version of IPSupport.

-Chris.  

[1] https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.java#l40
[2] https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24
[3] https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/lib/jdk/test/lib/net/SimpleSSLContext.java#l54

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

From pavel.rappo at oracle.com  Tue May  7 11:10:08 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 7 May 2019 12:10:08 +0100
Subject: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)
In-Reply-To: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
References: <b416df99-a476-98a9-a5bd-f8b48fd34ae3@gmail.com>
Message-ID: <649D245D-9F41-4669-A255-84B2AC6EE138@oracle.com>

We are currently investigating a more constrained fix for 8210493. I'll get back
to this list once it becomes clear(er) how to proceed.

> On 2 May 2019, at 08:44, Andre Naujoks <nautsch2 at gmail.com> wrote:
> 
> Hello all.
> 
> I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
> 12. With a new bug JDK-8215294 taking over the issue.
> 
> Just to let you know, the issue is not linux specific (as the new bug
> states). A test on a windows machine resulted in the same behavior.
> 
>  Andre
> 
> ### win10, openjdk12
> 
> Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App printProperties
> INFO: awt.toolkit: sun.awt.windows.WToolkit
> file.encoding: Cp1252
> file.separator: \
> java.awt.graphicsenv: sun.awt.Win32GraphicsEnvironment
> java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar
> java.class.version: 56.0
> java.home: C:\Program Files\Java\jdk-12.0.1
> java.io.tmpdir: C:\Users\WUENSC~1\AppData\Local\Temp\
> java.library.path: C:\Program
> Files\Java\jdk-12.0.1\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Users\wuenschmann\bin;C:\Program
> Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program
> Files\Git\usr\bin;C:\Program Files\Git\usr\bin;C:\Program
> Files\Git\mingw64\bin;C:\Program
> Files\Git\usr\bin;U:\bin;C:\Users\wuenschmann\coding\cygwin\bin;C:\Users\wuenschmann\coding\apache-maven-3.6.1;C:\Users\wuenschmann\coding\apache-maven-3.6.1\bin;C:\Program
> Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files
> (x86)\Intel\Intel(R) Management Engine Components\iCLS;C:\Program
> Files\Intel\Intel(R) Management Engine
> Components\iCLS;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program
> Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program
> Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files
> (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL
> Server\110\Tools\Binn;C:\Program Files\Git\cmd;C:\Program
> Files\PuTTY;C:\Program
> Files\Java\jdk-12.0.1;C:\Users\wuenschmann\AppData\Local\Microsoft\WindowsApps;C:\Users\wuenschmann\AppData\Local\atom\bin;C:\Program
> Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl;.
> java.runtime.name: OpenJDK Runtime Environment
> java.runtime.version: 12.0.1+12
> java.specification.name: Java Platform API Specification
> java.specification.vendor: Oracle Corporation
> java.specification.version: 12
> java.vendor: Oracle Corporation
> java.vendor.url: https://java.oracle.com/
> java.vendor.url.bug: https://bugreport.java.com/bugreport/
> java.version: 12.0.1
> java.version.date: 2019-04-16
> java.vm.compressedOopsMode: Zero based
> java.vm.info: mixed mode, sharing
> java.vm.name: OpenJDK 64-Bit Server VM
> java.vm.specification.name: Java Virtual Machine Specification
> java.vm.specification.vendor: Oracle Corporation
> java.vm.specification.version: 12
> java.vm.vendor: Oracle Corporation
> java.vm.version: 12.0.1+12
> jdk.debug: release
> line.separator:
> 
> os.arch: amd64
> os.name: Windows 10
> os.version: 10.0
> path.separator: ;
> sun.arch.data.model: 64
> sun.boot.library.path: C:\Program Files\Java\jdk-12.0.1\bin
> sun.cpu.endian: little
> sun.cpu.isalist: amd64
> sun.desktop: windows
> sun.io.unicode.encoding: UnicodeLittle
> sun.java.command: TestIPv6-1.0.0-SNAPSHOT.jar
> sun.java.launcher: SUN_STANDARD
> sun.jnu.encoding: Cp1252
> sun.management.compiler: HotSpot 64-Bit Tiered Compilers
> sun.os.patch.level:
> user.country: DE
> user.dir: C:\Users\wuenschmann\EclipseProject\TestIPv6\target
> user.home: C:\Users\wuenschmann
> user.language: de
> user.name: wuenschmann
> user.script:
> user.variant:
> 
> Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
> INFO: Got network interface: eth0 - 2
> Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
> INFO: ScopeID: 2
> Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
> INFO: Bind to: /ff12:0:0:0:0:0:4749:4750%eth0:29550
> Mai 02, 2019 8:45:38 VORM. de.nordsys.test.testipv6.App main
> SEVERE: null
> java.net.BindException: Cannot assign requested address: bind
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:455)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
> at de.nordsys.test.testipv6.App.main(App.java:152)
> 
> Exception in thread "main" java.lang.Error: java.net.BindException:
> Cannot assign requested address: bind
> at de.nordsys.test.testipv6.App.main(App.java:160)
> Caused by: java.net.BindException: Cannot assign requested address: bind
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:455)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
> at de.nordsys.test.testipv6.App.main(App.java:152)
> 
> 
> 
> 
> ### ubuntu-18.04, openjdk12:
> 
> Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App printProperties
> INFO: awt.toolkit: sun.awt.X11.XToolkit
> file.encoding: UTF-8
> file.separator: /
> java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment
> java.class.path: TestIPv6-1.0.0-SNAPSHOT.jar
> java.class.version: 56.0
> java.home: /usr/lib/jvm/jdk-12.0.1
> java.io.tmpdir: /tmp
> java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
> java.runtime.name: OpenJDK Runtime Environment
> java.runtime.version: 12.0.1+12
> java.specification.name: Java Platform API Specification
> java.specification.vendor: Oracle Corporation
> java.specification.version: 12
> java.vendor: Oracle Corporation
> java.vendor.url: https://java.oracle.com/
> java.vendor.url.bug: https://bugreport.java.com/bugreport/
> java.version: 12.0.1
> java.version.date: 2019-04-16
> java.vm.compressedOopsMode: 32-bit
> java.vm.info: mixed mode, sharing
> java.vm.name: OpenJDK 64-Bit Server VM
> java.vm.specification.name: Java Virtual Machine Specification
> java.vm.specification.vendor: Oracle Corporation
> java.vm.specification.version: 12
> java.vm.vendor: Oracle Corporation
> java.vm.version: 12.0.1+12
> jdk.debug: release
> line.separator:
> os.arch: amd64
> os.name: Linux
> os.version: 4.15.0-20-generic
> path.separator: :
> sun.arch.data.model: 64
> sun.boot.library.path: /usr/lib/jvm/jdk-12.0.1/lib
> sun.cpu.endian: little
> sun.desktop: gnome
> sun.io.unicode.encoding: UnicodeLittle
> sun.java.command: TestIPv6-1.0.0-SNAPSHOT.jar
> sun.java.launcher: SUN_STANDARD
> sun.jnu.encoding: UTF-8
> sun.management.compiler: HotSpot 64-Bit Tiered Compilers
> user.country: DE
> user.dir: /home/nico/EclipseProject/TestIPv6/target
> user.home: /home/nico
> user.language: de
> user.name: nico
> Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
> INFO: Got network interface: enp0s3 - 2
> Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
> INFO: ScopeID: 2
> Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
> INFO: Bind to: /ff12:0:0:0:0:0:4749:4750%enp0s3:29550
> Mai 02, 2019 7:57:57 VORM. de.nordsys.test.testipv6.App main
> SEVERE: null
> java.net.SocketException: Das Argument ist ung?ltig
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:455)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
> at de.nordsys.test.testipv6.App.main(App.java:152)
> Exception in thread "main" java.lang.Error: java.net.SocketException:
> Das Argument ist ung?ltig
> at de.nordsys.test.testipv6.App.main(App.java:160)
> Caused by: java.net.SocketException: Das Argument ist ung?ltig
> at java.base/sun.nio.ch.Net.bind0(Native Method)
> at java.base/sun.nio.ch.Net.bind(Net.java:455)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bindInternal(DatagramChannelImpl.java:814)
> at
> java.base/sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:785)
> at de.nordsys.test.testipv6.App.main(App.java:152)


From michael.x.mcmahon at oracle.com  Tue May  7 13:50:34 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 07 May 2019 14:50:34 +0100
Subject: RFR: 8223457 java.net.ServerSocket protected constructor should throw
 NPE if impl null
Message-ID: <5CD18D2A.8030200@oracle.com>

Could I get the following small change reviewed please?
The recent change in the SocketImpl code unmasked the fact that
the protected constructor of ServerSocket was not checking for a null
impl parameter as required.

http://cr.openjdk.java.net/~michaelm/8223457/webrev.1/

Thanks
Michael

From daniel.fuchs at oracle.com  Tue May  7 13:53:36 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 May 2019 14:53:36 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
Message-ID: <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>

Hi Arthur,

On 07/05/2019 00:50, Arthur Eubanks wrote:
[...]
> IIUC, a security manager that disallows everything would prevent the 
> code in IPSupport from working at all, and there's no way to get around 
> it with doPrivileged() since IPSupport and System.getProperty() are not 
> in the same protection domain. So something like IPSupport would need to 
> be in java.base, which doesn't make sense.

Some tests in the code base use policy files and arrange to grant all
permissions to the library code.

> None of the tests touched in this change start failing. Given that fact, 
> does it make sense that tests in the future that test SecurityManagers 
> and networking should not use IPSupport, since it would be unreliable?

The library code should have the appropriate doPrivileged block so that
the test or jtreg infrastructure can grant the appropriate permissions
to the library code, and shield the test itself from whatever permission
the library requires.

> And what do you mean by double checking?

Well - some tests could be designed to check that a security
exception is thrown. We should double check whether any test you
modified that has a security manager is trying to do that, and
verify that your proposed change doesn't cause such security
exception to be thrown by the library code instead.
The test could be quite happy, but no longer testing what it's
supposed to test if that happened.

Adding the doPrivileged in the library code is only half of the
answer: we must also make sure that any such test has also
the proper magic in place to make sure the library code is
granted the permission it needs. I believe we had this issue
in the past. I'll try to find out whatever we did to solve it.


[...]

> hasIPv4 and hasIPv6 will both be false when IPv4 is not available 
> and?java.net.preferIPv4Stack is true. In this case we should throw a 
> jtreg.SkippedException, not an AssertionError.
> We can throw an AssertionError if?java.net.preferIPv4Stack is not true 
> and both IPv4 and IPv6 are not available (meaning there's something 
> wrong with the system). This should catch things like binds not working.

That would be quite reasonable. Thanks.

> New webrev (only IPSupport was changed):
> http://cr.openjdk.java.net/~aeubanks/8220673/webrev.02/

I still believe the library code should have the appropriate
doPrivileged, and then we need to double check whether anything
more is needed (whether any policy file / custom Policy or
custom security manager that modified tests are using need
any updates to grant permission to library code).

best regards,

-- daniel


From daniel.fuchs at oracle.com  Tue May  7 13:55:49 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 May 2019 14:55:49 +0100
Subject: RFR: 8223457 java.net.ServerSocket protected constructor should
 throw NPE if impl null
In-Reply-To: <5CD18D2A.8030200@oracle.com>
References: <5CD18D2A.8030200@oracle.com>
Message-ID: <b0594654-582c-5063-19c1-55ad7bd081d8@oracle.com>

Looks good to me Michael!

best regards,

-- daniel

On 07/05/2019 14:50, Michael McMahon wrote:
> Could I get the following small change reviewed please?
> The recent change in the SocketImpl code unmasked the fact that
> the protected constructor of ServerSocket was not checking for a null
> impl parameter as required.
> 
> http://cr.openjdk.java.net/~michaelm/8223457/webrev.1/
> 
> Thanks
> Michael


From vyommani at gmail.com  Tue May  7 14:02:57 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Tue, 7 May 2019 19:32:57 +0530
Subject: RFR: 8223457 java.net.ServerSocket protected constructor should
 throw NPE if impl null
In-Reply-To: <5CD18D2A.8030200@oracle.com>
References: <5CD18D2A.8030200@oracle.com>
Message-ID: <CAKysZ8wmi=sE+fJXZr7KbSr158CyR8ybwOY5AczyVuh-rVXFfg@mail.gmail.com>

Looks good to me.
Vyom

On Tue, May 7, 2019 at 7:20 PM Michael McMahon <michael.x.mcmahon at oracle.com>
wrote:

> Could I get the following small change reviewed please?
> The recent change in the SocketImpl code unmasked the fact that
> the protected constructor of ServerSocket was not checking for a null
> impl parameter as required.
>
> http://cr.openjdk.java.net/~michaelm/8223457/webrev.1/
>
> Thanks
> Michael
>


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

From michael.x.mcmahon at oracle.com  Tue May  7 14:38:13 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 07 May 2019 15:38:13 +0100
Subject: RFR: 8223457 java.net.ServerSocket protected constructor should
 throw NPE if impl null
In-Reply-To: <b0594654-582c-5063-19c1-55ad7bd081d8@oracle.com>
References: <5CD18D2A.8030200@oracle.com>
 <b0594654-582c-5063-19c1-55ad7bd081d8@oracle.com>
Message-ID: <5CD19855.4060807@oracle.com>

Thanks.

On 07/05/2019, 14:55, Daniel Fuchs wrote:
> Looks good to me Michael!
>
> best regards,
>
> -- daniel
>
> On 07/05/2019 14:50, Michael McMahon wrote:
>> Could I get the following small change reviewed please?
>> The recent change in the SocketImpl code unmasked the fact that
>> the protected constructor of ServerSocket was not checking for a null
>> impl parameter as required.
>>
>> http://cr.openjdk.java.net/~michaelm/8223457/webrev.1/
>>
>> Thanks
>> Michael
>

From daniel.fuchs at oracle.com  Tue May  7 15:06:29 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 May 2019 16:06:29 +0100
Subject: [teststabilization] RFR: 8223463: Replace wildcard address with
 loopback or local host in tests - part 2
Message-ID: <cee93a02-5f26-3d70-4a9c-8fd29af838b6@oracle.com>

Hi,

Some more tests seen failing when using the wildcard address.
One of them actually needs the wildcard so for that one I simply
edited the summary to make it clear. There are more in the pipe
after those are fixed...

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


best regards,

-- daniel

From Alan.Bateman at oracle.com  Tue May  7 15:17:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 16:17:43 +0100
Subject: [teststabilization] RFR: 8223463: Replace wildcard address with
 loopback or local host in tests - part 2
In-Reply-To: <cee93a02-5f26-3d70-4a9c-8fd29af838b6@oracle.com>
References: <cee93a02-5f26-3d70-4a9c-8fd29af838b6@oracle.com>
Message-ID: <326d54d3-dae9-72f6-fb0d-a61897323462@oracle.com>

On 07/05/2019 16:06, Daniel Fuchs wrote:
> Hi,
>
> Some more tests seen failing when using the wildcard address.
> One of them actually needs the wildcard so for that one I simply
> edited the summary to make it clear. There are more in the pipe
> after those are fixed...
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8223463/webrev.00/
This looks good. In passing, it might be clearer if 
AcceptInheritHandle.test named is argument args rather than sysProps as 
it's an array of arguments for the child. Also you could use
Arrays.stream(sysProps).anyMatch("-Djava.net.preferIPv4Stack=true"::equals)
to avoid the Set if you want.

-Alan

From daniel.fuchs at oracle.com  Tue May  7 15:39:23 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 May 2019 16:39:23 +0100
Subject: [teststabilization] RFR: 8223463: Replace wildcard address with
 loopback or local host in tests - part 2
In-Reply-To: <326d54d3-dae9-72f6-fb0d-a61897323462@oracle.com>
References: <cee93a02-5f26-3d70-4a9c-8fd29af838b6@oracle.com>
 <326d54d3-dae9-72f6-fb0d-a61897323462@oracle.com>
Message-ID: <529e0a5b-ae37-b8ef-4760-e7ee681dc340@oracle.com>

Thaks Alan!

On 07/05/2019 16:17, Alan Bateman wrote:
> This looks good. In passing, it might be clearer if 
> AcceptInheritHandle.test named is argument args rather than sysProps as 
> it's an array of arguments for the child. Also you could use
> Arrays.stream(sysProps).anyMatch("-Djava.net.preferIPv4Stack=true"::equals)
> to avoid the Set if you want.

I did the suggested changes:

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

-- daniel

From Alan.Bateman at oracle.com  Tue May  7 15:43:01 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 16:43:01 +0100
Subject: [teststabilization] RFR: 8223463: Replace wildcard address with
 loopback or local host in tests - part 2
In-Reply-To: <529e0a5b-ae37-b8ef-4760-e7ee681dc340@oracle.com>
References: <cee93a02-5f26-3d70-4a9c-8fd29af838b6@oracle.com>
 <326d54d3-dae9-72f6-fb0d-a61897323462@oracle.com>
 <529e0a5b-ae37-b8ef-4760-e7ee681dc340@oracle.com>
Message-ID: <ad1bfa01-db4c-7364-155d-fb9332e0b2d9@oracle.com>



On 07/05/2019 16:39, Daniel Fuchs wrote:
> Thaks Alan!
>
> On 07/05/2019 16:17, Alan Bateman wrote:
>> This looks good. In passing, it might be clearer if 
>> AcceptInheritHandle.test named is argument args rather than sysProps 
>> as it's an array of arguments for the child. Also you could use
>> Arrays.stream(sysProps).anyMatch("-Djava.net.preferIPv4Stack=true"::equals) 
>>
>> to avoid the Set if you want.
>
> I did the suggested changes:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8223463/webrev.01/
Looks good.

From michael.x.mcmahon at oracle.com  Tue May  7 15:44:34 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 07 May 2019 16:44:34 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <5CD1A7E2.60903@oracle.com>

Hi Alan,

What's the purpose of the change to the UdpTest?

- Michael.

On 01/05/2019, 14:10, Alan Bateman wrote:
>
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
> finalized and the changes reviewed so that it can be targeted.
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
>
> The new implementation is one source file; the only other code change 
> is to SocketImpl.createPlatformSocketImpl to select the implementation 
> based on the system property jdk.net.usePlainSocketImpl. The reason 
> the patch isn't too big is that all the "enabling changes" are already 
> in jdk/jdk.
>
> We added additional tests a few weeks ago via JDK-8221259 [3] to test 
> long standing behavior. The webrev adds a few additional tests, the 
> main new one is to test that the SocketImpl is reliable in the fact of 
> usages that are not specified by SocketImpl. A selection of existing 
> tests are also updated to run with both the old and new implementation 
> - the motive of this is to ensure that the old implementation doesn't 
> bit rot before it is removed.
>
> Once the changes are in a promoted build then we'll need help testing. 
> The best outcome is that nobody notices :-)  Rory O'Donnell, with his 
> OpenJDK quality outreach hat on, has agreed to contact the projects 
> tracked by that program to test the EA builds when they are available.
>
> -Alan
>
> [1] https://openjdk.java.net/jeps/353
> [2] https://bugs.openjdk.java.net/browse/JDK-8222028
> [3] https://bugs.openjdk.java.net/browse/JDK-8221259

From chris.hegarty at oracle.com  Tue May  7 16:00:03 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 17:00:03 +0100
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
Message-ID: <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>

Arthur,

> On 1 May 2019, at 23:53, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/ <http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223214 <https://bugs.openjdk.java.net/browse/JDK-8223214>
I think the changes are good.

Minor comment: after this changes, the Inet6AddressImpl class-level
comment is a little misleading. Maybe it would benefit from a small
update.

 * If InetAddress.preferIPv6Address is true then anyLocalAddress(),
 * loopbackAddress(), and localHost() will return IPv6 addresses,
 * otherwise IPv4 addresses.

In your patch queue have you got any similar-ish changes relating to
`anyLocalAddress`? The reason I ask ( and it may not be an immediate
issue ) is that it is somewhat related, but kinda masked by code in the
native NET_InetAddressToSockaddr function, that maps the IPv4 wildcard
address to the IPv6 equivalent.

This change reminds me that; InetAddress getLoopbackAddress and
anyLocalAddress remove the need by the developer to think about the
particular IP version in use, as the methods should return an
appropriate address for the platform and environment in use. But 
sometimes you just want the IPv4 loopback or the IPv6 loopback, etc.
Should we add public API points for just this?

   Inet4Address::getIPv4LoopbackAddress
   Inet6Address::getIPv6LoopbackAddress
   Inet4Address::wildcardAddress
   Inet6Address::wildcardAddress
   
-Chris.   

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

From Alan.Bateman at oracle.com  Tue May  7 16:14:22 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 17:14:22 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <5CD1A7E2.60903@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com>
Message-ID: <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>

On 07/05/2019 16:44, Michael McMahon wrote:
> Hi Alan,
>
> What's the purpose of the change to the UdpTest?
The deprecated Socket constructors can be used to create a Socket that 
uses UDP. This means the new SocketImpl has to support the creation of 
UDP sockets and use the ResourceManager to enforce limits when running 
with a? security manager.? So it's just increasing test coverage as I 
wasn't able to find any tests in test/jdk that exercise it.

-Alan

From chris.hegarty at oracle.com  Tue May  7 16:30:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 17:30:51 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>


> On 1 May 2019, at 14:10, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] finalized and the changes reviewed so that it can be targeted.
> 
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html <http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html>

I have looked at this a number of times, already given some feedback and
pushed a few changes to the sandbox branch ( some time ago ).

Is this webrev ready for review? ( I see Michael has asked about a
change to UdpTest, but I see no UdpTest in the patch, maybe an old
version? )

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

From Alan.Bateman at oracle.com  Tue May  7 16:39:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 17:39:02 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>
Message-ID: <dd429470-2774-74f2-f139-cb430444f2dd@oracle.com>

On 07/05/2019 17:30, Chris Hegarty wrote:
>
>> On 1 May 2019, at 14:10, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>
>> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
>> finalized and the changes reviewed so that it can be targeted.
>>
>> The webrev with the changes is here:
>> http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
>
> I have looked at this a number of times, already given some feedback and
> pushed a few changes to the sandbox branch ( some time ago ).
>
> Is this webrev ready for review? ( I see Michael has asked about a
> change to UdpTest, but I see no UdpTest in the patch, maybe an old
> version? )
Yes, it is ready for review.

I think/assume Michael was asking about the changes to the 
Socket/UdpSocket.java test. I didn't touch ipv6tests/UdpTest.java as 
that is a DatagramSocket test.

-Alan


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

From aeubanks at google.com  Tue May  7 18:35:50 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 7 May 2019 11:35:50 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
Message-ID: <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>

>
> > IIUC, a security manager that disallows everything would prevent the
> > code in IPSupport from working at all, and there's no way to get around
> > it with doPrivileged() since IPSupport and System.getProperty() are not
> > in the same protection domain. So something like IPSupport would need to
> > be in java.base, which doesn't make sense.
>
> Some tests in the code base use policy files and arrange to grant all
> permissions to the library code.

Ah, I thought we wanted to be able to use IPSupport without having to
specify permissions in a policy file. Having to modify a policy file makes
IPSupport a leaky abstraction, but I suppose there's no way around it.

>
> > None of the tests touched in this change start failing. Given that fact,
> > does it make sense that tests in the future that test SecurityManagers
> > and networking should not use IPSupport, since it would be unreliable?
>
> The library code should have the appropriate doPrivileged block so that
> the test or jtreg infrastructure can grant the appropriate permissions
> to the library code, and shield the test itself from whatever permission
> the library requires.
>
> > And what do you mean by double checking?
>
> Well - some tests could be designed to check that a security
> exception is thrown. We should double check whether any test you
> modified that has a security manager is trying to do that, and
> verify that your proposed change doesn't cause such security
> exception to be thrown by the library code instead.
> The test could be quite happy, but no longer testing what it's
> supposed to test if that happened.
>
> Adding the doPrivileged in the library code is only half of the
> answer: we must also make sure that any such test has also
> the proper magic in place to make sure the library code is
> granted the permission it needs. I believe we had this issue
> in the past. I'll try to find out whatever we did to solve it.
>
When you said "double checking" I thought it was some terminology related
to security managers (e.g. "double checked locking") :P
I looked through all the tests I modified for any references to security
managers or policy files (grep "security" and "policy"). There is
one, test/jdk/java/net/InetAddress/GetLocalHostWithSM.java, but the call to
IPSupport is before the test sets the SecurityManager.
So the existing tests should not be affected by this.


With help from Chris's references ([1]), I added a test with a policy file
that grants IPSupport permission to listen/resolve localhost:0, and read
the java.net.preferIPv4Stack system property. Without either permission,
the test fails as expected.
One thing I discovered is that to make the policy file work properly with
the jtreg directory structure, I needed to add "@build
jdk.test.lib.net.IPSupport" to the test. So any test that wants to use
IPSupport and security managers needs to have that extra line and make sure
that its policy file contains all the permissions as in the new test policy
I added.
Without "@build jdk.test.lib.net.IPSupport", the policy file would need grant
codeBase "file:${test.classes}/-"
With "@build jdk.test.lib.net.IPSupport", the policy file needs grant
codeBase "file:${test.classes}/../../../../test/lib/-"
This matches [1], and seems more restrictive (only applies to test library
code) and better.

New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/

[1]:
https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/f0fc5a7f/attachment-0001.html>

From martinrb at google.com  Tue May  7 18:35:54 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 May 2019 11:35:54 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
Message-ID: <CA+kOe0-=+qJBF=NwHz6u+rHizPj5q+rkMs-2L5V2roHqqPPsTQ@mail.gmail.com>

TIL that we had tests with security policies so fine-grained that test
libraries were granted more permissions than other test code.

grant codeBase "file:${test.classes}/../../../../test/lib/-" {

Given that, I agree with Chris and Daniel that test library code should
include the same doPrivileged blocks that the JDK proper would.

*From: *Daniel Fuchs <daniel.fuchs at oracle.com>
*Date: *Tue, May 7, 2019 at 6:54 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list

Hi Arthur,
>
> On 07/05/2019 00:50, Arthur Eubanks wrote:
> [...]
> > IIUC, a security manager that disallows everything would prevent the
> > code in IPSupport from working at all, and there's no way to get around
> > it with doPrivileged() since IPSupport and System.getProperty() are not
> > in the same protection domain. So something like IPSupport would need to
> > be in java.base, which doesn't make sense.
>
> Some tests in the code base use policy files and arrange to grant all
> permissions to the library code.
>
> > None of the tests touched in this change start failing. Given that fact,
> > does it make sense that tests in the future that test SecurityManagers
> > and networking should not use IPSupport, since it would be unreliable?
>
> The library code should have the appropriate doPrivileged block so that
> the test or jtreg infrastructure can grant the appropriate permissions
> to the library code, and shield the test itself from whatever permission
> the library requires.
>
> > And what do you mean by double checking?
>
> Well - some tests could be designed to check that a security
> exception is thrown. We should double check whether any test you
> modified that has a security manager is trying to do that, and
> verify that your proposed change doesn't cause such security
> exception to be thrown by the library code instead.
> The test could be quite happy, but no longer testing what it's
> supposed to test if that happened.
>
> Adding the doPrivileged in the library code is only half of the
> answer: we must also make sure that any such test has also
> the proper magic in place to make sure the library code is
> granted the permission it needs. I believe we had this issue
> in the past. I'll try to find out whatever we did to solve it.
>
>
> [...]
>
> > hasIPv4 and hasIPv6 will both be false when IPv4 is not available
> > and java.net.preferIPv4Stack is true. In this case we should throw a
> > jtreg.SkippedException, not an AssertionError.
> > We can throw an AssertionError if java.net.preferIPv4Stack is not true
> > and both IPv4 and IPv6 are not available (meaning there's something
> > wrong with the system). This should catch things like binds not working.
>
> That would be quite reasonable. Thanks.
>
> > New webrev (only IPSupport was changed):
> > http://cr.openjdk.java.net/~aeubanks/8220673/webrev.02/
>
> I still believe the library code should have the appropriate
> doPrivileged, and then we need to double check whether anything
> more is needed (whether any policy file / custom Policy or
> custom security manager that modified tests are using need
> any updates to grant permission to library code).
>
> best regards,
>
> -- daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/d9f8cc99/attachment.html>

From serguei.spitsyn at oracle.com  Tue May  7 18:40:14 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 7 May 2019 11:40:14 -0700
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
Message-ID: <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>

Hi guys,

We need a couple of partial reviews for this enhancement:

 ?- From the net-dev to check IPv6-addresses related part.
 ?? It does not need to be a thorough review.
 ?? We need another pair of eyes to check for obvious typos or misses.
 ?? Included Chris H. to mailing list in hope for some assistance.
 ?? (Chris, we need some help to find one of the IPv6 experts.)

 ?- From the serviceability-dev to check if compatibility
 ?? is not broken and nothing is missed.
 ?? This includes part of code that is not directly involved
 ?? into manipulations with the IPv4/IPv6 addresses.
 ?? The related spec update is tracked by a sub-task:
 ???? https://bugs.openjdk.java.net/browse/JDK-8221707


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

The latest webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/


Thanks,
Serguei


On 5/6/19 3:27 PM, serguei.spitsyn at oracle.com wrote:
> Hi Alex,
>
> It looks great and very solid in general!
>
> Some minor comments are below.
>
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html
>
> 263 * Result must be release with dbgsysFreeAddrInfo.
> ? A typo: "must be release" => "must be released"
>
>    80 typedef struct {
> 81 struct in6_addr subnet;
> 82 struct in6_addr netmask;
>    83 } AllowedPeerInfo;
>   . . .
>
> 431 parseAllowedPeersInternal(char *buffer) { . . .
> 483 } . . . 524 isPeerAllowed(struct sockaddr_storage *peer) {
> 525 struct in6_addr tmp;
> 526 struct in6_addr *addr6;
> 527 if (peer->ss_family == AF_INET) {
> 528 convertIPv4ToIPv6((struct sockaddr *)peer, &tmp);
> 529 addr6 = &tmp;
> 530 } else {
> 531 addr6 = &(((struct sockaddr_in6 *)peer)->sin6_addr);
> 532 }
> 533
> 534 for (int i = 0; i < _peers_cnt; ++i) {
> 535 if (isAddressInSubnet(addr6, &(_peers[i].subnet), 
> &(_peers[i].netmask))) {
>   536             return 1;
>   537         }
>   538     }
> ?The allowed pears are converted into and used/checked in the IPv6 format.
> ?Some short comments about it in all three places above would be helpful.
> ?I'd consider to do the same in parseAllowedAddr() before this fragment:
> 367 if (addrInfo->ai_family == AF_INET6) {
> 368 memcpy(result, &(((struct sockaddr_in6 
> *)(addrInfo->ai_addr))->sin6_addr), sizeof(*result));
> 369 *isIPv4 = 0;
> 370 } else { // IPv4 address
> 371 struct in6_addr addr6;
> 372 convertIPv4ToIPv6(addrInfo->ai_addr, &addr6);
> 373 memcpy(result, &addr6, sizeof(*result));
> 374 *isIPv4 = 1;
>   375     }
>
> ?and in parseAllowedMask() before the line:
> 420 result->s6_addr[i] = (char)(0xFF << (8 - prefixLen));
>
> This fragment needs a comment: 402 if (isIPv4) {
> 403 prefixLen += 96;
>   404     }
>
>
> We have to find out at least one more reviewer for this fix!
>
> Thanks,
> Serguei
>
>
> On 5/3/19 18:14, serguei.spitsyn at oracle.com wrote:
>> Hi Alex,
>>
>> Thank you for creating the CSR!
>> I've added myself as a reviewer and corrected a couple of places.
>> Feel free to change my changes if necessary. :)
>> It would be nice to get one more CSR review if possible, so I've 
>> added the net-dev mailing list.
>>
>> I hope to finish the webrev review soon.
>>
>> Thanks,
>> Serguei
>>
>> On 5/1/19 10:54 AM, Alex Menkov wrote:
>>> Hi all,
>>>
>>> I created CSR for the feature:
>>> https://bugs.openjdk.java.net/browse/JDK-8223104
>>>
>>> The latest webrev:
>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>>>
>>> --alex
>>
>

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

From aeubanks at google.com  Tue May  7 20:36:03 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 7 May 2019 13:36:03 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
Message-ID: <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>

>
> Arthur,
>
> On 1 May 2019, at 23:53, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
>
>
> I think the changes are good.
>
> Minor comment: after this changes, the Inet6AddressImpl class-level
> comment is a little misleading. Maybe it would benefit from a small
> update.
>
>  * If InetAddress.preferIPv6Address is true then anyLocalAddress(),
>  * loopbackAddress(), and localHost() will return IPv6 addresses,
>  * otherwise IPv4 addresses.
>
Updated the comment.

>
> In your patch queue have you got any similar-ish changes relating to
> `anyLocalAddress`? The reason I ask ( and it may not be an immediate
> issue ) is that it is somewhat related, but kinda masked by code in the
> native NET_InetAddressToSockaddr function, that maps the IPv4 wildcard
> address to the IPv6 equivalent.
>
I don't see any other changes that are related to Inet6AddressImpl.

>
> This change reminds me that; InetAddress getLoopbackAddress and
> anyLocalAddress remove the need by the developer to think about the
> particular IP version in use, as the methods should return an
> appropriate address for the platform and environment in use. But
> sometimes you just want the IPv4 loopback or the IPv6 loopback, etc.
> Should we add public API points for just this?
>
>    Inet4Address::getIPv4LoopbackAddress
>    Inet6Address::getIPv6LoopbackAddress
>    Inet4Address::wildcardAddress
>    Inet6Address::wildcardAddress
>
I think that makes sense. We could also refactor some of these patches to
use those rather than specifying "::1" or {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}.

New webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/374dc0f3/attachment-0001.html>

From aeubanks at google.com  Wed May  8 00:48:40 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 7 May 2019 17:48:40 -0700
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
 <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
Message-ID: <CAPW48spqNsnHxFYim2QWr_FpoV8XydcZtn1ZwCfgsiNJtVuHRA@mail.gmail.com>

Even though I showed our internal patches in this area earlier, I haven't
really looked into exactly what this patch does (since it was written by
someone else).
I can confirm that it fixes jshell in an IPv6 only environment though.

*From: *<serguei.spitsyn at oracle.com>
*Date: *Tue, May 7, 2019 at 11:42 AM
*To: *Alex Menkov, <serviceability-dev at openjdk.java.net>, net-dev, Chris
Hegarty

Hi guys,
>
> We need a couple of partial reviews for this enhancement:
>
>  - From the net-dev to check IPv6-addresses related part.
>    It does not need to be a thorough review.
>    We need another pair of eyes to check for obvious typos or misses.
>    Included Chris H. to mailing list in hope for some assistance.
>    (Chris, we need some help to find one of the IPv6 experts.)
>
>  - From the serviceability-dev to check if compatibility
>    is not broken and nothing is missed.
>    This includes part of code that is not directly involved
>    into manipulations with the IPv4/IPv6 addresses.
>    The related spec update is tracked by a sub-task:
>      https://bugs.openjdk.java.net/browse/JDK-8221707
>
>
> Related CSR:
> https://bugs.openjdk.java.net/browse/JDK-8223104
>
> The latest webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>
>
> Thanks,
> Serguei
>
>
> On 5/6/19 3:27 PM, serguei.spitsyn at oracle.com wrote:
>
> Hi Alex,
>
> It looks great and very solid in general!
>
> Some minor comments are below.
>
>
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html
>
>  263  * Result must be release with dbgsysFreeAddrInfo.
>
>   A typo: "must be release" => "must be released"
>
>   80 typedef struct {  81     struct in6_addr subnet;  82     struct in6_addr netmask;
>   83 } AllowedPeerInfo;
>  . . .
>  431 parseAllowedPeersInternal(char *buffer) {
>  . . . 483 }
>  . . .
>  524 isPeerAllowed(struct sockaddr_storage *peer) { 525     struct in6_addr tmp; 526     struct in6_addr *addr6; 527     if (peer->ss_family == AF_INET) { 528         convertIPv4ToIPv6((struct sockaddr *)peer, &tmp); 529         addr6 = &tmp; 530     } else { 531         addr6 = &(((struct sockaddr_in6 *)peer)->sin6_addr); 532     } 533  534     for (int i = 0; i < _peers_cnt; ++i) { 535         if (isAddressInSubnet(addr6, &(_peers[i].subnet), &(_peers[i].netmask))) {
>  536             return 1;
>  537         }
>  538     }
>
>  The allowed pears are converted into and used/checked in the IPv6 format.
>  Some short comments about it in all three places above would be helpful.
>  I'd consider to do the same in parseAllowedAddr() before this fragment:
>
>  367     if (addrInfo->ai_family == AF_INET6) { 368         memcpy(result, &(((struct sockaddr_in6 *)(addrInfo->ai_addr))->sin6_addr), sizeof(*result)); 369         *isIPv4 = 0; 370     } else {    // IPv4 address 371         struct in6_addr addr6; 372         convertIPv4ToIPv6(addrInfo->ai_addr, &addr6); 373         memcpy(result, &addr6, sizeof(*result)); 374         *isIPv4 = 1;
>  375     }
>
>
>  and in parseAllowedMask() before the line:
>
>  420             result->s6_addr[i] = (char)(0xFF << (8 - prefixLen));
>
>
>  This fragment needs a comment:
>  402     if (isIPv4) { 403         prefixLen += 96;
>  404     }
>
>
>
> We have to find out at least one more reviewer for this fix!
>
> Thanks,
> Serguei
>
>
> On 5/3/19 18:14, serguei.spitsyn at oracle.com wrote:
>
> Hi Alex,
>
> Thank you for creating the CSR!
> I've added myself as a reviewer and corrected a couple of places.
> Feel free to change my changes if necessary. :)
> It would be nice to get one more CSR review if possible, so I've added the
> net-dev mailing list.
>
> I hope to finish the webrev review soon.
>
> Thanks,
> Serguei
>
> On 5/1/19 10:54 AM, Alex Menkov wrote:
>
> Hi all,
>
> I created CSR for the feature:
> https://bugs.openjdk.java.net/browse/JDK-8223104
>
> The latest webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>
> --alex
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/9385f9ab/attachment.html>

From aeubanks at google.com  Wed May  8 05:52:09 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 7 May 2019 22:52:09 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
Message-ID: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8223532
Webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.00/

There are a couple of functions in
src/java.base/unix/native/libnet/NetworkInterface.c which try to create
IPv4 sockets, then check if errno is EPROTONOSUPPORT. If errno is
EPROTONOSUPPORT, then IPv6 is tried, else it immediately bails.

We have a kernel that returns EAFNOSUPPORT when IPv4 is disabled and there
is an attempt to create an AF_INET socket.

Rather than adding a check for EAFNOSUPPORT, which seems too specific, just
don't bother trying to create an IPv4 socket if IPv4 is not available. This
uses ipv4_available(), introduced in
http://hg.openjdk.java.net/jdk/jdk/rev/22323f20401b.

Since previously the code assumed that we have at least IPv4, now when
initializing ipv4/6_available(), make sure that at least one of them is
available, or else bail. One problem I have with this is that the error
message when neither is present is not descriptive:
Error occurred during initialization of boot layer
java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF required
by path/to/jdk/build/jdk/lib/libnet.so
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/773684e1/attachment.html>

From christoph.langer at sap.com  Wed May  8 08:02:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 May 2019 08:02:58 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
Message-ID: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review a small change that I'd like to see in OpenJDK to get rid of compilation errors in the Eclipse IDE.

It seems the root cause for the compilation errors is that javac would sometimes widen capture variables and is hence able to compile the places that I touch here. The EC4J compiler claims that it's following the spec more strictly and bails out at these places. I had posted about this on compiler-dev but got no reaction [0].

So, as this seems to be some field of open work for the compiler/spec folks, I'd like to get EC4J quiesced by introducing some slight modifications to the original places which makes the code appeal a bit less elegant and fluent but will get rid of the compile errors.

Please review:
Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/

The modification to src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java belongs to JSR-166, so I don't know if it needs some special handling.

Thanks & Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html

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

From daniel.fuchs at oracle.com  Wed May  8 10:45:20 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 May 2019 11:45:20 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
Message-ID: <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>

Hi Arthur,

The idea looks reasonable to me - I believe the changes in
NetworkInterface.c should be OK.

However - I don't think the changes in net_util.c::DEF_JNI_OnLoad
are acceptable.
I'll question whether this is the right place to bail
out. I agree it would be nice to have some diagnostic
that tells us that the native library is non-functioning
because both IPv4 & IPv6 where not available, but I'd rather
have this check at the place where the code actually tries
to e.g. open an IP/TCP socket, and where throwing a regular exception
with a better detailed message is possible, rather than
having the VM fail to start with some cryptic UnsatisfiedLinkError.

best regards,

-- daniel

On 08/05/2019 06:52, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223532
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.00/
> 
> There are a couple of functions in 
> src/java.base/unix/native/libnet/NetworkInterface.c which try to create 
> IPv4 sockets, then check if errno is EPROTONOSUPPORT. If errno is 
> EPROTONOSUPPORT, then IPv6 is tried, else it immediately bails.
> 
> We have a kernel that returns EAFNOSUPPORT when IPv4 is disabled and 
> there is an attempt to create an AF_INET socket.
> 
> Rather than adding a check for EAFNOSUPPORT, which seems too specific, 
> just don't bother trying to create an IPv4 socket if IPv4 is not 
> available. This uses ipv4_available(), introduced in 
> http://hg.openjdk.java.net/jdk/jdk/rev/22323f20401b.
> 
> Since previously the code assumed that we have at least IPv4, now when 
> initializing ipv4/6_available(), make sure that at least one of them is 
> available, or else bail. One problem I have with this is that the error 
> message when neither is present is not descriptive:
> Error occurred during initialization of boot layer
> java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF 
> required by path/to/jdk/build/jdk/lib/libnet.so


From chris.hegarty at oracle.com  Wed May  8 11:02:30 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 May 2019 12:02:30 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
Message-ID: <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>

Arthur,

On 07/05/2019 19:35, Arthur Eubanks wrote:
> ...
> 
> 
> With help from Chris's references ([1]), I added a test with a policy 
> file that grants IPSupport permission to listen/resolve localhost:0, and 
> read the java.net.preferIPv4Stack system property. Without either 
> permission, the test fails as expected.
> One thing I discovered is that to make the policy file work properly 
> with the jtreg directory structure, I needed to add "@build 
> jdk.test.lib.net.IPSupport" to the test. So any test that wants to use 
> IPSupport and security managers needs to have that extra line and make 
> sure that its policy file contains all the permissions as in the new 
> test policy I added.

That is ok.

> Without "@build jdk.test.lib.net.IPSupport", the policy file would need 
> grant codeBase "file:${test.classes}/-"
> With?"@build jdk.test.lib.net.IPSupport", the policy file needs grant 
> codeBase "file:${test.classes}/../../../../test/lib/-"

Right, the difference comes from how jtreg builds its dependencies. The
former is an example of when a library is used conveniently with just
the @library tag, the library is automatically compiled into the
specific test's classes directory. The latter is when the library is
explicitly compiled with an @build, and gets put into a shared library
output directory, so that other tests ( that also specify an @build with
that library name ) can use the pre-built classes.

> This matches [1], and seems more restrictive (only applies to test 
> library code) and better.
> 
> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/

I am happy with this latest version. Reviewed.

Trivially, maybe rename B8220673.java to something more descriptive
( without the bug no. ). Maybe MinimumPermissions? or whatever,
no need for a new webrev.

-Chris.

P.S. adding nio-dev since there are a few tests in that area
being updated.

> 
> [1]: 
> https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24

From daniel.fuchs at oracle.com  Wed May  8 11:22:22 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 May 2019 12:22:22 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
Message-ID: <ae5f2cd0-9638-d9c7-d8ba-f7ea4e3e83da@oracle.com>

Hi Arthur,

On 07/05/2019 19:35, Arthur Eubanks wrote:
> When you said "double checking" I thought it was some terminology 
> related to security managers (e.g. "double checked locking") :P

Oh - sorry I was not clear enough.

> I looked through all the tests I modified for any references to security 
> managers or policy files (grep "security" and "policy"). There is 
> one,?test/jdk/java/net/InetAddress/GetLocalHostWithSM.java, but the call 
> to IPSupport is before the test sets the SecurityManager.
> So the existing tests should not be affected by this.

Thanks :-) That's what I wanted to hear.

> With help from Chris's references ([1]), I added a test with a policy 
> file that grants IPSupport permission to listen/resolve localhost:0, and 
> read the java.net.preferIPv4Stack system property. Without either 
> permission, the test fails as expected.
> One thing I discovered is that to make the policy file work properly 
> with the jtreg directory structure, I needed to add "@build 
> jdk.test.lib.net.IPSupport" to the test. So any test that wants to use 
> IPSupport and security managers needs to have that extra line and make 
> sure that its policy file contains all the permissions as in the new 
> test policy I added.
> Without "@build jdk.test.lib.net.IPSupport", the policy file would need 
> grant codeBase "file:${test.classes}/-"
> With?"@build jdk.test.lib.net.IPSupport", the policy file needs grant 
> codeBase "file:${test.classes}/../../../../test/lib/-"
> This matches [1], and seems more restrictive (only applies to test 
> library code) and better.

Ah! yes - there's this old (odd?) behavior about where jtreg
generates the library test classes. That has bitten us in the
past - mostly because if you start using using @build then
the test must explicitly list all classes it intends to use.
Otherwise, some test might pass 'by chance' because some
other test has run before and caused jtreg to compile the
classes it needs. The classic symptom would be that the test passes
when you run :jdk_net but fail when you run it in isolation
(when it's the only test that your jtreg command line compiles).

So if you add  @build jdk.test.lib.net.IPSupport then please
make sure to add all the library classes that the test might
be using on the @build command line (IIRC wildcards are also
accepted). Just mentioning it for the future as I see these
changes shouldn't have this issue.

> 
> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/

http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/test/jdk/java/net/MulticastSocket/JoinLeave.java.frames.html

has two `@library /test/lib` lines

The rest looks very good to me!
Thanks for taking that on, and thanks for adding the new test!

best regards,

-- daniel

> 
> [1]: 
> https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24


From chris.hegarty at oracle.com  Wed May  8 11:51:38 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 May 2019 12:51:38 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
Message-ID: <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>

Arthur, Daniel,

On 08/05/2019 11:45, Daniel Fuchs wrote:
> Hi Arthur,
> 
> The idea looks reasonable to me - I believe the changes in
> NetworkInterface.c should be OK.

I agree.

Now that I look at this again, I think it may also be reasonable to
consider EAFNOSUPPORT in a similar way to that of EPROTONOSUPPORT. To
me it is really a matter of interpretation by the Kernel developer which
gets thrown and at which point ( protocol / family /type compiled out
of the Kernel or disabled by the System Administrator ). Anyway, what
Arthur is proposing for NetworkInterface is fine.

> However - I don't think the changes in net_util.c::DEF_JNI_OnLoad
> are acceptable.

Agree.

> I'll question whether this is the right place to bail
> out. I agree it would be nice to have some diagnostic
> that tells us that the native library is non-functioning
> because both IPv4 & IPv6 where not available, but I'd rather
> have this check at the place where the code actually tries
> to e.g. open an IP/TCP socket, and where throwing a regular exception
> with a better detailed message is possible, rather than
> having the VM fail to start with some cryptic UnsatisfiedLinkError.

The cryptic error message ( generated by returning a JNI version that is
not supported by the VM ) indicates that this is not the right place.

> ...
> On 08/05/2019 06:52, Arthur Eubanks wrote:
>> ...
>> Since previously the code assumed that we have at least IPv4, now when 
>> initializing ipv4/6_available(), make sure that at least one of them 
>> is available, or else bail. One problem I have with this is that the 
>> error message when neither is present is not descriptive:
>> Error occurred during initialization of boot layer
>> java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF 
>> required by path/to/jdk/build/jdk/lib/libnet.so

While the vast majority of libnet.so is devoted to socket related
implementation, not all is. There are a small number of low-level pieces
of functionality that can be used with support for either IPv4 or IPv6
being present. The NIO implementation also uses some shared common
functionality from libnet.so. It seems overly restricting to disallow
libnet.so from loading if neither IPv4 or IPv6 are present.

I'm just not sure that this is needed at all.

-Chris.


From Alan.Bateman at oracle.com  Wed May  8 14:58:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 May 2019 15:58:31 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
Message-ID: <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>



On 08/05/2019 12:51, Chris Hegarty wrote:
>
> While the vast majority of libnet.so is devoted to socket related
> implementation, not all is. There are a small number of low-level pieces
> of functionality that can be used with support for either IPv4 or IPv6
> being present. The NIO implementation also uses some shared common
> functionality from libnet.so. It seems overly restricting to disallow
> libnet.so from loading if neither IPv4 or IPv6 are present.
>
I agree as an innocent reference to a type in java.net might resulting 
in libnet being loaded as a side effect. We also have the issue that the 
file system implementation is in libnio so libnet will be loaded there 
too (although shouldn't trigger its JNI OnLoad to be run).

-Alan


From chris.hegarty at oracle.com  Wed May  8 15:25:05 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 May 2019 16:25:05 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>

Alan,

On 01/05/2019 14:10, Alan Bateman wrote:
> 
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
> finalized and the changes reviewed so that it can be targeted.
> 
> The webrev with the changes is here:
>  ?? http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
This is a nice. The code is well structured and much more readable than
the plain implementation.

Some specific comments:

NioSocketImpl.java

  If configureBlocking returned a boolean, then an assert could be
  written to ensure that it operates as expected. For example, both
  connect and accept require it to actually switch the block mode for
  timed operations when called ( it cannot be a no-op ).

  RuntimeException is being used to transport IOException between
  FileDescriptorCloser::run ( which cannot throw a checked exception )
  and tryClose. I believe that tryClose should catch and unwrap this
  carrier RuntimeException.

  When tryClose is invoked in end[Read|Write|Connect|Accept], I believe
  that IOExceptions should be suppressed, at least when `completed` is
  true.

  typos "an" -> "a"
   408  * @throws SocketException if the socket is closed or *an* socket 
I/O error occurs
   429  * @throws SocketException if the socket is closed or *an* socket 
I/O error occurs

   882         // shutdown output when linger interval not set to 0
   883         try {
   884             var SO_LINGER = StandardSocketOptions.SO_LINGER;
   885             if ((int) Net.getSocketOption(fd, SO_LINGER) != 0) {
   886                 Net.shutdown(fd, Net.SHUT_WR);
   887             }
   888         } catch (IOException ignore) { }

  Is this a bug fix, or something that you ran across? I'm not familiar
  with this.

SocketImpl.java

  "45  * @implNote Client and server sockets created with the {@code 
Socket} and
   46  * {@code SocketServer} public constructors create a 
system/platform default
   47  * {@code SocketImpl}."

  The public no-args j.n.Socket constructor has the following slightly
  different wording: "Creates an unconnected socket, with the
  system-default type of SocketImpl." - these should probably be
  consistent.

  Why the use of "Java virtual machine" and "command line", since it is
  just a system property. I assume that this must come from the read-once
  nature of its impact? If so, are there other example of such and where?

  49  * newer implementation. The JDK continues to ship with the older 
implementation
  50  * to allow code to run that depends on unspecified behavior that 
differs between
  51  * the old and new implementations.

  If the intention of this property is as a temporarily aid for folk,
  that have code that depend upon the unspecified behavior, to run
  successfully until that code can be amended to remove the dependency on
  the particular unspecified behavior, then can that please be made
  clear.

  The property is effectively terminally deprecated at birth, right? If
  so, can a note indicating such be added.

Timeouts.java

  The test uses `assertTrue(false);` in a few places. TestNG has
  `org.testng.Assert.fail(String)` for this.

  Only time will tell if these tests that check duration will be stable
  on all platforms and configurations.

UdpSocket.java

  The new test scenario uses a hardcoded port number. Could this be a
  problem?

   121             while (ref.get() != null) {
   122                 System.gc();
   123                 Thread.sleep(100);
   124             }

  Is this loop guaranteed to exist at some point?

  80   assertTrue(Arrays.equals(array1, 0, n, array2, 0, n), "Unexpected 
contents");

  Can use `assertEquals(byte[] actual, byte[] expected, String message)`,
  which will print the arrays if unequal.

NewSocketMethods.java

  Is the change in this class still needed, or left over from a previous
  iteration?

test/jdk/java/net/SocketImpl/BadUsages.java

  At one point I added test/jdk/java/net/SocketImpl/BadSocketImpls.java
  to the sandbox branch. Have the test scenarios been subsumed into
  BadUsages? Or where have they gone?

-Chris.



From aeubanks at google.com  Wed May  8 16:02:42 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 8 May 2019 09:02:42 -0700
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <ae5f2cd0-9638-d9c7-d8ba-f7ea4e3e83da@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <ae5f2cd0-9638-d9c7-d8ba-f7ea4e3e83da@oracle.com>
Message-ID: <CAPW48srM1gpirOa6P_0xtpyyOWSaZz39xRcz23A4PsUr1Fz3Rg@mail.gmail.com>

>
> Trivially, maybe rename B8220673.java to something more descriptive
> ( without the bug no. ). Maybe MinimumPermissions? or whatever,
> no need for a new webrev.

Done


> So if you add  @build jdk.test.lib.net.IPSupport then please
> make sure to add all the library classes that the test might
> be using on the @build command line (IIRC wildcards are also
> accepted). Just mentioning it for the future as I see these
> changes shouldn't have this issue.
>
Noted, thanks.

>
>
> http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/test/jdk/java/net/MulticastSocket/JoinLeave.java.frames.html
>
> has two `@library /test/lib` lines

Fixed.

http://cr.openjdk.java.net/~aeubanks/8220673/webrev.04/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190508/8a6c1979/attachment.html>

From daniel.fuchs at oracle.com  Wed May  8 16:16:24 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 May 2019 17:16:24 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48srM1gpirOa6P_0xtpyyOWSaZz39xRcz23A4PsUr1Fz3Rg@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <ae5f2cd0-9638-d9c7-d8ba-f7ea4e3e83da@oracle.com>
 <CAPW48srM1gpirOa6P_0xtpyyOWSaZz39xRcz23A4PsUr1Fz3Rg@mail.gmail.com>
Message-ID: <294ee635-b626-6d3e-0f69-ae1c27398a32@oracle.com>

On 08/05/2019 17:02, Arthur Eubanks wrote:
> http://cr.openjdk.java.net/~aeubanks/8220673/webrev.04/

LGTM.

best regards,

-- daniel

From Alan.Bateman at oracle.com  Wed May  8 17:18:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 May 2019 18:18:21 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
Message-ID: <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>

On 08/05/2019 16:25, Chris Hegarty wrote:
> This is a nice. The code is well structured and much more readable than
> the plain implementation.
Thanks for doing through the implementation.

> :
>
> NioSocketImpl.java
>
> ?If configureBlocking returned a boolean, then an assert could be
> ?written to ensure that it operates as expected. For example, both
> ?connect and accept require it to actually switch the block mode for
> ?timed operations when called ( it cannot be a no-op ).
It's just connect that restores the blocking mode after a connection is 
established with a timeout. IOException is thrown if it fails. I assume 
you are wondering if there is a code path that calls 
configureNonBlockingForever that locks the socket in non-blocking mode. 
I guess we could add asserts but that would complicate down stream work. 
So I guess I'm inclined to leave it as is, and add any comments to help 
if there isn't anything obvious on how it works.


>
> ?RuntimeException is being used to transport IOException between
> ?FileDescriptorCloser::run ( which cannot throw a checked exception )
> ?and tryClose. I believe that tryClose should catch and unwrap this
> ?carrier RuntimeException.
Fair point as there is an assumption it cannot fail. There is actually 
is a long standing issue here in that 
FileDispatcherImpl.closeFileDescriptor should not throw an exception if 
close fails with EINTR (as close is not restartable). If it fails with 
anything else then it suggests a serious bug somewhere.

> :
>
> ?typos "an" -> "a"
> ? 408? * @throws SocketException if the socket is closed or *an* 
> socket I/O error occurs
> ? 429? * @throws SocketException if the socket is closed or *an* 
> socket I/O error occurs
Thanks.


>
> ? 882???????? // shutdown output when linger interval not set to 0
> ? 883???????? try {
> ? 884???????????? var SO_LINGER = StandardSocketOptions.SO_LINGER;
> ? 885???????????? if ((int) Net.getSocketOption(fd, SO_LINGER) != 0) {
> ? 886???????????????? Net.shutdown(fd, Net.SHUT_WR);
> ? 887???????????? }
> ? 888???????? } catch (IOException ignore) { }
>
> ?Is this a bug fix, or something that you ran across? I'm not familiar
> ?with this.
This preserves existing behavior to do a graceful shutdown when there is 
no linger interval. If you look at the NET_SocketClose implementation on 
Windows or SocketChannelImpl.close then you'll see what I mean.

>
> SocketImpl.java
>
> ?"45? * @implNote Client and server sockets created with the {@code 
> Socket} and
> ? 46? * {@code SocketServer} public constructors create a 
> system/platform default
> ? 47? * {@code SocketImpl}."
>
> ?The public no-args j.n.Socket constructor has the following slightly
> ?different wording: "Creates an unconnected socket, with the
> ?system-default type of SocketImpl." - these should probably be
> ?consistent.
Okay, I can try to keep it consistent although at some point I think we 
should do a pass over some of the JDK 1.0 era javadoc and re-visit the 
places it talks about the default SocketImpl, esp. all the references to 
"plain".

>
> ?Why the use of "Java virtual machine" and "command line", since it is
> ?just a system property. I assume that this must come from the read-once
> ?nature of its impact? If so, are there other example of such and where?
It's not reliable to set the system property in a running VM so the note 
is just setting the expectations that it needs to be set at startup, 
nothing more.

>
> ?49? * newer implementation. The JDK continues to ship with the older 
> implementation
> ?50? * to allow code to run that depends on unspecified behavior that 
> differs between
> ?51? * the old and new implementations.
>
> ?If the intention of this property is as a temporarily aid for folk,
> ?that have code that depend upon the unspecified behavior, to run
> ?successfully until that code can be amended to remove the dependency on
> ?the particular unspecified behavior, then can that please be made
> ?clear.
>
> ?The property is effectively terminally deprecated at birth, right? If
> ?so, can a note indicating such be added.
The intention is that implNote will be removed when the property and old 
implementation are removed. It's something that I was going to put in 
the RN/docs but I guess we could extend the implNote on this point too.


>
> Timeouts.java
>
> ?The test uses `assertTrue(false);` in a few places. TestNG has
> ?`org.testng.Assert.fail(String)` for this.
Okay.


>
> ?Only time will tell if these tests that check duration will be stable
> ?on all platforms and configurations.
Right, it's always tricky to test timeout behavior. In this case, I've 
run the test 1000+ times on all platforms and have not seen any failures.

>
> UdpSocket.java
>
> ?The new test scenario uses a hardcoded port number. Could this be a
> ?problem?
The host/port specified to the 3-arg constructor is the remote socket 
address that it connects to, not the local address/port. So it's like 
DatagramSocket.connect and any port will do because it's not 
sending/receiving packets.

>
> ? 121???????????? while (ref.get() != null) {
> ? 122???????????????? System.gc();
> ? 123???????????????? Thread.sleep(100);
> ? 124???????????? }
>
> ?Is this loop guaranteed to exist at some point?
We use this idiom in several tests. If someone where to run the tests 
with +DisableExplicitGC then it would fail but hundreds of other tests 
would also fail.

>
> ?80?? assertTrue(Arrays.equals(array1, 0, n, array2, 0, n), 
> "Unexpected contents");
>
> ?Can use `assertEquals(byte[] actual, byte[] expected, String message)`,
> ?which will print the arrays if unequal.
Fair point although this is the existing test where it just throws when 
the size or contents differ.


>
> NewSocketMethods.java
>
> ?Is the change in this class still needed, or left over from a previous
> ?iteration?
This is an outlier on Solaris as that platform doesn't allow IPV6_TCLASS 
to be set when the socket is connected. There is a note in the JEP on 
this as it is masked by the old implementation. I see you've collected 
some useful info in JDK-8221487 on the issue so I think we can keep it 
separate.


>
> test/jdk/java/net/SocketImpl/BadUsages.java
>
> ?At one point I added test/jdk/java/net/SocketImpl/BadSocketImpls.java
> ?to the sandbox branch. Have the test scenarios been subsumed into
> ?BadUsages? Or where have they gone?
BadSocketImpls.java exercised the platform SocketImpl accepting a 
connection with a no-op SocketImpl.? It pre-dates the work in 
JDK-8220493 to prevent such combinations. We added 
SocketImplCombinations.java as part of JDK-8220493 to test all the 
combinations and scenarios that we could come up, I don't think there 
was anything in BadSocketImpls that we could bring over.

-Alan.

From daniel.fuchs at oracle.com  Wed May  8 17:24:10 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 May 2019 18:24:10 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
Message-ID: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>

Hi,

Please find below another patch in the series for intermittently
failing tests:

8223573: Replace wildcard address with loopback or local host in
          tests - part 4
https://bugs.openjdk.java.net/browse/JDK-8223573

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

best regards,

-- daniel

From aeubanks at google.com  Wed May  8 17:33:18 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 8 May 2019 10:33:18 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
Message-ID: <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>

Reverted changes in net_util.c.
Also, webrev.00 would create an IPv6 socket even if creating the IPv4
socket was successful. Fixed. (My very first revision had this same issue,
which I thought I had fixed before sending it out. Tricky if statements
have been cleaned up to make this less likely to happen again in the
future.)

http://cr.openjdk.java.net/~aeubanks/8223532/webrev.01/

*From: *Alan Bateman <Alan.Bateman at oracle.com>
*Date: *Wed, May 8, 2019 at 7:58 AM
*To: *Chris Hegarty, Arthur Eubanks, OpenJDK Network Dev list


>
> On 08/05/2019 12:51, Chris Hegarty wrote:
> >
> > While the vast majority of libnet.so is devoted to socket related
> > implementation, not all is. There are a small number of low-level pieces
> > of functionality that can be used with support for either IPv4 or IPv6
> > being present. The NIO implementation also uses some shared common
> > functionality from libnet.so. It seems overly restricting to disallow
> > libnet.so from loading if neither IPv4 or IPv6 are present.
> >
> I agree as an innocent reference to a type in java.net might resulting
> in libnet being loaded as a side effect. We also have the issue that the
> file system implementation is in libnio so libnet will be loaded there
> too (although shouldn't trigger its JNI OnLoad to be run).
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190508/97ded3e6/attachment.html>

From Alan.Bateman at oracle.com  Thu May  9 06:22:54 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 07:22:54 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
Message-ID: <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>

On 08/05/2019 12:02, Chris Hegarty wrote:
> :
>>
>> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
>
> :
>
> P.S. adding nio-dev since there are a few tests in that area
> being updated.
Thanks for forwarding.

IPSupports.skipIfConcurrentConfigurationIsInvalid is a bit strange and I 
think the first use of SkippedException in the jdk tests. I'm tempted to 
suggest this should be a key that tests should select on via the 
@requires tag but that may not be feasible because it depends on 
properties such as preferIPv4Stack. So I guess the approach is okay but 
we should rename the method to start with "skipTest" as it's not clear 
from the use-case what is being skipped. Also 
"ConcurrentConfigurationIsInvalid" is vague and I think it would be 
useful if the method description could emulate the conditions a bit 
better so that someone seeing a IPSupport.skipTestXXX knows what is means.

-Alan

From Alan.Bateman at oracle.com  Thu May  9 07:09:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 08:09:43 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
Message-ID: <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>

On 08/05/2019 18:24, Daniel Fuchs wrote:
> Hi,
>
> Please find below another patch in the series for intermittently
> failing tests:
>
> 8223573: Replace wildcard address with loopback or local host in
> ???????? tests - part 4
> https://bugs.openjdk.java.net/browse/JDK-8223573
>
> patch:
> http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.00/
I skimmed through the diffs and they look okay with me. Minor nit in 
6550798/test.java is there is a space in "HttpServer.create (". Also 
wonder if we should rename this source file too.

-Alan

From daniel.fuchs at oracle.com  Thu May  9 09:21:24 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 10:21:24 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
 <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
Message-ID: <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>

On 09/05/2019 08:09, Alan Bateman wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.00/
> I skimmed through the diffs and they look okay with me. Minor nit in 
> 6550798/test.java is there is a space in "HttpServer.create (". Also 
> wonder if we should rename this source file too.

Thanks Alan!

I'll grant you that the name of that test is not ideal.
But since it's not a new test I think I'll prefer to keep its original
name. I have removed the offending spaces - at several places
in that test.

Meanwhile I also found two other tests that needed updating:
test/jdk/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java
test/jdk/sun/net/www/http/ChunkedInputStream/TestAvailable.java

I've added them to the webrev:

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

best regards,

-- daniel

From chris.hegarty at oracle.com  Thu May  9 09:33:24 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 10:33:24 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
 <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
 <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
Message-ID: <2FB7950D-4071-4B65-B532-109876FB7989@oracle.com>

Daniel,

> On 9 May 2019, at 10:21, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> ...
> Meanwhile I also found two other tests that needed updating:
> test/jdk/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java
> test/jdk/sun/net/www/http/ChunkedInputStream/TestAvailable.java
> 
> I've added them to the webrev:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.01/

Looks good.

I?m missing why ChunkedEncodingWithProgressMonitorTest.java
needs `@library /test/lib` added?

-Chris.


From daniel.fuchs at oracle.com  Thu May  9 09:46:01 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 10:46:01 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <2FB7950D-4071-4B65-B532-109876FB7989@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
 <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
 <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
 <2FB7950D-4071-4B65-B532-109876FB7989@oracle.com>
Message-ID: <b79808b0-6588-36b9-5bd0-ca0ad47227fb@oracle.com>

Hi Chris,

On 09/05/2019 10:33, Chris Hegarty wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.01/
> Looks good.
> 
> I?m missing why ChunkedEncodingWithProgressMonitorTest.java
> needs `@library /test/lib` added?

It depends on ChunkedInputStream/ChunkedEncodingTest.java, creates
an instance of that class.

I missed that in the previous webrev so I checked out all the
tests in that same directory.

best regards,

-- daniel

From Alan.Bateman at oracle.com  Thu May  9 09:52:17 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 10:52:17 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
 <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
 <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
Message-ID: <c1da5914-f26c-8fdc-4805-9e6148e18547@oracle.com>

On 09/05/2019 10:21, Daniel Fuchs wrote:
> On 09/05/2019 08:09, Alan Bateman wrote:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8223573/webrev.00/
>> I skimmed through the diffs and they look okay with me. Minor nit in 
>> 6550798/test.java is there is a space in "HttpServer.create (". Also 
>> wonder if we should rename this source file too.
>
> Thanks Alan!
>
> I'll grant you that the name of that test is not ideal.
> But since it's not a new test I think I'll prefer to keep its original
> name. I have removed the offending spaces - at several places
> in that test.
Thanks, I see there is no more at L48 (you've removed one of them but 
there is a second).

In any case, the updated webrev looks good.

-Alan.

From daniel.fuchs at oracle.com  Thu May  9 10:05:31 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 11:05:31 +0100
Subject: [teststabilization] RFR: 8223573: Replace wildcard address with
 loopback or local host in tests - part 4
In-Reply-To: <c1da5914-f26c-8fdc-4805-9e6148e18547@oracle.com>
References: <868ab3d1-a27b-d434-f277-18a4924ec327@oracle.com>
 <14a50906-8116-469f-31f5-b80c99aa186f@oracle.com>
 <c083db46-8702-6f12-c1eb-ec874879c1ae@oracle.com>
 <c1da5914-f26c-8fdc-4805-9e6148e18547@oracle.com>
Message-ID: <1e524a8a-7fda-9ff7-7d81-e802af9e0848@oracle.com>

On 09/05/2019 10:52, Alan Bateman wrote:
> Thanks, I see there is no more at L48 (you've removed one of them but 
> there is a second).
> 
> In any case, the updated webrev looks good.

Argh! Thanks Alan - well spotted. I'll remove the offending
space before pushing.

best regards,

-- daniel


From michael.x.mcmahon at oracle.com  Thu May  9 10:51:55 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 09 May 2019 11:51:55 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com> <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
Message-ID: <5CD4064B.9060205@oracle.com>



On 07/05/2019, 17:14, Alan Bateman wrote:
> On 07/05/2019 16:44, Michael McMahon wrote:
>> Hi Alan,
>>
>> What's the purpose of the change to the UdpTest?
> The deprecated Socket constructors can be used to create a Socket that 
> uses UDP. This means the new SocketImpl has to support the creation of 
> UDP sockets and use the ResourceManager to enforce limits when running 
> with a  security manager.  So it's just increasing test coverage as I 
> wasn't able to find any tests in test/jdk that exercise it.
>
> -Alan
Ok, thanks. A test that might be useful could be one that compares the 
supported options between the old
and new impls for both client and server sockets. I guess it shouldn't 
be required for the initial push though.

- Michael.

From chris.hegarty at oracle.com  Thu May  9 11:02:08 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 12:02:08 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
 <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
Message-ID: <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>

Alan,

> On 9 May 2019, at 07:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/05/2019 12:02, Chris Hegarty wrote:
>> :
>>> 
>>> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
>> 
>> :
>> 
>> P.S. adding nio-dev since there are a few tests in that area
>> being updated.
> Thanks for forwarding.
> 
> IPSupports.skipIfConcurrentConfigurationIsInvalid is a bit strange and I think the first use of SkippedException in the jdk tests. I'm tempted to suggest this should be a key that tests should select on via the @requires tag but that may not be feasible because it depends on properties such as preferIPv4Stack.

The alternative of using `@requires` was considered and rejected, for
the same reason you mention [1]. Additionally, using SkippedException
will be more straight forward to detect skipped tests and the reason
( the IP configuration ) why the test was skipped.

> So I guess the approach is okay but we should rename the method to start with "skipTest" as it's not clear from the use-case what is being skipped. Also "ConcurrentConfigurationIsInvalid" is vague and I think it would be useful if the method description could emulate the conditions a bit better so that someone seeing a IPSupport.skipTestXXX knows what is means.

I agree that the method name could be improved. It?s really:

?skip test if cannot create a minimally-operational IPv4 or IPv6 socket"

Some concrete method name suggestions ( more welcome ):

  - IPSupport::skipTestIfNonOperational
  - IPSupport::skipTestIfCannotCreateAnyIPSockets
  

Suggested method-level documentation improvement:

  /**
   * Ensures that the platform supports the ability to create a
   * minimally-operational socket whose protocol is either one of IPv4
   * or IPv6.
   *
   * <p> A minimally-operation socket is one that can be created and
   * bound to an IP-specific loopback address. IP support is
   * considered non-operational if a socket cannot be bound to either
   * one of, an IPv4 loopback address, or the IPv6 loopback address.
   *
   * @throws SkippedException if the current networking configuration
   *         is non-operational
   */
  public static void skipTestIfNonOperational() throws SkippedException


-Chris.

P.S. 8220673 has been pushed already, but we should continue the
discussion here and I will create a follow-on JIRA issue to track it.

[1] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012348.html



From Alan.Bateman at oracle.com  Thu May  9 11:16:38 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 12:16:38 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <5CD4064B.9060205@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com> <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
 <5CD4064B.9060205@oracle.com>
Message-ID: <24cd3c15-ad4f-351e-2cfa-1b80bbc895b8@oracle.com>

On 09/05/2019 11:51, Michael McMahon wrote:
> Ok, thanks. A test that might be useful could be one that compares the 
> supported options between the old
> and new impls for both client and server sockets. I guess it shouldn't 
> be required for the initial push though.
>
There are several existing tests that will fail if there options missing 
but they might not catch the scenario where the new implementation 
supports additional option. I can add another test for that as it's easy.

-Alan


From Alan.Bateman at oracle.com  Thu May  9 11:20:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 12:20:18 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
 <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
 <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>
Message-ID: <3f1f5602-7c33-913c-9a7d-6d2df4513447@oracle.com>

On 09/05/2019 12:02, Chris Hegarty wrote:
> :
> I agree that the method name could be improved. It?s really:
>
> ?skip test if cannot create a minimally-operational IPv4 or IPv6 socket"
>
> Some concrete method name suggestions ( more welcome ):
>
>    - IPSupport::skipTestIfNonOperational
>    - IPSupport::skipTestIfCannotCreateAnyIPSockets
>    
>
throwSkippedExceptionIfXXX might work too. That might make it a bit more 
obvious in the tests.

-Alan

From macanaoire at hotmail.com  Thu May  9 11:33:15 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Thu, 9 May 2019 11:33:15 +0000
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
Message-ID: <DB6P192MB0200F608AE02567AABCA1B19DF330@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>

Hi Arthur et al.
    with these changes and the increased separation of IPv4 and IPv6 in the call flows, does
it make sense to preclude the retrieval of IPv6 interfaces, if there is an error in the IPv4 processing in the
enumInterfaces function ?  Or  that an  error retrieving IPv6 interfaces precludes returning IPv4 interfaces already retrieved?

Is it worth considering  the alternative to record the error and continue the attempt to retrieve IPv6 interfaces.
If that succeeds clear the exception and return the IPv6 interfaces, and vice verse. An error in the IPv6 retrieval will
preclude the return of the IPv4 interfaces already retrieved.

A potential cause of failure in opening a socket is FD exhaustion at the moment of invocation (e.g. a constrained environment with open files 64 !!)
which may have dissipated, if the call flow proceeds to retrieve the IPv6, while at the same time another thread has released an fd with file close or socket close.

If not  then it may be worth  considering that any Exception thrown should elaborate the cause a bit more -- indicating the root cause is either IPv4 or IPv6 based,  as per openSocketWithFallback.

has the semantics of the openSocketWithFallback now changed ?
was it not that an AF_INET6 socket creation was attempted if the AF_INET (IPv4) socket creation failed ?
the predicate was on EPROTONOSUPPORT rather than EAFNOSUPPORT which is encaspulated in ipv4_available()
Now it's if ipv4 not available then try ipv6.
I know Chris made the point about treating them the same ... maybe so.
But at a pedantic level, the function is creating datagram socke heret, while IPv4_supported created a stream socket!!

anyway main point -- should a failure to retrieve IPv4 interfaces preclude IPv6 interface retrieval and vice verse.


regards
Mark


________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Arthur Eubanks <aeubanks at google.com>
Sent: Wednesday 8 May 2019 17:33
To: Alan Bateman
Cc: OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

Reverted changes in net_util.c.
Also, webrev.00 would create an IPv6 socket even if creating the IPv4 socket was successful. Fixed. (My very first revision had this same issue, which I thought I had fixed before sending it out. Tricky if statements have been cleaned up to make this less likely to happen again in the future.)

http://cr.openjdk.java.net/~aeubanks/8223532/webrev.01/

From: Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>
Date: Wed, May 8, 2019 at 7:58 AM
To: Chris Hegarty, Arthur Eubanks, OpenJDK Network Dev list



On 08/05/2019 12:51, Chris Hegarty wrote:
>
> While the vast majority of libnet.so is devoted to socket related
> implementation, not all is. There are a small number of low-level pieces
> of functionality that can be used with support for either IPv4 or IPv6
> being present. The NIO implementation also uses some shared common
> functionality from libnet.so. It seems overly restricting to disallow
> libnet.so from loading if neither IPv4 or IPv6 are present.
>
I agree as an innocent reference to a type in java.net<http://java.net> might resulting
in libnet being loaded as a side effect. We also have the issue that the
file system implementation is in libnio so libnet will be loaded there
too (although shouldn't trigger its JNI OnLoad to be run).

-Alan

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

From Alan.Bateman at oracle.com  Thu May  9 13:00:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 14:00:18 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
Message-ID: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>

Thanks Chris and Michael for the reviews/help so far. I've uploaded a 
new webrev to address most of their points here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html

and delta webrev with the changes from 1 to 2 here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html

-Alan

From chris.hegarty at oracle.com  Thu May  9 13:24:26 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 14:24:26 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
 <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
Message-ID: <39747523-B6D1-42FD-891C-CDBE3F17117A@oracle.com>

Alan,

> On 9 May 2019, at 14:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> Thanks Chris and Michael for the reviews/help so far. I've uploaded a new webrev to address most of their points here:
>    http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html
> 
> and delta webrev with the changes from 1 to 2 here:
>    http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html


This addresses my comments / concerns. Reviewed.

-Chris.

P.S. Thanks for generating the delta-webrev.

From michael.x.mcmahon at oracle.com  Thu May  9 13:24:38 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 09 May 2019 14:24:38 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
 <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
Message-ID: <5CD42A16.6060909@oracle.com>

Looks good to me. I don't have anything else to add at this point. I 
agree the new implementation is much clearer
than the old and it will be great to see it working in the field.

Thanks,

Michael

On 09/05/2019, 14:00, Alan Bateman wrote:
> Thanks Chris and Michael for the reviews/help so far. I've uploaded a 
> new webrev to address most of their points here:
>    http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html
>
> and delta webrev with the changes from 1 to 2 here:
>    http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html
>
> -Alan

From daniel.fuchs at oracle.com  Thu May  9 15:23:31 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 16:23:31 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>

Hi Christoph,

I'm only commenting on the HttpClient changes, I'll let
others comment on the other changes...

http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html

I have a profound dislike for using @SuppressedWarnings, unless
it's the only alternative. My preference would be to introduce
local variables, if that can make the compiler happy, until such time
where the issue is actually resolved...

For instance, it seems that the following would work:

     // Use local variable assignments to keep other java compilers
     // happy and avoid unchecked casts warnings
     BiFunction<Http2Connection, Throwable, CompletableFuture<? extends 
ExchangeImpl<U>>>
         factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection);
     Function<CompletableFuture<? extends ExchangeImpl<U>>, 
CompletableFuture<? extends ExchangeImpl<U>>>
         identity = (cf) -> cf;
     return c2f.handle(factory).thenCompose(identity);


best regards,

-- daniel

On 08/05/2019 09:02, Langer, Christoph wrote:
> Hi,
> 
> please review a small change that I?d like to see in OpenJDK to get rid 
> of compilation errors in the Eclipse IDE.
> 
> It seems the root cause for the compilation errors is that javac would 
> sometimes widen capture variables and is hence able to compile the 
> places that I touch here. The EC4J compiler claims that it?s following 
> the spec more strictly and bails out at these places. I had posted about 
> this on compiler-dev but got no reaction [0].
> 
> So, as this seems to be some field of open work for the compiler/spec 
> folks, I?d like to get EC4J quiesced by introducing some slight 
> modifications to the original places which makes the code appeal a bit 
> less elegant and fluent but will get rid of the compile errors.
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> 
> The modification to 
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
> belongs to JSR-166, so I don?t know if it needs some special handling.
> 
> Thanks & Best regards
> 
> Christoph
> 
> [0] 
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html
> 


From chris.hegarty at oracle.com  Thu May  9 16:24:03 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 17:24:03 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
Message-ID: <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>

Arthur,

> On 8 May 2019, at 18:33, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Reverted changes in net_util.c.
> Also, webrev.00 would create an IPv6 socket even if creating the IPv4 socket was successful. Fixed. (My very first revision had this same issue, which I thought I had fixed before sending it out. Tricky if statements have been cleaned up to make this less likely to happen again in the future.)
> 
> http://cr.openjdk.java.net/~aeubanks/8223532/webrev.01/

The following is Solaris specific code:

1630                 sock = socket(AF_INET6, SOCK_DGRAM, 0)

It is missing a trailing semi-colon, so does not compile on Solaris.

Also the else block where this code exists should probably be:
 
   else if (ipv6_available()) {

   , since it creates an AF_NET6 socket.

I?ll run some tests.

-Chris.

From aeubanks at google.com  Thu May  9 17:40:14 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 9 May 2019 10:40:14 -0700
Subject: [RFR]: 8223652: Rename IPSupport.skipIfCurrentConfigurationIsInvalid()
Message-ID: <CAPW48sq1gbeuAd-61piZyiYPtYMhKSUJyWYq4VvghbWqgWhxaw@mail.gmail.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8223652
Webrev: http://cr.openjdk.java.net/~aeubanks/8223652/webrev.00/index.html

As mentioned in
https://markmail.org/search/?q=aeubanks%40google.com#query:aeubanks%40google.com+page:1+mid:rjthqgdeghv6vyck+state:results,
IPSupport.skipIfCurrentConfigurationIsInvalid() is ambiguous (how is it
skipping the test? what is a configuration?)

Something like IPSupport.throwSkippedExceptionIfNonOperational() is
probably better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190509/a0d37ec7/attachment-0001.html>

From daniel.fuchs at oracle.com  Thu May  9 17:52:00 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 18:52:00 +0100
Subject: [RFR]: 8223652: Rename
 IPSupport.skipIfCurrentConfigurationIsInvalid()
In-Reply-To: <CAPW48sq1gbeuAd-61piZyiYPtYMhKSUJyWYq4VvghbWqgWhxaw@mail.gmail.com>
References: <CAPW48sq1gbeuAd-61piZyiYPtYMhKSUJyWYq4VvghbWqgWhxaw@mail.gmail.com>
Message-ID: <db68c309-9808-97f1-b99b-c9bf7314a745@oracle.com>

Hi Arthur,

Looks good to me.

best regards,

-- daniel

On 09/05/2019 18:40, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223652
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223652/webrev.00/index.html
> 
> As mentioned in 
> https://markmail.org/search/?q=aeubanks%40google.com#query:aeubanks%40google.com+page:1+mid:rjthqgdeghv6vyck+state:results, 
> IPSupport.skipIfCurrentConfigurationIsInvalid() is ambiguous (how is it 
> skipping the test? what is a configuration?)
> 
> Something like IPSupport.throwSkippedExceptionIfNonOperational() is 
> probably better.


From aleksej.efimov at oracle.com  Thu May  9 18:42:15 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 9 May 2019 19:42:15 +0100
Subject: [teststabilization] RFR: 8223465: Replace wildcard address with
 loopback or local host in tests - part 3
Message-ID: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>

Hi,

Please help to review another part of test fixes to address intermittent 
failures.

Webrev:
http://cr.openjdk.java.net/~aefimov/8223465/00/

JBS:
https://bugs.openjdk.java.net/browse/JDK-8223465

With Best Regards,
Aleksei

From aeubanks at google.com  Thu May  9 20:03:41 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 9 May 2019 13:03:41 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <DB6P192MB0200F608AE02567AABCA1B19DF330@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <DB6P192MB0200F608AE02567AABCA1B19DF330@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <CAPW48so3k4TjuFBf8Az6X0RnvvTpAU5Ea1z8oM75ipRLK9EGmQ@mail.gmail.com>

*From: *mark sheppard <macanaoire at hotmail.com>
*Date: *Thu, May 9, 2019 at 4:33 AM
*To: *Arthur Eubanks, Alan Bateman
*Cc: *OpenJDK Network Dev list

Hi Arthur et al.
>     with these changes and the increased separation of IPv4 and IPv6 in
> the call flows, does
> it make sense to preclude the retrieval of IPv6 interfaces, if there is an
> error in the IPv4 processing in the
> enumInterfaces function ?  Or  that an  error retrieving IPv6
> interfaces precludes returning IPv4 interfaces already retrieved?
>

> Is it worth considering  the alternative to record the error and continue
> the attempt to retrieve IPv6 interfaces.
> If that succeeds clear the exception and return the IPv6 interfaces, and
> vice verse. An error in the IPv6 retrieval will
> preclude the return of the IPv4 interfaces already retrieved.
>
I think that makes sense. There is a comment
// return partial list if an exception occurs in the middle of process ???
which hints toward doing that. But I think this can be a future change if
somebody thinks it's worth doing.

>
> A potential cause of failure in opening a socket is FD exhaustion at the
> moment of invocation (e.g. a constrained environment with open files 64 !!)
> which may have dissipated, if the call flow proceeds to retrieve the IPv6,
> while at the same time another thread has released an fd with file close or
> socket close.
>
I'm not sure that this is a big enough concern, but maybe others want to
comment on this.

>
> If not  then it may be worth  considering that any Exception thrown
> should elaborate the cause a bit more -- indicating the root cause is
> either IPv4 or IPv6 based,  as per openSocketWithFallback.
>
Good idea. With your comment I realized we don't need openSocket(), so I've
inlined it and made the socket creation exception more explicit as to
whether IPv4 or IPv6 socket creation failed.

>
> has the semantics of the openSocketWithFallback now changed ?
> was it not that an AF_INET6 socket creation was attempted if the AF_INET
> (IPv4) socket creation failed ?
> the predicate was on EPROTONOSUPPORT rather than EAFNOSUPPORT which is
> encaspulated in ipv4_available()
> Now it's if ipv4 not available then try ipv6.
> I know Chris made the point about treating them the same ... maybe so.
> But at a pedantic level, the function is creating datagram socke heret,
> while IPv4_supported created a stream socket!!
>
Good catch. We still have the same problem with IPv6 version. Right now
ipv6_available() returns true if a stream socket, yet we still use it for
determining if we can create an IPv6 datagram socket.
I think it's good to converge the two as this change does. If anybody runs
in an environment where a stream socket can be created but not a datagram
socket (or vice versa), we may need more granularity for determining what
kinds of sockets are available.

>
> anyway main point -- should a failure to retrieve IPv4 interfaces preclude
> IPv6 interface retrieval and vice verse.
>
>
> regards
> Mark
>

New webrev:
 http://cr.openjdk.java.net/~aeubanks/8223532/webrev.02/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190509/145b9699/attachment.html>

From aeubanks at google.com  Thu May  9 20:05:21 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 9 May 2019 13:05:21 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
Message-ID: <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Thu, May 9, 2019 at 9:24 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list

Arthur,
>
> > On 8 May 2019, at 18:33, Arthur Eubanks <aeubanks at google.com> wrote:
> >
> > Reverted changes in net_util.c.
> > Also, webrev.00 would create an IPv6 socket even if creating the IPv4
> socket was successful. Fixed. (My very first revision had this same issue,
> which I thought I had fixed before sending it out. Tricky if statements
> have been cleaned up to make this less likely to happen again in the
> future.)
> >
> > http://cr.openjdk.java.net/~aeubanks/8223532/webrev.01/
>
> The following is Solaris specific code:
>
> 1630                 sock = socket(AF_INET6, SOCK_DGRAM, 0)
>
> It is missing a trailing semi-colon, so does not compile on Solaris.
>
> Also the else block where this code exists should probably be:
>
>    else if (ipv6_available()) {
>
>    , since it creates an AF_NET6 socket.
>
Fixed

>
> I?ll run some tests.
>
Thanks

>
> -Chris.


New webrev:
 http://cr.openjdk.java.net/~aeubanks/8223532/webrev.02/index.html
This also contains some changes from Mark's suggestions. That thread
appears to have been separated from this thread in my inbox for some reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190509/170d841b/attachment-0001.html>

From christoph.langer at sap.com  Fri May 10 09:17:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 10 May 2019 09:17:29 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
Message-ID: <AM6PR02MB5192FEC67CFDBA7821A0448E8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

I fully agree, @SuppressWarnings should be avoided wherever possible.

So, thanks for coming up with this alternative suggestion. It works and so I updated my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/  

Any reviews for the other 3 files?

Thanks
Christoph

> -----Original Message-----
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Donnerstag, 9. Mai 2019 17:24
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm only commenting on the HttpClient changes, I'll let
> others comment on the other changes...
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s
> hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html
> 
> I have a profound dislike for using @SuppressedWarnings, unless
> it's the only alternative. My preference would be to introduce
> local variables, if that can make the compiler happy, until such time
> where the issue is actually resolved...
> 
> For instance, it seems that the following would work:
> 
>      // Use local variable assignments to keep other java compilers
>      // happy and avoid unchecked casts warnings
>      BiFunction<Http2Connection, Throwable, CompletableFuture<? extends
> ExchangeImpl<U>>>
>          factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection);
>      Function<CompletableFuture<? extends ExchangeImpl<U>>,
> CompletableFuture<? extends ExchangeImpl<U>>>
>          identity = (cf) -> cf;
>      return c2f.handle(factory).thenCompose(identity);
> 
> 
> best regards,
> 
> -- daniel
> 
> On 08/05/2019 09:02, Langer, Christoph wrote:
> > Hi,
> >
> > please review a small change that I'd like to see in OpenJDK to get rid
> > of compilation errors in the Eclipse IDE.
> >
> > It seems the root cause for the compilation errors is that javac would
> > sometimes widen capture variables and is hence able to compile the
> > places that I touch here. The EC4J compiler claims that it's following
> > the spec more strictly and bails out at these places. I had posted about
> > this on compiler-dev but got no reaction [0].
> >
> > So, as this seems to be some field of open work for the compiler/spec
> > folks, I'd like to get EC4J quiesced by introducing some slight
> > modifications to the original places which makes the code appeal a bit
> > less elegant and fluent but will get rid of the compile errors.
> >
> > Please review:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> >
> > The modification to
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> > belongs to JSR-166, so I don't know if it needs some special handling.
> >
> > Thanks & Best regards
> >
> > Christoph
> >
> > [0]
> > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-
> March/013054.html
> >


From chris.hegarty at oracle.com  Fri May 10 09:46:39 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 10 May 2019 10:46:39 +0100
Subject: [RFR]: 8223652: Rename
 IPSupport.skipIfCurrentConfigurationIsInvalid()
In-Reply-To: <db68c309-9808-97f1-b99b-c9bf7314a745@oracle.com>
References: <CAPW48sq1gbeuAd-61piZyiYPtYMhKSUJyWYq4VvghbWqgWhxaw@mail.gmail.com>
 <db68c309-9808-97f1-b99b-c9bf7314a745@oracle.com>
Message-ID: <f80cb801-7107-6410-bf9c-9083de425192@oracle.com>

+1

-Chris

On 09/05/2019 18:52, Daniel Fuchs wrote:
> Hi Arthur,
> 
> Looks good to me.
> 
> best regards,
> 
> -- daniel
> 
> On 09/05/2019 18:40, Arthur Eubanks wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223652
>> Webrev: http://cr.openjdk.java.net/~aeubanks/8223652/webrev.00/index.html
>>
>> As mentioned in 
>> https://markmail.org/search/?q=aeubanks%40google.com#query:aeubanks%40google.com+page:1+mid:rjthqgdeghv6vyck+state:results, 
>> IPSupport.skipIfCurrentConfigurationIsInvalid() is ambiguous (how is 
>> it skipping the test? what is a configuration?)
>>
>> Something like IPSupport.throwSkippedExceptionIfNonOperational() is 
>> probably better.
> 

From daniel.fuchs at oracle.com  Fri May 10 10:19:11 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 10 May 2019 11:19:11 +0100
Subject: [teststabilization] RFR: 8223465: Replace wildcard address with
 loopback or local host in tests - part 3
In-Reply-To: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>
References: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>
Message-ID: <9679a9c4-1339-e657-35f9-f57838e1a903@oracle.com>

Hi Aleksei,

ServerSocket_accept.java:

I think the new logic deserve a comment before line 63.
Something like:

// if readyToClose is still false it means some other
// process on the system attempted to connect: just
// ignore it, and go back to accept again.

SocksV4Test.java:

can you remove the extraneous space at line 59, and add the missing
space after '(0,' at line 60?

ChunkedErrorStream.java:

missing space at line 153.  This test now uses the external
address instead of using the loopback but I guess that's OK.

Otherwise looks good!

best regards,

-- daniel

On 09/05/2019 19:42, Aleks Efimov wrote:
> Hi,
> 
> Please help to review another part of test fixes to address intermittent 
> failures.
> 
> Webrev:
> http://cr.openjdk.java.net/~aefimov/8223465/00/
> 
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8223465
> 
> With Best Regards,
> Aleksei


From chris.hegarty at oracle.com  Fri May 10 10:56:27 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 10 May 2019 11:56:27 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
Message-ID: <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>

Arthur,

On 09/05/2019 21:05, Arthur Eubanks wrote:
> 
> ...
> New webrev:
> http://cr.openjdk.java.net/~aeubanks/8223532/webrev.02/index.html
> This also contains some changes from Mark's suggestions. That thread 
> appears to have been separated from this thread in my inbox for some reason.

Curve ball! Sorry.

There is much history in this native code, and how ipv6_available
evolved ( it is far from perfect! ). The use of ipv4_available ( as
Mark mentions ) is not quite a good fit here (SOCK_STREAM Vs.
SOCK_DGRAM).

After further thought, I have now convinced myself that, from the
perspective of the JDK's usage ( at least in NetworkInterface ), that
it would be better to effectively treat EPROTONOSUPPORT and EAFNOSUPPORT
the same, as "the specified protocol, domain, type, address family, is
not supported". This should not be controversial given the constant
values that are passed to socket(2).

Given this, then the changes can be minimal, direct, and localized.
Effectively:

   -      if (errno != EPROTONOSUPPORT) {
   ---
   +      if (!(errno == EAFNOSUPPORT || errno == EPROTONOSUPPORT)) {

And in enumInterfaces, something like:

     /* Enumerate IPv4 addresses */
     sock = openSocket(env, AF_INET);
     if (sock < 0 && (*env)->ExceptionOccurred(env)) {
         return NULL;
     }

     if (sock >= 0) {
         ifs = enumIPv4Interfaces(env, sock, NULL);
         close(sock);

         if ((*env)->ExceptionOccurred(env)) {
             freeif(ifs);
             return NULL;
         }
     }
     ...

         if (ipv6_available()) {
            sock = openSocket(env, AF_INET6);
            if (sock < 0 && (*env)->ExceptionOccurred(env)) {
                freeif(ifs);
                return NULL;
            }

            if (sock >= 0) {
                ifs = enumIPv6Interfaces(env, sock, ifs);
                close(sock);

                if ((*env)->ExceptionOccurred(env)) {
                    freeif(ifs);
                    return NULL;
                }
            }
        }
---

Let's keep this JIRA issue focused on the task in-hand ( ip6-only
support ). Other technical debt and behavioural issues ( beyond the most
trivial ) can be addressed separately.

-Chris.

From aleksej.efimov at oracle.com  Fri May 10 12:24:17 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 10 May 2019 13:24:17 +0100
Subject: [teststabilization] RFR: 8223465: Replace wildcard address with
 loopback or local host in tests - part 3
In-Reply-To: <9679a9c4-1339-e657-35f9-f57838e1a903@oracle.com>
References: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>
 <9679a9c4-1339-e657-35f9-f57838e1a903@oracle.com>
Message-ID: <fae5203a-435e-b9b6-0292-8d4ac7c74a83@oracle.com>

Thank you for the review Daniel!

I've added the suggested comment to ServerSocket_accept + fixed the 
white-spaces.

About ChunkedErrorStream.java: Thank you for spotting the change - I 
will keep the original logic of the test to use loopback instead of 
localhost.

All these changes can be found in the second version of webrev:
http://cr.openjdk.java.net/~aefimov/8223465/01/

With Best Regards,
Aleksei

On 10/05/2019 11:19, Daniel Fuchs wrote:
> Hi Aleksei,
>
> ServerSocket_accept.java:
>
> I think the new logic deserve a comment before line 63.
> Something like:
>
> // if readyToClose is still false it means some other
> // process on the system attempted to connect: just
> // ignore it, and go back to accept again.
>
> SocksV4Test.java:
>
> can you remove the extraneous space at line 59, and add the missing
> space after '(0,' at line 60?
>
> ChunkedErrorStream.java:
>
> missing space at line 153.? This test now uses the external
> address instead of using the loopback but I guess that's OK.
>
> Otherwise looks good!
>
> best regards,
>
> -- daniel
>
> On 09/05/2019 19:42, Aleks Efimov wrote:
>> Hi,
>>
>> Please help to review another part of test fixes to address 
>> intermittent failures.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~aefimov/8223465/00/
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8223465
>>
>> With Best Regards,
>> Aleksei
>


From daniel.fuchs at oracle.com  Fri May 10 13:16:52 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 10 May 2019 14:16:52 +0100
Subject: [teststabilization] RFR: 8223465: Replace wildcard address with
 loopback or local host in tests - part 3
In-Reply-To: <fae5203a-435e-b9b6-0292-8d4ac7c74a83@oracle.com>
References: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>
 <9679a9c4-1339-e657-35f9-f57838e1a903@oracle.com>
 <fae5203a-435e-b9b6-0292-8d4ac7c74a83@oracle.com>
Message-ID: <b1e91874-7253-7051-d667-30447c974dd8@oracle.com>

Looks god to me!

cheers,

-- daniel

On 10/05/2019 13:24, Aleks Efimov wrote:
> Thank you for the review Daniel!
> 
> I've added the suggested comment to ServerSocket_accept + fixed the 
> white-spaces.
> 
> About ChunkedErrorStream.java: Thank you for spotting the change - I 
> will keep the original logic of the test to use loopback instead of 
> localhost.
> 
> All these changes can be found in the second version of webrev:
> http://cr.openjdk.java.net/~aefimov/8223465/01/
> 
> With Best Regards,
> Aleksei

From aleksej.efimov at oracle.com  Fri May 10 13:44:58 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 10 May 2019 14:44:58 +0100
Subject: [teststabilization] RFR: 8223465: Replace wildcard address with
 loopback or local host in tests - part 3
In-Reply-To: <b1e91874-7253-7051-d667-30447c974dd8@oracle.com>
References: <504a6d48-d4e2-6391-25f8-9550cddea8cc@oracle.com>
 <9679a9c4-1339-e657-35f9-f57838e1a903@oracle.com>
 <fae5203a-435e-b9b6-0292-8d4ac7c74a83@oracle.com>
 <b1e91874-7253-7051-d667-30447c974dd8@oracle.com>
Message-ID: <4d49368e-da5c-582c-5b33-ac6a638f0c4e@oracle.com>

Thank you Daniel!


On 10/05/2019 14:16, Daniel Fuchs wrote:
> Looks god to me!
>
> cheers,
>
> -- daniel
>
> On 10/05/2019 13:24, Aleks Efimov wrote:
>> Thank you for the review Daniel!
>>
>> I've added the suggested comment to ServerSocket_accept + fixed the 
>> white-spaces.
>>
>> About ChunkedErrorStream.java: Thank you for spotting the change - I 
>> will keep the original logic of the test to use loopback instead of 
>> localhost.
>>
>> All these changes can be found in the second version of webrev:
>> http://cr.openjdk.java.net/~aefimov/8223465/01/
>>
>> With Best Regards,
>> Aleksei


From aeubanks at google.com  Fri May 10 16:37:50 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 10 May 2019 09:37:50 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
Message-ID: <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>

Sounds good.
New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/

This is almost exactly the changes we made internally to this file.

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Fri, May 10, 2019 at 3:56 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list

Arthur,
>
> On 09/05/2019 21:05, Arthur Eubanks wrote:
> >
> > ...
> > New webrev:
> > http://cr.openjdk.java.net/~aeubanks/8223532/webrev.02/index.html
> > This also contains some changes from Mark's suggestions. That thread
> > appears to have been separated from this thread in my inbox for some
> reason.
>
> Curve ball! Sorry.
>
> There is much history in this native code, and how ipv6_available
> evolved ( it is far from perfect! ). The use of ipv4_available ( as
> Mark mentions ) is not quite a good fit here (SOCK_STREAM Vs.
> SOCK_DGRAM).
>
> After further thought, I have now convinced myself that, from the
> perspective of the JDK's usage ( at least in NetworkInterface ), that
> it would be better to effectively treat EPROTONOSUPPORT and EAFNOSUPPORT
> the same, as "the specified protocol, domain, type, address family, is
> not supported". This should not be controversial given the constant
> values that are passed to socket(2).
>
> Given this, then the changes can be minimal, direct, and localized.
> Effectively:
>
>    -      if (errno != EPROTONOSUPPORT) {
>    ---
>    +      if (!(errno == EAFNOSUPPORT || errno == EPROTONOSUPPORT)) {
>
> And in enumInterfaces, something like:
>
>      /* Enumerate IPv4 addresses */
>      sock = openSocket(env, AF_INET);
>      if (sock < 0 && (*env)->ExceptionOccurred(env)) {
>          return NULL;
>      }
>
>      if (sock >= 0) {
>          ifs = enumIPv4Interfaces(env, sock, NULL);
>          close(sock);
>
>          if ((*env)->ExceptionOccurred(env)) {
>              freeif(ifs);
>              return NULL;
>          }
>      }
>      ...
>
>          if (ipv6_available()) {
>             sock = openSocket(env, AF_INET6);
>             if (sock < 0 && (*env)->ExceptionOccurred(env)) {
>                 freeif(ifs);
>                 return NULL;
>             }
>
>             if (sock >= 0) {
>                 ifs = enumIPv6Interfaces(env, sock, ifs);
>                 close(sock);
>
>                 if ((*env)->ExceptionOccurred(env)) {
>                     freeif(ifs);
>                     return NULL;
>                 }
>             }
>         }
> ---
>
> Let's keep this JIRA issue focused on the task in-hand ( ip6-only
> support ). Other technical debt and behavioural issues ( beyond the most
> trivial ) can be addressed separately.
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190510/69d7c717/attachment.html>

From aeubanks at google.com  Sat May 11 00:17:41 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 10 May 2019 17:17:41 -0700
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal
 addresses correctly
Message-ID: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8223737
Webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html

HostsFileNameService doesn't handle IPv6 literal addresses correctly.
For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.

Rather than comparing address strings, compare the address byte arrays.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190510/324358fa/attachment-0001.html>

From chris.hegarty at oracle.com  Sat May 11 10:39:42 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 11 May 2019 11:39:42 +0100
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
 <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
Message-ID: <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com>



> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote:
> 
> Hi guys,
> 
> We need a couple of partial reviews for this enhancement:
> 
>  - From the net-dev to check IPv6-addresses related part.
>    It does not need to be a thorough review.
>    We need another pair of eyes to check for obvious typos or misses.
>    Included Chris H. to mailing list in hope for some assistance.
>    (Chris, we need some help to find one of the IPv6 experts.)
> 
>  - From the serviceability-dev to check if compatibility
>    is not broken and nothing is missed.
>    This includes part of code that is not directly involved
>    into manipulations with the IPv4/IPv6 addresses.
>    The related spec update is tracked by a sub-task:
>      https://bugs.openjdk.java.net/browse/JDK-8221707
> 
> 
> Related CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8223104 
> 
> The latest webrev: 
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/


src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c

   223     if (domain == AF_INET6) {
   224         int off = 0;
   225         // make the socket a dual mode socket
   226         setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&off, sizeof(off));
   227     }
   228   }

  This code is fine, but maybe you want to expand the comment to
  mention that the setsockopt may fail if IPv4 is not supported. And
  that?s OK.

  I cannot find a similar setting of IPV6_V6ONLY for the unix 
  equivalent. Why not, or where can it be found?

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c

  There is a lot of native code here, I skimmed over it, seems
  reasonable. There is an obvious lack of any reference to IPv6
  scopes. Can the address given to bind be an IPv6 link-local?
  If so, then the scope will need to be parsed / set appropriately.
  ( seems that the new test skips all scoped addresses? )

-Chris.


From chris.hegarty at oracle.com  Sat May 11 10:48:00 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 11 May 2019 11:48:00 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
Message-ID: <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>

Arthur,

> On 10 May 2019, at 17:37, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Sounds good.
> New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/ <http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/>
> 
> This is almost exactly the changes we made internally to this file.

Good that we eventually converged on the same substantive solution.
Bad that we went in a little circle first ( though it does give an 
additional level of confidence that we ended up in a similar place).

I think that this latest webrev looks good. I?ll do some testing with
it and report back the results.

BTW I? m happy to drop this TODO-like comment from the code.
     // return partial list if an exception occurs in the middle of process ???
I disagree with returning a partial list. I think it just hides potential bugs.     

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

From christoph.langer at sap.com  Mon May 13 07:29:28 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 May 2019 07:29:28 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

unfortunately, your proposed solution does not work with javac. I get this in the build:

...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture<T> cannot be applied to given types;
            return c2f.handle(factory).thenCompose(identity);
                                      ^
  required: Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>
  found:    Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>>
  reason: cannot infer type-variable(s) U#2
    (argument mismatch; Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>> cannot be converted to Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>)
  where U#1,U#2,T are type-variables:
    U#1 extends Object declared in method <U#1>get(Exchange<U#1>,HttpConnection)
    U#2 extends Object declared in method <U#2>thenCompose(Function<? super T,? extends CompletionStage<U#2>>)
    T extends Object declared in class CompletableFuture
1 error

So I think we need to go back to my initial proposal which works for both, IDE and javac: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ 

Thanks
Christoph


> -----Original Message-----
> From: Langer, Christoph
> Sent: Freitag, 10. Mai 2019 11:17
> To: Daniel Fuchs <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: RE: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Daniel,
> 
> I fully agree, @SuppressWarnings should be avoided wherever possible.
> 
> So, thanks for coming up with this alternative suggestion. It works and so I
> updated my webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/
> 
> Any reviews for the other 3 files?
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: Daniel Fuchs <daniel.fuchs at oracle.com>
> > Sent: Donnerstag, 9. Mai 2019 17:24
> > To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-
> libs-
> > dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> > Cc: compiler-dev at openjdk.java.net
> > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> > Eclipse Java Compiler
> >
> > Hi Christoph,
> >
> > I'm only commenting on the HttpClient changes, I'll let
> > others comment on the other changes...
> >
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s
> > hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html
> >
> > I have a profound dislike for using @SuppressedWarnings, unless
> > it's the only alternative. My preference would be to introduce
> > local variables, if that can make the compiler happy, until such time
> > where the issue is actually resolved...
> >
> > For instance, it seems that the following would work:
> >
> >      // Use local variable assignments to keep other java compilers
> >      // happy and avoid unchecked casts warnings
> >      BiFunction<Http2Connection, Throwable, CompletableFuture<? extends
> > ExchangeImpl<U>>>
> >          factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange,
> > connection);
> >      Function<CompletableFuture<? extends ExchangeImpl<U>>,
> > CompletableFuture<? extends ExchangeImpl<U>>>
> >          identity = (cf) -> cf;
> >      return c2f.handle(factory).thenCompose(identity);
> >
> >
> > best regards,
> >
> > -- daniel
> >
> > On 08/05/2019 09:02, Langer, Christoph wrote:
> > > Hi,
> > >
> > > please review a small change that I'd like to see in OpenJDK to get rid
> > > of compilation errors in the Eclipse IDE.
> > >
> > > It seems the root cause for the compilation errors is that javac would
> > > sometimes widen capture variables and is hence able to compile the
> > > places that I touch here. The EC4J compiler claims that it's following
> > > the spec more strictly and bails out at these places. I had posted about
> > > this on compiler-dev but got no reaction [0].
> > >
> > > So, as this seems to be some field of open work for the compiler/spec
> > > folks, I'd like to get EC4J quiesced by introducing some slight
> > > modifications to the original places which makes the code appeal a bit
> > > less elegant and fluent but will get rid of the compile errors.
> > >
> > > Please review:
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> > >
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> > >
> > > The modification to
> > >
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> > a
> > > belongs to JSR-166, so I don't know if it needs some special handling.
> > >
> > > Thanks & Best regards
> > >
> > > Christoph
> > >
> > > [0]
> > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-
> > March/013054.html
> > >


From daniel.fuchs at oracle.com  Mon May 13 09:34:02 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 May 2019 10:34:02 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>

Hi Christoph,

On 13/05/2019 08:29, Langer, Christoph wrote:
> Hi Daniel,
> 
> unfortunately, your proposed solution does not work with javac. I get this in the build:

Oh darn. I should have double checked.
Can we at least reduce the scope of the @SuppressedWarnings by
introducing a private method that just has the return call?

best regards,

-- daniel


> 
> ...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture<T> cannot be applied to given types;
>              return c2f.handle(factory).thenCompose(identity);
>                                        ^
>    required: Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>
>    found:    Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>>
>    reason: cannot infer type-variable(s) U#2
>      (argument mismatch; Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>> cannot be converted to Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>)
>    where U#1,U#2,T are type-variables:
>      U#1 extends Object declared in method <U#1>get(Exchange<U#1>,HttpConnection)
>      U#2 extends Object declared in method <U#2>thenCompose(Function<? super T,? extends CompletionStage<U#2>>)
>      T extends Object declared in class CompletableFuture
> 1 error
> 
> So I think we need to go back to my initial proposal which works for both, IDE and javac:http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/  
> 
> Thanks
> Christoph


From daniel.fuchs at oracle.com  Mon May 13 13:58:36 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 May 2019 14:58:36 +0100
Subject: [teststabilization] RFR: 8223632: Replace wildcard address with
 loopback or local host in tests - part 5
Message-ID: <3bfcb6b8-9026-04d4-0be8-b5c8198a7e84@oracle.com>

Hi,

Please find below a fix for a bunch of tests that
have been observed to fail intermittently.

The usual trick (replacing wildcard with localhost) was applied.
In some cases, the logic of the test meant that the trick could
be applied only partially (e.g. it could be applied to the proxy,
but not to the server), or even could not be applied.

In that case the `@key intermittent` keyword has been added with
a comment explaining the reason for such intermittent failure.

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

JBS: https://bugs.openjdk.java.net/browse/JDK-8223632

best regards,

-- daniel

From aleksej.efimov at oracle.com  Mon May 13 15:07:58 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 13 May 2019 16:07:58 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
Message-ID: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>

Hi,

Please help to review another part of test fixes to address 
intermittent? networking test failures.

Webrev:
http://cr.openjdk.java.net/~aefimov/8223638/00/index.html

JBS:
https://bugs.openjdk.java.net/browse/JDK-8223638

With Best Regards,
Aleksei


From daniel.fuchs at oracle.com  Mon May 13 15:45:03 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 May 2019 16:45:03 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
In-Reply-To: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
References: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
Message-ID: <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>

Hi Aleksei,

I believe that some configurations in the wild might
return you the external host address when looking up
"localhost". It doesn't matter if the server binds to
the wildcard, but if you change the server to stop using
the wildcard, then you also need to change the client to
use the same address that the server binds too.

AcceptCauseFileDescriptorLeak.java:

I believe line
   97                         (new Socket("localhost", 
ss.getLocalPort())).close();

should be changed to use the loopback address.


UnreferencedSockets.java:

same remark as above:

  130         Socket s = new Socket("localhost", svr.localPort());

PerConnectionProxy.java:

same remark as above:

   97                 InetSocketAddress isa = 
InetSocketAddress.createUnresolved("localhost", pserver.getPort());

Redirect307Test.java:

should use URIBuilder here:

  108         URL url = new URL("http://localhost:" + port);

RedirectLimit.java:

  113         URL url = new URL("http://localhost:" + port);

should use URIBuilder.

MultiReleaseJarHttpProperties.java:

   69                 new URL("http://localhost:" + server.getPort() + 
"/multi-release.jar")

should use URIBuilder.

MultiReleaseJarURLConnection.java:

  171                 {"http", new URL("jar:http://localhost:" + 
server.getPort() + "/multi-release.jar!/")},
  172                 {"http", new URL("http://localhost:" + 
server.getPort() + "/multi-release.jar")},

Should use URIBuilder.

SimpleHttpServer.java:

a simpler change that keeps binding happening in
start() would be:

      private final HttpServer server;
+    private final InetAddress address;

      public SimpleHttpServer() throws IOException {
-        server = HttpServer.create();
+        this(null);
+    }
+
+    public SimpleHttpServer(InetAddress address) throws IOException {
+        address = addr;
+        server = HttpServer.create();
      }

      public void start() throws IOException {
-        server.bind(new InetSocketAddress(0), 0);
+        server.bind(new InetSocketAddress(address, 0), 0);

best regards,

-- daniel



On 13/05/2019 16:07, Aleks Efimov wrote:
> Hi,
> 
> Please help to review another part of test fixes to address 
> intermittent? networking test failures.
> 
> Webrev:
> http://cr.openjdk.java.net/~aefimov/8223638/00/index.html
> 
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8223638
> 
> With Best Regards,
> Aleksei
> 


From chris.hegarty at oracle.com  Mon May 13 15:55:36 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 May 2019 16:55:36 +0100
Subject: [teststabilization] RFR: 8223632: Replace wildcard address with
 loopback or local host in tests - part 5
In-Reply-To: <3bfcb6b8-9026-04d4-0be8-b5c8198a7e84@oracle.com>
References: <3bfcb6b8-9026-04d4-0be8-b5c8198a7e84@oracle.com>
Message-ID: <b0dffe46-8b3d-d05f-2b9c-a2f9896c4f26@oracle.com>

Daniel,

On 13/05/2019 14:58, Daniel Fuchs wrote:
> ...
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8223632/webrev.00/

This looks ok to me. I'm happy to see these tests being improved, as I
see them failing intermittently from time to time.

Clearly there is some interference in your test runs. ProxyTest.java
shows additional diagnostic information being printed. This is good, and
will improve the robustness and diagnosability in case of future
failures.

-Chris.

From chris.hegarty at oracle.com  Mon May 13 16:32:59 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 May 2019 17:32:59 +0100
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
Message-ID: <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>

Arthur,

On 11/05/2019 01:17, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223737
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html
> 
> HostsFileNameService doesn't handle IPv6 literal addresses correctly.
> For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.
> 
> Rather than comparing address strings, compare the address byte arrays.

Comparison of byte arrays is much better. The changes look good.

Trivially, can I ask you to please include a number of other reverse
lookup's to fill out the test a little. Here's what I came up with:

     testReverseLookup("10.2.3.4", "testHost.testDomain");

     // ::1 and 0:0:0:0:0:0:0:1 should map to ip6-localhost
     testReverseLookup("::1", "ip6-localhost");
     testReverseLookup("0:0:0:0:0:0:0:1", "ip6-localhost");
 
testReverseLookup("0000:0000:0000:0000:0000:0000:0000:0001","ip6-localhost");

     testReverseLookup("fe00::0", "ip6-localnet");
     testReverseLookup("fe00:0:0:0:0:0:0:0", "ip6-localnet");
     testReverseLookup("fe00:0000:0000:0000:0000:0000:0000:0000", 
"ip6-localnet");

     testReverseLookup("fe80::1", "link-local-host");
     testReverseLookup("fe80:000:0:00:0:000:00:1", "link-local-host");
     testReverseLookup("fe80:0000:0000:0000:0000:0000:0000:0001", 
"link-local-host");

Thanks,
-Chris.

From aeubanks at google.com  Mon May 13 17:59:22 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 13 May 2019 10:59:22 -0700
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
Message-ID: <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Mon, May 13, 2019 at 9:33 AM
*To: *Arthur Eubanks, OpenJDK Network Dev list

Arthur,
>
> On 11/05/2019 01:17, Arthur Eubanks wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223737
> > Webrev:
> http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html
> >
> > HostsFileNameService doesn't handle IPv6 literal addresses correctly.
> > For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.
> >
> > Rather than comparing address strings, compare the address byte arrays.
>
> Comparison of byte arrays is much better. The changes look good.
>
> Trivially, can I ask you to please include a number of other reverse
> lookup's to fill out the test a little. Here's what I came up with:
>
>      testReverseLookup("10.2.3.4", "testHost.testDomain");
>
>      // ::1 and 0:0:0:0:0:0:0:1 should map to ip6-localhost
>      testReverseLookup("::1", "ip6-localhost");
>      testReverseLookup("0:0:0:0:0:0:0:1", "ip6-localhost");
>
>
> testReverseLookup("0000:0000:0000:0000:0000:0000:0000:0001","ip6-localhost");
>
>      testReverseLookup("fe00::0", "ip6-localnet");
>      testReverseLookup("fe00:0:0:0:0:0:0:0", "ip6-localnet");
>      testReverseLookup("fe00:0000:0000:0000:0000:0000:0000:0000",
> "ip6-localnet");
>
>      testReverseLookup("fe80::1", "link-local-host");
>      testReverseLookup("fe80:000:0:00:0:000:00:1", "link-local-host");
>      testReverseLookup("fe80:0000:0000:0000:0000:0000:0000:0001",
> "link-local-host");
>
> Thanks,
> -Chris.
>
Added the extra reverse lookups.

I also noticed that the test is catching UnknownHostException and not
rethrowing it, so I removed the try/catch.

Updated webrev:
http://cr.openjdk.java.net/~aeubanks/8223737/webrev.01/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190513/4bf9250e/attachment-0001.html>

From daniel.fuchs at oracle.com  Mon May 13 18:29:59 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 May 2019 19:29:59 +0100
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should
 be more resilient to unexpected traffic
Message-ID: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>

Hi,

Please find below a fix for:

[1] 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be
          more resilient to unexpected traffic


Occasionally a test server may receive traffic that doesn't originate
from the client in the test. If the client makes requests that are
recognizable as originating from the client, the server can
sometimes (depending on the test logic) safely ignore what doesn't
appear to be coming from the expected client.

This change proposes to do so for the MultiThreadTest server,
which sometimes receives more connections than it expects:

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

However - after having eliminated this possible failure cause,
I have now convinced myself that the additional connection
observed from time to time may indeed be coming from the rightful
client. For the sake of test stabilization, this changes propose
to slightly relax the test logic to allow for one additional
connection than what the test expects.

A followup bug [2] has been logged to investigate the why
a sixth connection is sometime created by the client.

best regards,

-- daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8223716
[2] https://bugs.openjdk.java.net/browse/JDK-8223783


From aleksej.efimov at oracle.com  Mon May 13 18:45:05 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 13 May 2019 19:45:05 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
In-Reply-To: <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>
References: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
 <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>
Message-ID: <f255d5f4-cdab-dba8-5b7a-755d1fff4cf8@oracle.com>

Hi Daniel,

Thanks for all your comments.
I've changed all the tests to address the concern about the "localhost" 
configurations. Plus, I've utilized URIBuilder where possible.
Also tried keep the SimpleHttpServer simpler.

The new version can be viewed here:
http://cr.openjdk.java.net/~aefimov/8223638/01/

With Best Regards,
Aleksei

On 13/05/2019 16:45, Daniel Fuchs wrote:
> Hi Aleksei,
>
> I believe that some configurations in the wild might
> return you the external host address when looking up
> "localhost". It doesn't matter if the server binds to
> the wildcard, but if you change the server to stop using
> the wildcard, then you also need to change the client to
> use the same address that the server binds too.
>
> AcceptCauseFileDescriptorLeak.java:
>
> I believe line
> ? 97???????????????????????? (new Socket("localhost", 
> ss.getLocalPort())).close();
>
> should be changed to use the loopback address.
>
>
> UnreferencedSockets.java:
>
> same remark as above:
>
> ?130???????? Socket s = new Socket("localhost", svr.localPort());
>
> PerConnectionProxy.java:
>
> same remark as above:
>
> ? 97???????????????? InetSocketAddress isa = 
> InetSocketAddress.createUnresolved("localhost", pserver.getPort());
>
> Redirect307Test.java:
>
> should use URIBuilder here:
>
> ?108???????? URL url = new URL("http://localhost:" + port);
>
> RedirectLimit.java:
>
> ?113???????? URL url = new URL("http://localhost:" + port);
>
> should use URIBuilder.
>
> MultiReleaseJarHttpProperties.java:
>
> ? 69???????????????? new URL("http://localhost:" + server.getPort() + 
> "/multi-release.jar")
>
> should use URIBuilder.
>
> MultiReleaseJarURLConnection.java:
>
> ?171???????????????? {"http", new URL("jar:http://localhost:" + 
> server.getPort() + "/multi-release.jar!/")},
> ?172???????????????? {"http", new URL("http://localhost:" + 
> server.getPort() + "/multi-release.jar")},
>
> Should use URIBuilder.
>
> SimpleHttpServer.java:
>
> a simpler change that keeps binding happening in
> start() would be:
>
> ???? private final HttpServer server;
> +??? private final InetAddress address;
>
> ???? public SimpleHttpServer() throws IOException {
> -??????? server = HttpServer.create();
> +??????? this(null);
> +??? }
> +
> +??? public SimpleHttpServer(InetAddress address) throws IOException {
> +??????? address = addr;
> +??????? server = HttpServer.create();
> ???? }
>
> ???? public void start() throws IOException {
> -??????? server.bind(new InetSocketAddress(0), 0);
> +??????? server.bind(new InetSocketAddress(address, 0), 0);
>
> best regards,
>
> -- daniel
>
>
>
> On 13/05/2019 16:07, Aleks Efimov wrote:
>> Hi,
>>
>> Please help to review another part of test fixes to address 
>> intermittent? networking test failures.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~aefimov/8223638/00/index.html
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8223638
>>
>> With Best Regards,
>> Aleksei
>>
>


From alexey.menkov at oracle.com  Mon May 13 21:06:12 2019
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Mon, 13 May 2019 14:06:12 -0700
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
 <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
 <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com>
Message-ID: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com>

Hi Chris, Serguei,

Updated webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/
CSR (approved):
https://bugs.openjdk.java.net/browse/JDK-8223104

Changes (vs. webrev.04):

- setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared 
setOptionsCommon function (in socketTransport.c)
   the value by default is "true" on Windows and is "false" on Unix, but 
it can be overridden, so lets set it explicitly;
- a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is added;
- added some comments as per Serguei request.

About scopes support - I thought that the functionality is not important 
for debugger, but I can implement it (I'd prefer to do it by separate RFE).

--alex

On 05/11/2019 03:39, Chris Hegarty wrote:
> 
> 
>> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote:
>>
>> Hi guys,
>>
>> We need a couple of partial reviews for this enhancement:
>>
>>   - From the net-dev to check IPv6-addresses related part.
>>     It does not need to be a thorough review.
>>     We need another pair of eyes to check for obvious typos or misses.
>>     Included Chris H. to mailing list in hope for some assistance.
>>     (Chris, we need some help to find one of the IPv6 experts.)
>>
>>   - From the serviceability-dev to check if compatibility
>>     is not broken and nothing is missed.
>>     This includes part of code that is not directly involved
>>     into manipulations with the IPv4/IPv6 addresses.
>>     The related spec update is tracked by a sub-task:
>>       https://bugs.openjdk.java.net/browse/JDK-8221707
>>
>>
>> Related CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8223104
>>
>> The latest webrev:
>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
> 
> 
> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c
> 
>     223     if (domain == AF_INET6) {
>     224         int off = 0;
>     225         // make the socket a dual mode socket
>     226         setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&off, sizeof(off));
>     227     }
>     228   }
> 
>    This code is fine, but maybe you want to expand the comment to
>    mention that the setsockopt may fail if IPv4 is not supported. And
>    that?s OK.
> 
>    I cannot find a similar setting of IPV6_V6ONLY for the unix
>    equivalent. Why not, or where can it be found?
> 
> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
> 
>    There is a lot of native code here, I skimmed over it, seems
>    reasonable. There is an obvious lack of any reference to IPv6
>    scopes. Can the address given to bind be an IPv6 link-local?
>    If so, then the scope will need to be parsed / set appropriately.
>    ( seems that the new test skips all scoped addresses? )
> 
> -Chris.
> 

From serguei.spitsyn at oracle.com  Mon May 13 23:33:24 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 13 May 2019 16:33:24 -0700
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
 <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
 <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com>
 <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com>
Message-ID: <4101dda6-021c-5a3c-270e-fa0a10b82ae4@oracle.com>

Hi Alex,

Thank you for the update!
It looks good to me.

Thanks,
Serguei


On 5/13/19 14:06, Alex Menkov wrote:
> Hi Chris, Serguei,
>
> Updated webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/
> CSR (approved):
> https://bugs.openjdk.java.net/browse/JDK-8223104
>
> Changes (vs. webrev.04):
>
> - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared 
> setOptionsCommon function (in socketTransport.c)
> ? the value by default is "true" on Windows and is "false" on Unix, 
> but it can be overridden, so lets set it explicitly;
> - a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is 
> added;
> - added some comments as per Serguei request.
>
> About scopes support - I thought that the functionality is not 
> important for debugger, but I can implement it (I'd prefer to do it by 
> separate RFE).
>
> --alex
>
> On 05/11/2019 03:39, Chris Hegarty wrote:
>>
>>
>>> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote:
>>>
>>> Hi guys,
>>>
>>> We need a couple of partial reviews for this enhancement:
>>>
>>> ? - From the net-dev to check IPv6-addresses related part.
>>> ??? It does not need to be a thorough review.
>>> ??? We need another pair of eyes to check for obvious typos or misses.
>>> ??? Included Chris H. to mailing list in hope for some assistance.
>>> ??? (Chris, we need some help to find one of the IPv6 experts.)
>>>
>>> ? - From the serviceability-dev to check if compatibility
>>> ??? is not broken and nothing is missed.
>>> ??? This includes part of code that is not directly involved
>>> ??? into manipulations with the IPv4/IPv6 addresses.
>>> ??? The related spec update is tracked by a sub-task:
>>> ????? https://bugs.openjdk.java.net/browse/JDK-8221707
>>>
>>>
>>> Related CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8223104
>>>
>>> The latest webrev:
>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>>
>>
>> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c
>>
>> ??? 223???? if (domain == AF_INET6) {
>> ??? 224???????? int off = 0;
>> ??? 225???????? // make the socket a dual mode socket
>> ??? 226???????? setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char 
>> *)&off, sizeof(off));
>> ??? 227???? }
>> ??? 228?? }
>>
>> ?? This code is fine, but maybe you want to expand the comment to
>> ?? mention that the setsockopt may fail if IPv4 is not supported. And
>> ?? that?s OK.
>>
>> ?? I cannot find a similar setting of IPV6_V6ONLY for the unix
>> ?? equivalent. Why not, or where can it be found?
>>
>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>
>> ?? There is a lot of native code here, I skimmed over it, seems
>> ?? reasonable. There is an obvious lack of any reference to IPv6
>> ?? scopes. Can the address given to bind be an IPv6 link-local?
>> ?? If so, then the scope will need to be parsed / set appropriately.
>> ?? ( seems that the new test skips all scoped addresses? )
>>
>> -Chris.
>>


From macanaoire at hotmail.com  Mon May 13 23:52:34 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Mon, 13 May 2019 23:52:34 +0000
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>,
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
Message-ID: <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>

Hi Arthur, Chris,
   just a note in passing, as you are well set on the changes, which is all  good -- needs must, as they say.

The current implementation is an emulation of the gethostbyname and gethostbyaddr lookup on /etc/hosts.
The reverse lookup  issue is also solved by adding an additional entry in the hosts file
0:0:0:0:0:0:0:1 ip6-localhost ip6-loopback. Your reverse lookup will pass.

$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java InternalNameServiceWithHostsFileTest
############################  InetAddress == ip6-localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr ::1 : expected host name ip6-localhost?
testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name ip6-localhost?
testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name ip6-localhost?

That was the design -- the hosts file would contain whatever set of mapping are required for a particular context.
So the string comparison was sufficient.

IF your reverse lookup tests are run against the PlatformFormNameService,
which is the fall through to the native OS calls gethostbyname, getaddrinfo etc.
then you get the same set of failure afaik.

on windows using jdk12 test output shown below
so you could say there is some degree of consistent behaviour between the two services!!

regards
Mark



msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr ::1 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "::1" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:25)?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0:0:0:0:0:0:0:1" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:26)?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0000:0000:0000:0000:0000:0000:0000:0001" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:27)?


________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Arthur Eubanks <aeubanks at google.com>
Sent: Monday 13 May 2019 17:59
To: Chris Hegarty
Cc: OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly



From: Chris Hegarty <chris.hegarty at oracle.com<mailto:chris.hegarty at oracle.com>>
Date: Mon, May 13, 2019 at 9:33 AM
To: Arthur Eubanks, OpenJDK Network Dev list

Arthur,

On 11/05/2019 01:17, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223737
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html
>
> HostsFileNameService doesn't handle IPv6 literal addresses correctly.
> For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.
>
> Rather than comparing address strings, compare the address byte arrays.

Comparison of byte arrays is much better. The changes look good.

Trivially, can I ask you to please include a number of other reverse
lookup's to fill out the test a little. Here's what I came up with:

     testReverseLookup("10.2.3.4", "testHost.testDomain");

     // ::1 and 0:0:0:0:0:0:0:1 should map to ip6-localhost
     testReverseLookup("::1", "ip6-localhost");
     testReverseLookup("0:0:0:0:0:0:0:1", "ip6-localhost");

testReverseLookup("0000:0000:0000:0000:0000:0000:0000:0001","ip6-localhost");

     testReverseLookup("fe00::0", "ip6-localnet");
     testReverseLookup("fe00:0:0:0:0:0:0:0", "ip6-localnet");
     testReverseLookup("fe00:0000:0000:0000:0000:0000:0000:0000",
"ip6-localnet");

     testReverseLookup("fe80::1", "link-local-host");
     testReverseLookup("fe80:000:0:00:0:000:00:1", "link-local-host");
     testReverseLookup("fe80:0000:0000:0000:0000:0000:0000:0001",
"link-local-host");

Thanks,
-Chris.
Added the extra reverse lookups.

I also noticed that the test is catching UnknownHostException and not rethrowing it, so I removed the try/catch.

Updated webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.01/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190513/a35f9ee4/attachment.html>

From chris.hegarty at oracle.com  Tue May 14 09:15:38 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 May 2019 10:15:38 +0100
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
 <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>

Mark,

The comparison by String was a reasonable choice when this mechanism was
added. What is being proposed here expands the functionality so that
logically equivalent IPv6 literals can be used without the need for
additional entries.

I did the following testing on my Linux box, Ubuntu 16.04, and it shows,
at least on this Linux flavour, that the platform name service operates
in a similar way to that of the change that is being proposed here.

$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS"
NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
$ uname -a
Linux chhegar 4.15.0-39-generic #42~16.04.1-Ubuntu SMP Wed Oct 24 17:09:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$
$
$ cat /etc/hosts
::3	xxyyzz

::1	localhost
::1	chhegar

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

$ ~/binaries/jdk-12/bin/jshell
|  Welcome to JShell -- Version 12
|  For an introduction type: /help intro

jshell> InetAddress.getByName("::3").getHostName()
$1 ==> "xxyyzz"

jshell> InetAddress.getByName("0:0:0:0:0:0:0:3").getHostName()
$2 ==> "xxyyzz"

jshell> InetAddress.getByName("0000:0000:0000:0000:0000:0000:0000:0003").getHostName()
$3 ==> "xxyyzz"


> On 14 May 2019, at 00:52, mark sheppard <macanaoire at hotmail.com> wrote:
> 
> Hi Arthur, Chris,
>    just a note in passing, as you are well set on the changes, which is all  good -- needs must, as they say.
> 
> The current implementation is an emulation of the gethostbyname and gethostbyaddr lookup on /etc/hosts.
> The reverse lookup  issue is also solved by adding an additional entry in the hosts file
> 0:0:0:0:0:0:0:1 ip6-localhost ip6-loopback. Your reverse lookup will pass.
> 
> $ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java InternalNameServiceWithHostsFileTest
> ############################  InetAddress == ip6-localhost/0:0:0:0:0:0:0:1?
> retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
> testReverseLookup: host addr ::1 : expected host name ip6-localhost?
> testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name ip6-localhost?
> testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name ip6-localhost?
> 
> That was the design -- the hosts file would contain whatever set of mapping are required for a particular context.
> So the string comparison was sufficient.
> 
> IF your reverse lookup tests are run against the PlatformFormNameService, 
> which is the fall through to the native OS calls gethostbyname, getaddrinfo etc.
> then you get the same set of failure afaik.
> 
> on windows using jdk12 test output shown below 
> so you could say there is some degree of consistent behaviour between the two services!!
> 
> regards
> Mark
> 
> 
> 
> msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests
> $ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
> ############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
> retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
> testReverseLookup: host addr ::1 : expected host name localhost?
> Exception in thread "main" java.lang.RuntimeException: reverse lookup of "::1" is "0:0:0:0:0:0:0:1", should be "localhost"?
> ?
>         at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
>         at PlatformNameServiceTest.main(PlatformNameServiceTest.java:25)?
> ?
> msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
> $ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
> ############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
> retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
> testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name localhost?
> Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0:0:0:0:0:0:0:1" is "0:0:0:0:0:0:0:1", should be "localhost"?
> ?
>         at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
>         at PlatformNameServiceTest.main(PlatformNameServiceTest.java:26)?
> ?
> msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
> $ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
> ############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
> retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
> testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name localhost?
> Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0000:0000:0000:0000:0000:0000:0000:0001" is "0:0:0:0:0:0:0:1", should be "localhost"?
> ?
>         at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
>         at PlatformNameServiceTest.main(PlatformNameServiceTest.java:27)?
> 
> 
> From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Arthur Eubanks <aeubanks at google.com>
> Sent: Monday 13 May 2019 17:59
> To: Chris Hegarty
> Cc: OpenJDK Network Dev list
> Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly
>  
> 
> 
> From: Chris Hegarty <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>>
> Date: Mon, May 13, 2019 at 9:33 AM
> To: Arthur Eubanks, OpenJDK Network Dev list
> 
> Arthur,
> 
> On 11/05/2019 01:17, Arthur Eubanks wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223737 <https://bugs.openjdk.java.net/browse/JDK-8223737>
> > Webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html <http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html>
> > 
> > HostsFileNameService doesn't handle IPv6 literal addresses correctly.
> > For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.
> > 
> > Rather than comparing address strings, compare the address byte arrays.
> 
> Comparison of byte arrays is much better. The changes look good.
> 
> Trivially, can I ask you to please include a number of other reverse
> lookup's to fill out the test a little. Here's what I came up with:
> 
>      testReverseLookup("10.2.3.4", "testHost.testDomain");
> 
>      // ::1 and 0:0:0:0:0:0:0:1 should map to ip6-localhost
>      testReverseLookup("::1", "ip6-localhost");
>      testReverseLookup("0:0:0:0:0:0:0:1", "ip6-localhost");
> 
> testReverseLookup("0000:0000:0000:0000:0000:0000:0000:0001","ip6-localhost");
> 
>      testReverseLookup("fe00::0", "ip6-localnet");
>      testReverseLookup("fe00:0:0:0:0:0:0:0", "ip6-localnet");
>      testReverseLookup("fe00:0000:0000:0000:0000:0000:0000:0000", 
> "ip6-localnet");
> 
>      testReverseLookup("fe80::1", "link-local-host");
>      testReverseLookup("fe80:000:0:00:0:000:00:1", "link-local-host");
>      testReverseLookup("fe80:0000:0000:0000:0000:0000:0000:0001", 
> "link-local-host");
> 
> Thanks,
> -Chris.
> Added the extra reverse lookups.
> 
> I also noticed that the test is catching UnknownHostException and not rethrowing it, so I removed the try/catch.
> 
> Updated webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.01/index.html <http://cr.openjdk.java.net/~aeubanks/8223737/webrev.01/index.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190514/db0f59b7/attachment-0001.html>

From daniel.fuchs at oracle.com  Tue May 14 09:18:44 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 May 2019 10:18:44 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
In-Reply-To: <f255d5f4-cdab-dba8-5b7a-755d1fff4cf8@oracle.com>
References: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
 <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>
 <f255d5f4-cdab-dba8-5b7a-755d1fff4cf8@oracle.com>
Message-ID: <a2053b92-a309-22d0-4911-6e82cc5b7d02@oracle.com>

Hi Aleksei,

Nit: PerConnectionProxy.java:

  88                 InetSocketAddress isa = 
InetSocketAddress.createUnresolved(InetAddress.getLoopbackAddress().getHostAddress(), 
pserver.getPort());

If you had named `serverAddress` `loopback` then you could trivially
reuse it at the line above and reduce the line length.
It's better to avoid too long lines as these are harder to review
with frame diffs and side diffs.

MultiReleaseJarURLConnection.java:

  173                 {"http", 
URIBuilder.newBuilder().scheme("jar:http").port(server.getPort()).loopback()
  174                         .path("/multi-release.jar!/").toURL()},
  175                 {"http", 
URIBuilder.newBuilder().scheme("http").port(server.getPort()).loopback()
  176                         .path("/multi-release.jar").toURL()},

There's too much going on on these lines. Can we rewrite this as:

   {"http", toHttpJarURL(server.getPort(), "/multi-release.jar", "!/") },
   {"http", toHttpJarURL(server.getPort(), "/multi-release.jar", "") },

with

private static URL toHttpJarURL(int port, String jar, String file)
        throws MalformedURLException, URISyntaxException {
     assert file.isEmpty() || file.startsWith("!");
     URI httpURI = URIBuilder.newBuilder()
                   .scheme("http")
                   .loopback()
                   .port(port)
                   .path(jar);
     return new URL("jar:" + httpURI + file);
}

best regards,

-- daniel

On 13/05/2019 19:45, Aleks Efimov wrote:
> Hi Daniel,
> 
> Thanks for all your comments.
> I've changed all the tests to address the concern about the "localhost" 
> configurations. Plus, I've utilized URIBuilder where possible.
> Also tried keep the SimpleHttpServer simpler.
> 
> The new version can be viewed here:
> http://cr.openjdk.java.net/~aefimov/8223638/01/
> 
> With Best Regards,
> Aleksei
> 
> On 13/05/2019 16:45, Daniel Fuchs wrote:
>> Hi Aleksei,
>>
>> I believe that some configurations in the wild might
>> return you the external host address when looking up
>> "localhost". It doesn't matter if the server binds to
>> the wildcard, but if you change the server to stop using
>> the wildcard, then you also need to change the client to
>> use the same address that the server binds too.
>>
>> AcceptCauseFileDescriptorLeak.java:
>>
>> I believe line
>> ? 97???????????????????????? (new Socket("localhost", 
>> ss.getLocalPort())).close();
>>
>> should be changed to use the loopback address.
>>
>>
>> UnreferencedSockets.java:
>>
>> same remark as above:
>>
>> ?130???????? Socket s = new Socket("localhost", svr.localPort());
>>
>> PerConnectionProxy.java:
>>
>> same remark as above:
>>
>> ? 97???????????????? InetSocketAddress isa = 
>> InetSocketAddress.createUnresolved("localhost", pserver.getPort());
>>
>> Redirect307Test.java:
>>
>> should use URIBuilder here:
>>
>> ?108???????? URL url = new URL("http://localhost:" + port);
>>
>> RedirectLimit.java:
>>
>> ?113???????? URL url = new URL("http://localhost:" + port);
>>
>> should use URIBuilder.
>>
>> MultiReleaseJarHttpProperties.java:
>>
>> ? 69???????????????? new URL("http://localhost:" + server.getPort() + 
>> "/multi-release.jar")
>>
>> should use URIBuilder.
>>
>> MultiReleaseJarURLConnection.java:
>>
>> ?171???????????????? {"http", new URL("jar:http://localhost:" + 
>> server.getPort() + "/multi-release.jar!/")},
>> ?172???????????????? {"http", new URL("http://localhost:" + 
>> server.getPort() + "/multi-release.jar")},
>>
>> Should use URIBuilder.
>>
>> SimpleHttpServer.java:
>>
>> a simpler change that keeps binding happening in
>> start() would be:
>>
>> ???? private final HttpServer server;
>> +??? private final InetAddress address;
>>
>> ???? public SimpleHttpServer() throws IOException {
>> -??????? server = HttpServer.create();
>> +??????? this(null);
>> +??? }
>> +
>> +??? public SimpleHttpServer(InetAddress address) throws IOException {
>> +??????? address = addr;
>> +??????? server = HttpServer.create();
>> ???? }
>>
>> ???? public void start() throws IOException {
>> -??????? server.bind(new InetSocketAddress(0), 0);
>> +??????? server.bind(new InetSocketAddress(address, 0), 0);
>>
>> best regards,
>>
>> -- daniel
>>
>>
>>
>> On 13/05/2019 16:07, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please help to review another part of test fixes to address 
>>> intermittent? networking test failures.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~aefimov/8223638/00/index.html
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8223638
>>>
>>> With Best Regards,
>>> Aleksei
>>>
>>
> 


From chris.hegarty at oracle.com  Tue May 14 09:42:03 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 May 2019 10:42:03 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
 <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
Message-ID: <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>

Arthur,

> On 11 May 2019, at 11:48, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Arthur,
> 
>> On 10 May 2019, at 17:37, Arthur Eubanks <aeubanks at google.com <mailto:aeubanks at google.com>> wrote:
>> 
>> Sounds good.
>> New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/ <http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/>
>> 
>> This is almost exactly the changes we made internally to this file.
> 
> Good that we eventually converged on the same substantive solution.
> Bad that we went in a little circle first ( though it does give an 
> additional level of confidence that we ended up in a similar place).
> 
> I think that this latest webrev looks good. I?ll do some testing with
> it and report back the results.

All good. I see no issues when running various tests.

-Chris.

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

From macanaoire at hotmail.com  Tue May 14 11:14:06 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Tue, 14 May 2019 11:14:06 +0000
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
 <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>,
 <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>
Message-ID: <DB6P192MB02005FB68555804559ECC1E2DF080@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>

Hi Chris,
    yes understood,  thanks for that ... all good  :+1  ... just wanted to highlight how the current mechanism worked
and
    that on  a Windows lapper there is a potential anomaly with the standard platform names service with the reverse lookup scenario.

regards
Mark

________________________________
From: Chris Hegarty <chris.hegarty at oracle.com>
Sent: Tuesday 14 May 2019 09:15
To: mark sheppard
Cc: Arthur Eubanks; OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly

Mark,

The comparison by String was a reasonable choice when this mechanism was
added. What is being proposed here expands the functionality so that
logically equivalent IPv6 literals can be used without the need for
additional entries.

I did the following testing on my Linux box, Ubuntu 16.04, and it shows,
at least on this Linux flavour, that the platform name service operates
in a similar way to that of the change that is being proposed here.

$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS"
NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
$ uname -a
Linux chhegar 4.15.0-39-generic #42~16.04.1-Ubuntu SMP Wed Oct 24 17:09:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$
$
$ cat /etc/hosts
::3 xxyyzz

::1 localhost
::1 chhegar

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

$ ~/binaries/jdk-12/bin/jshell
|  Welcome to JShell -- Version 12
|  For an introduction type: /help intro

jshell> InetAddress.getByName("::3").getHostName()
$1 ==> "xxyyzz"

jshell> InetAddress.getByName("0:0:0:0:0:0:0:3").getHostName()
$2 ==> "xxyyzz"

jshell> InetAddress.getByName("0000:0000:0000:0000:0000:0000:0000:0003").getHostName()
$3 ==> "xxyyzz"


On 14 May 2019, at 00:52, mark sheppard <macanaoire at hotmail.com<mailto:macanaoire at hotmail.com>> wrote:

Hi Arthur, Chris,
   just a note in passing, as you are well set on the changes, which is all  good -- needs must, as they say.

The current implementation is an emulation of the gethostbyname and gethostbyaddr lookup on /etc/hosts.
The reverse lookup  issue is also solved by adding an additional entry in the hosts file
0:0:0:0:0:0:0:1 ip6-localhost ip6-loopback. Your reverse lookup will pass.

$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java InternalNameServiceWithHostsFileTest
############################  InetAddress == ip6-localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr ::1 : expected host name ip6-localhost?
testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name ip6-localhost?
testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name ip6-localhost?

That was the design -- the hosts file would contain whatever set of mapping are required for a particular context.
So the string comparison was sufficient.

IF your reverse lookup tests are run against the PlatformFormNameService,
which is the fall through to the native OS calls gethostbyname, getaddrinfo etc.
then you get the same set of failure afaik.

on windows using jdk12 test output shown below
so you could say there is some degree of consistent behaviour between the two services!!

regards
Mark



msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr ::1 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "::1" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:25)?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr 0:0:0:0:0:0:0:1 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0:0:0:0:0:0:0:1" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:26)?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java  -Djava.net.preferIPv6Addresses=true PlatformNameServiceTest?
############################  InetAddress == localhost/0:0:0:0:0:0:0:1?
retrieved address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] equal to expected address == [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]?
testReverseLookup: host addr 0000:0000:0000:0000:0000:0000:0000:0001 : expected host name localhost?
Exception in thread "main" java.lang.RuntimeException: reverse lookup of "0000:0000:0000:0000:0000:0000:0000:0001" is "0:0:0:0:0:0:0:1", should be "localhost"?
?
        at PlatformNameServiceTest.testReverseLookup(PlatformNameServiceTest.java:64)?
        at PlatformNameServiceTest.main(PlatformNameServiceTest.java:27)?


________________________________
From: net-dev <net-dev-bounces at openjdk.java.net<mailto:net-dev-bounces at openjdk.java.net>> on behalf of Arthur Eubanks <aeubanks at google.com<mailto:aeubanks at google.com>>
Sent: Monday 13 May 2019 17:59
To: Chris Hegarty
Cc: OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly



From: Chris Hegarty <chris.hegarty at oracle.com<mailto:chris.hegarty at oracle.com>>
Date: Mon, May 13, 2019 at 9:33 AM
To: Arthur Eubanks, OpenJDK Network Dev list

Arthur,

On 11/05/2019 01:17, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223737
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.00/index.html
>
> HostsFileNameService doesn't handle IPv6 literal addresses correctly.
> For example, ::1 and 0:0:0:0:0:0:0:1 should yield the same output.
>
> Rather than comparing address strings, compare the address byte arrays.

Comparison of byte arrays is much better. The changes look good.

Trivially, can I ask you to please include a number of other reverse
lookup's to fill out the test a little. Here's what I came up with:

     testReverseLookup("10.2.3.4", "testHost.testDomain");

     // ::1 and 0:0:0:0:0:0:0:1 should map to ip6-localhost
     testReverseLookup("::1", "ip6-localhost");
     testReverseLookup("0:0:0:0:0:0:0:1", "ip6-localhost");

testReverseLookup("0000:0000:0000:0000:0000:0000:0000:0001","ip6-localhost");

     testReverseLookup("fe00::0", "ip6-localnet");
     testReverseLookup("fe00:0:0:0:0:0:0:0", "ip6-localnet");
     testReverseLookup("fe00:0000:0000:0000:0000:0000:0000:0000",
"ip6-localnet");

     testReverseLookup("fe80::1", "link-local-host");
     testReverseLookup("fe80:000:0:00:0:000:00:1", "link-local-host");
     testReverseLookup("fe80:0000:0000:0000:0000:0000:0000:0001",
"link-local-host");

Thanks,
-Chris.
Added the extra reverse lookups.

I also noticed that the test is catching UnknownHostException and not rethrowing it, so I removed the try/catch.

Updated webrev: http://cr.openjdk.java.net/~aeubanks/8223737/webrev.01/index.html

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

From aleksej.efimov at oracle.com  Tue May 14 11:22:27 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Tue, 14 May 2019 12:22:27 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
In-Reply-To: <a2053b92-a309-22d0-4911-6e82cc5b7d02@oracle.com>
References: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
 <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>
 <f255d5f4-cdab-dba8-5b7a-755d1fff4cf8@oracle.com>
 <a2053b92-a309-22d0-4911-6e82cc5b7d02@oracle.com>
Message-ID: <0d41e1f4-f447-1cb5-16f7-5a032c91b207@oracle.com>

Hi Daniel,

New webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8223638/02/

PerConnectionProxy.java - fixed as suggested.

MultiReleaseJarURLConnection.java:
I've added the toHttpJarURL method with small modifications:
Test now uses the method only for the case with "jar:http". For "http:" 
- it's been using only "http:" before the change. With "jar:" appended 
and without "!/" it fails with:

Caused by: java.lang.NullPointerException: no !/ in spec
	at java.base/sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:168)
	at java.base/sun.net.www.protocol.jar.Handler.parseURL(Handler.java:150)
	at java.base/java.net.URL.<init>(URL.java:679)

Best Regards,
Aleksei

On 14/05/2019 10:18, Daniel Fuchs wrote:
> Hi Aleksei,
>
> Nit: PerConnectionProxy.java:
>
> ?88???????????????? InetSocketAddress isa = 
> InetSocketAddress.createUnresolved(InetAddress.getLoopbackAddress().getHostAddress(), 
> pserver.getPort());
>
> If you had named `serverAddress` `loopback` then you could trivially
> reuse it at the line above and reduce the line length.
> It's better to avoid too long lines as these are harder to review
> with frame diffs and side diffs.
>
> MultiReleaseJarURLConnection.java:
>
> ?173???????????????? {"http", 
> URIBuilder.newBuilder().scheme("jar:http").port(server.getPort()).loopback()
> ?174 .path("/multi-release.jar!/").toURL()},
> ?175???????????????? {"http", 
> URIBuilder.newBuilder().scheme("http").port(server.getPort()).loopback()
> ?176???????????????????????? .path("/multi-release.jar").toURL()},
>
> There's too much going on on these lines. Can we rewrite this as:
>
> ? {"http", toHttpJarURL(server.getPort(), "/multi-release.jar", "!/") },
> ? {"http", toHttpJarURL(server.getPort(), "/multi-release.jar", "") },
>
> with
>
> private static URL toHttpJarURL(int port, String jar, String file)
> ?????? throws MalformedURLException, URISyntaxException {
> ??? assert file.isEmpty() || file.startsWith("!");
> ??? URI httpURI = URIBuilder.newBuilder()
> ????????????????? .scheme("http")
> ????????????????? .loopback()
> ????????????????? .port(port)
> ????????????????? .path(jar);
> ??? return new URL("jar:" + httpURI + file);
> }
>
> best regards,
>
> -- daniel
>
> On 13/05/2019 19:45, Aleks Efimov wrote:
>> Hi Daniel,
>>
>> Thanks for all your comments.
>> I've changed all the tests to address the concern about the 
>> "localhost" configurations. Plus, I've utilized URIBuilder where 
>> possible.
>> Also tried keep the SimpleHttpServer simpler.
>>
>> The new version can be viewed here:
>> http://cr.openjdk.java.net/~aefimov/8223638/01/
>>
>> With Best Regards,
>> Aleksei
>>
>> On 13/05/2019 16:45, Daniel Fuchs wrote:
>>> Hi Aleksei,
>>>
>>> I believe that some configurations in the wild might
>>> return you the external host address when looking up
>>> "localhost". It doesn't matter if the server binds to
>>> the wildcard, but if you change the server to stop using
>>> the wildcard, then you also need to change the client to
>>> use the same address that the server binds too.
>>>
>>> AcceptCauseFileDescriptorLeak.java:
>>>
>>> I believe line
>>> ? 97???????????????????????? (new Socket("localhost", 
>>> ss.getLocalPort())).close();
>>>
>>> should be changed to use the loopback address.
>>>
>>>
>>> UnreferencedSockets.java:
>>>
>>> same remark as above:
>>>
>>> ?130???????? Socket s = new Socket("localhost", svr.localPort());
>>>
>>> PerConnectionProxy.java:
>>>
>>> same remark as above:
>>>
>>> ? 97???????????????? InetSocketAddress isa = 
>>> InetSocketAddress.createUnresolved("localhost", pserver.getPort());
>>>
>>> Redirect307Test.java:
>>>
>>> should use URIBuilder here:
>>>
>>> ?108???????? URL url = new URL("http://localhost:" + port);
>>>
>>> RedirectLimit.java:
>>>
>>> ?113???????? URL url = new URL("http://localhost:" + port);
>>>
>>> should use URIBuilder.
>>>
>>> MultiReleaseJarHttpProperties.java:
>>>
>>> ? 69???????????????? new URL("http://localhost:" + server.getPort() 
>>> + "/multi-release.jar")
>>>
>>> should use URIBuilder.
>>>
>>> MultiReleaseJarURLConnection.java:
>>>
>>> ?171???????????????? {"http", new URL("jar:http://localhost:" + 
>>> server.getPort() + "/multi-release.jar!/")},
>>> ?172???????????????? {"http", new URL("http://localhost:" + 
>>> server.getPort() + "/multi-release.jar")},
>>>
>>> Should use URIBuilder.
>>>
>>> SimpleHttpServer.java:
>>>
>>> a simpler change that keeps binding happening in
>>> start() would be:
>>>
>>> ???? private final HttpServer server;
>>> +??? private final InetAddress address;
>>>
>>> ???? public SimpleHttpServer() throws IOException {
>>> -??????? server = HttpServer.create();
>>> +??????? this(null);
>>> +??? }
>>> +
>>> +??? public SimpleHttpServer(InetAddress address) throws IOException {
>>> +??????? address = addr;
>>> +??????? server = HttpServer.create();
>>> ???? }
>>>
>>> ???? public void start() throws IOException {
>>> -??????? server.bind(new InetSocketAddress(0), 0);
>>> +??????? server.bind(new InetSocketAddress(address, 0), 0);
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>>
>>> On 13/05/2019 16:07, Aleks Efimov wrote:
>>>> Hi,
>>>>
>>>> Please help to review another part of test fixes to address 
>>>> intermittent? networking test failures.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~aefimov/8223638/00/index.html
>>>>
>>>> JBS:
>>>> https://bugs.openjdk.java.net/browse/JDK-8223638
>>>>
>>>> With Best Regards,
>>>> Aleksei
>>>>
>>>
>>
>

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

From daniel.fuchs at oracle.com  Tue May 14 11:57:59 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 May 2019 12:57:59 +0100
Subject: [teststabilization] RFR: 8223638: Replace wildcard address with
 loopback or local host in tests - part 6
In-Reply-To: <0d41e1f4-f447-1cb5-16f7-5a032c91b207@oracle.com>
References: <704ef1ee-b6df-d341-41ea-947edda325f8@oracle.com>
 <6762820b-be22-26bf-1d15-fe7e5463f590@oracle.com>
 <f255d5f4-cdab-dba8-5b7a-755d1fff4cf8@oracle.com>
 <a2053b92-a309-22d0-4911-6e82cc5b7d02@oracle.com>
 <0d41e1f4-f447-1cb5-16f7-5a032c91b207@oracle.com>
Message-ID: <938b05db-3954-0e8d-a6d1-8d3cc468ccbf@oracle.com>

Hi Aleksei,

Looks good to me!

best regards,

-- daniel

On 14/05/2019 12:22, Aleks Efimov wrote:
> Hi Daniel,
> 
> New webrev can be found here: 
> http://cr.openjdk.java.net/~aefimov/8223638/02/
> 
> PerConnectionProxy.java - fixed as suggested.
> 
> MultiReleaseJarURLConnection.java:
> I've added the toHttpJarURL method with small modifications:
> Test now uses the method only for the case with "jar:http". For "http:" 
> - it's been using only "http:" before the change. With "jar:" appended 
> and without "!/" it fails with:
> 
> Caused by: java.lang.NullPointerException: no !/ in spec
> 	at java.base/sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:168)
> 	at java.base/sun.net.www.protocol.jar.Handler.parseURL(Handler.java:150)
> 	at java.base/java.net.URL.<init>(URL.java:679)
> 
> Best Regards,
> Aleksei
> 


From christoph.langer at sap.com  Tue May 14 12:57:07 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 12:57:07 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
Message-ID: <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

> > unfortunately, your proposed solution does not work with javac. I get this
> in the build:
> 
> Oh darn. I should have double checked.
> Can we at least reduce the scope of the @SuppressedWarnings by
> introducing a private method that just has the return call?

Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?

Thanks
Christoph


From daniel.fuchs at oracle.com  Tue May 14 16:02:58 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 May 2019 17:02:58 +0100
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
Message-ID: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>

Hi,

Some recent test stabilization fixes had a side effect on
two FTP tests: now that the client might use the IPv6 loopback,
the test might fail on IPv6 only hosts if the test server
doesn't support the extended EPSV mode, or if the client
isn't configured to use NO_PROXY and the default proxy selector
doesn't bypass [0:0:0:0:0:0:0:1] - as happened on my local
machine.

I'd like to push this change that fixes two of the FTP
test recently modified to work with IPv6 addresses as an example
of what might need to be done to get such tests working on
IPv6 only hosts.

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

JBS: https://bugs.openjdk.java.net/browse/JDK-8223880

best regards,

-- daniel

From daniel.fuchs at oracle.com  Tue May 14 16:03:45 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 May 2019 17:03:45 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>

Hi Christoph,

That looks much better, thanks!
(but still not commenting on the other changes ;-))

best regards,

-- daniel

On 14/05/2019 13:57, Langer, Christoph wrote:
> Hi Daniel,
> 
>>> unfortunately, your proposed solution does not work with javac. I get this
>> in the build:
>>
>> Oh darn. I should have double checked.
>> Can we at least reduce the scope of the @SuppressedWarnings by
>> introducing a private method that just has the return call?
> 
> Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> 
> Thanks
> Christoph
> 


From christoph.langer at sap.com  Tue May 14 21:03:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 21:03:47 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
Message-ID: <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks Daniel.

Can anybody help reviewing the changes to:
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
and
src/java.management/share/classes/java/lang/management/ManagementFactory.java ?

Thanks
Christoph

> -----Original Message-----
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Dienstag, 14. Mai 2019 18:04
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
>
> Hi Christoph,
>
> That looks much better, thanks!
> (but still not commenting on the other changes ;-))
>
> best regards,
>
> -- daniel
>
> On 14/05/2019 13:57, Langer, Christoph wrote:
> > Hi Daniel,
> >
> >>> unfortunately, your proposed solution does not work with javac. I get
> this
> >> in the build:
> >>
> >> Oh darn. I should have double checked.
> >> Can we at least reduce the scope of the @SuppressedWarnings by
> >> introducing a private method that just has the return call?
> >
> > Sure, what about this one:
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> >
> > Thanks
> > Christoph
> >


From david.holmes at oracle.com  Tue May 14 22:05:20 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 May 2019 08:05:20 +1000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>

Hi Christoph,

I'm very reluctant to see changes like this that the compiler folk have 
not determined are actually incorrect. That said ...

On 15/05/2019 7:03 am, Langer, Christoph wrote:
> Thanks Daniel.
> 
> Can anybody help reviewing the changes to:
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java

The introduction of the intermediate local variable seems harmless 
(though why it should be necessary is another matter).

> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java

As you note this should be ok'd by jsr166 folk so I've cc'd Martin 
Buccholz. I dislike seeing a raw type introduced here though.

> and
> src/java.management/share/classes/java/lang/management/ManagementFactory.java ?

Introducing an unchecked cast seems very crude. I'd want the core-libs 
stream experts to comment on this.

Cheers,
David
----

> Thanks
> Christoph
> 
>> -----Original Message-----
>> From: Daniel Fuchs <daniel.fuchs at oracle.com>
>> Sent: Dienstag, 14. Mai 2019 18:04
>> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
>> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
>> Cc: compiler-dev at openjdk.java.net
>> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
>> Eclipse Java Compiler
>>
>> Hi Christoph,
>>
>> That looks much better, thanks!
>> (but still not commenting on the other changes ;-))
>>
>> best regards,
>>
>> -- daniel
>>
>> On 14/05/2019 13:57, Langer, Christoph wrote:
>>> Hi Daniel,
>>>
>>>>> unfortunately, your proposed solution does not work with javac. I get
>> this
>>>> in the build:
>>>>
>>>> Oh darn. I should have double checked.
>>>> Can we at least reduce the scope of the @SuppressedWarnings by
>>>> introducing a private method that just has the return call?
>>>
>>> Sure, what about this one:
>> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
>>>
>>> Thanks
>>> Christoph
>>>
> 

From aeubanks at google.com  Tue May 14 22:57:16 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 14 May 2019 15:57:16 -0700
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
Message-ID: <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>

In test/jdk/sun/net/ftp/FtpURL.java, extendedEnabled is always true. Same
with portEnabled and pasvEnabled. Is the assumption that all current
servers support these modes? If so, why is there a bool to say those modes
are not enabled?

*From: *Daniel Fuchs <daniel.fuchs at oracle.com>
*Date: *Tue, May 14, 2019 at 9:02 AM
*To: *OpenJDK Network Dev list
*Cc: *Arthur Eubanks

Hi,
>
> Some recent test stabilization fixes had a side effect on
> two FTP tests: now that the client might use the IPv6 loopback,
> the test might fail on IPv6 only hosts if the test server
> doesn't support the extended EPSV mode, or if the client
> isn't configured to use NO_PROXY and the default proxy selector
> doesn't bypass [0:0:0:0:0:0:0:1] - as happened on my local
> machine.
>
> I'd like to push this change that fixes two of the FTP
> test recently modified to work with IPv6 addresses as an example
> of what might need to be done to get such tests working on
> IPv6 only hosts.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8223880/webrev.00/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8223880
>
> best regards,
>
> -- daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190514/84fe23d1/attachment.html>

From aeubanks at google.com  Wed May 15 02:06:13 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 14 May 2019 19:06:13 -0700
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <DB6P192MB02005FB68555804559ECC1E2DF080@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
 <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
 <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>
 <DB6P192MB02005FB68555804559ECC1E2DF080@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <CAPW48spx=Rrgur5tKE_6EzoR53ifWe=fyYXqR1qAaFbTPH9xig@mail.gmail.com>

On Tue, May 14, 2019 at 4:14 AM mark sheppard <macanaoire at hotmail.com>
wrote:

> Hi Chris,
>     yes understood,  thanks for that ... all good  :+1  ... just wanted to
> highlight how the current mechanism worked
> and
>     that on  a Windows lapper there is a potential anomaly with the
> standard platform names service with the reverse lookup scenario.
>
> regards
> Mark
>
Mark, is the +1 for a review for this change or for Mark's explanation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190514/b1dc061a/attachment.html>

From martinrb at google.com  Wed May 15 04:16:33 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 May 2019 21:16:33 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
Message-ID: <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>

I feel the same as David - reluctant to change anything.  Introducing a raw
type makes an ugly cast uglier.

*From: *David Holmes <david.holmes at oracle.com>

> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I dislike seeing a raw type introduced here though.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190514/a96a67ac/attachment.html>

From daniel.fuchs at oracle.com  Wed May 15 08:49:04 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 09:49:04 +0100
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
Message-ID: <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>

Hi Arthue,

On 14/05/2019 23:57, Arthur Eubanks wrote:
> In test/jdk/sun/net/ftp/FtpURL.java, extendedEnabled is always true. 
> Same with?portEnabled and pasvEnabled. 

Yes - I left them there as they were preexisting.
The bits that handles EPSV is a copy paste from another
test and that minimized the changes.

> Is the assumption that all 
> current servers support these modes? If so, why is there a bool to say 
> those modes are not enabled?

I have no idea. EPSV and EPRT have been introduced do
support IPv6, and are replacements for PASV and PORT
which only support IPv4. I would guess that servers
should all support these modes by now.

As to your question - my guess is that this test server
got copy & pasted in many tests and some of them might
want to disable some of these modes for testing purposes.

WRT EPSV/PASV the jdk client tries EPSV ALL first, and
if the server replies with `500 'command not understood'`
it will fallback to PASV.

Because this particular server in the test didn't support
EPSV before - it was using PASV for IPv4 addresses.
I made sure this would continue to happen - so that
what's happening on the client side doesn't change
when testing with IPv4.

PASV and PORT will not work on a machine that only has
IPv6.

best regards,

-- daniel



From macanaoire at hotmail.com  Wed May 15 09:53:53 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 15 May 2019 09:53:53 +0000
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <CAPW48spx=Rrgur5tKE_6EzoR53ifWe=fyYXqR1qAaFbTPH9xig@mail.gmail.com>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
 <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
 <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>
 <DB6P192MB02005FB68555804559ECC1E2DF080@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>,
 <CAPW48spx=Rrgur5tKE_6EzoR53ifWe=fyYXqR1qAaFbTPH9xig@mail.gmail.com>
Message-ID: <DB6P192MB02001B075D9C59ED35E5724BDF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>

Hi Arthur,
    yes all good ??   thanks

regards
Mark

________________________________
From: Arthur Eubanks <aeubanks at google.com>
Sent: Wednesday 15 May 2019 02:06
To: mark sheppard
Cc: Chris Hegarty; OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly



On Tue, May 14, 2019 at 4:14 AM mark sheppard <macanaoire at hotmail.com<mailto:macanaoire at hotmail.com>> wrote:
Hi Chris,
    yes understood,  thanks for that ... all good  :+1  ... just wanted to highlight how the current mechanism worked
and
    that on  a Windows lapper there is a potential anomaly with the standard platform names service with the reverse lookup scenario.

regards
Mark
Mark, is the +1 for a review for this change or for Mark's explanation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/2a5b0339/attachment-0001.html>

From chris.hegarty at oracle.com  Wed May 15 10:24:13 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 May 2019 11:24:13 +0100
Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6
In-Reply-To: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com>
References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com>
 <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com>
 <bbaae1c2-9417-b230-bbcb-7e941808f58b@oracle.com>
 <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com>
 <c9c3be56-48cf-914a-afc1-2974d753884b@oracle.com>
 <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com>
 <d5c29147-e69a-ffc7-6266-df670d4688d4@oracle.com>
 <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com>
 <d5eb0a83-061f-f619-487a-60839958d89e@oracle.com>
 <f2ec0460-24d8-ea9d-a28a-e8f2219b3459@oracle.com>
 <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com>
 <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com>
 <e5569564-b972-fe07-4d07-d31bbca353c2@oracle.com>
 <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com>
 <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com>
Message-ID: <62488d96-be11-c64b-c154-a2c54052176a@oracle.com>

Alex,

On 13/05/2019 22:06, Alex Menkov wrote:
> Hi Chris, Serguei,
> 
> Updated webrev:
> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/

I'm ok with this version.

> CSR (approved):
> https://bugs.openjdk.java.net/browse/JDK-8223104
> 
> Changes (vs. webrev.04):
> 
> - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared 
> setOptionsCommon function (in socketTransport.c)
>  ? the value by default is "true" on Windows and is "false" on Unix, but 
> it can be overridden, so lets set it explicitly;
> - a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is added;
> - added some comments as per Serguei request.
> 
> About scopes support - I thought that the functionality is not important 
> for debugger, but I can implement it (I'd prefer to do it by separate RFE).

Ok.

-Chris.

> --alex
> 
> On 05/11/2019 03:39, Chris Hegarty wrote:
>>
>>
>>> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote:
>>>
>>> Hi guys,
>>>
>>> We need a couple of partial reviews for this enhancement:
>>>
>>> ? - From the net-dev to check IPv6-addresses related part.
>>> ??? It does not need to be a thorough review.
>>> ??? We need another pair of eyes to check for obvious typos or misses.
>>> ??? Included Chris H. to mailing list in hope for some assistance.
>>> ??? (Chris, we need some help to find one of the IPv6 experts.)
>>>
>>> ? - From the serviceability-dev to check if compatibility
>>> ??? is not broken and nothing is missed.
>>> ??? This includes part of code that is not directly involved
>>> ??? into manipulations with the IPv4/IPv6 addresses.
>>> ??? The related spec update is tracked by a sub-task:
>>> ????? https://bugs.openjdk.java.net/browse/JDK-8221707
>>>
>>>
>>> Related CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8223104
>>>
>>> The latest webrev:
>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/
>>
>>
>> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c
>>
>> ??? 223???? if (domain == AF_INET6) {
>> ??? 224???????? int off = 0;
>> ??? 225???????? // make the socket a dual mode socket
>> ??? 226???????? setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char 
>> *)&off, sizeof(off));
>> ??? 227???? }
>> ??? 228?? }
>>
>> ?? This code is fine, but maybe you want to expand the comment to
>> ?? mention that the setsockopt may fail if IPv4 is not supported. And
>> ?? that?s OK.
>>
>> ?? I cannot find a similar setting of IPV6_V6ONLY for the unix
>> ?? equivalent. Why not, or where can it be found?
>>
>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>
>> ?? There is a lot of native code here, I skimmed over it, seems
>> ?? reasonable. There is an obvious lack of any reference to IPv6
>> ?? scopes. Can the address given to bind be an IPv6 link-local?
>> ?? If so, then the scope will need to be parsed / set appropriately.
>> ?? ( seems that the new test skips all scoped addresses? )
>>
>> -Chris.
>>

From vyommani at gmail.com  Wed May 15 10:25:06 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 15 May 2019 15:55:06 +0530
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
 <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
Message-ID: <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>

Hi Daniel,

Changes looks good to me, as you said code is copied from one test to
another, i found FtpGetContent.java where same FtpServer code is copied.
Are you planning to fix FtpGetContent.java as well  ?.

Thanks,
Vyom

On Wed, May 15, 2019 at 2:18 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthue,
>
> On 14/05/2019 23:57, Arthur Eubanks wrote:
> > In test/jdk/sun/net/ftp/FtpURL.java, extendedEnabled is always true.
> > Same with portEnabled and pasvEnabled.
>
> Yes - I left them there as they were preexisting.
> The bits that handles EPSV is a copy paste from another
> test and that minimized the changes.
>
> > Is the assumption that all
> > current servers support these modes? If so, why is there a bool to say
> > those modes are not enabled?
>
> I have no idea. EPSV and EPRT have been introduced do
> support IPv6, and are replacements for PASV and PORT
> which only support IPv4. I would guess that servers
> should all support these modes by now.
>
> As to your question - my guess is that this test server
> got copy & pasted in many tests and some of them might
> want to disable some of these modes for testing purposes.
>
> WRT EPSV/PASV the jdk client tries EPSV ALL first, and
> if the server replies with `500 'command not understood'`
> it will fallback to PASV.
>
> Because this particular server in the test didn't support
> EPSV before - it was using PASV for IPv4 addresses.
> I made sure this would continue to happen - so that
> what's happening on the client side doesn't change
> when testing with IPv4.
>
> PASV and PORT will not work on a machine that only has
> IPv6.
>
> best regards,
>
> -- daniel
>
>
>

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

From daniel.fuchs at oracle.com  Wed May 15 13:38:29 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 14:38:29 +0100
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
 <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
 <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>
Message-ID: <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>

Hi Vyom,

On 15/05/2019 11:25, Vyom Tiwari wrote:
> Hi Daniel,
> 
> Changes looks good to me,

Thanks!

> as you said code is copied from one test to 
> another, i found FtpGetContent.java where same FtpServer code is 
> copied.? Are you planning to fix FtpGetContent.java as well? ?.

Well - I wasn't intending to but it looks like a low
hanging fruit. All other tests in that directory either
do not use PASV or already support EPSV so it seems like
a low hanging fruit to bundle the same change FtpGetContent.java
and then we'll be done with it...

Here it goes...
http://cr.openjdk.java.net/~dfuchs/webrev_8223880/webrev.01/

best regards,

-- daniel


> 
> Thanks,
> Vyom


From christoph.langer at sap.com  Wed May 15 13:59:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 15 May 2019 13:59:08 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
Message-ID: <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi David, Martin,

thanks for looking into this.

Generally I share your view on this. It's not nice at all.

However, it's the only way I can see currently to get rid of the Errors in the Eclipse IDE. Maybe an idea would be to get this in but at the same time open a ticket to evaluate this code again from a compiler/spec perspective and make the according modifications?

Thanks
Christoph

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 15. Mai 2019 00:05
> To: Langer, Christoph <christoph.langer at sap.com>; Daniel Fuchs
> <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net; Martin Buchholz
> <martinrb at google.com>
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm very reluctant to see changes like this that the compiler folk have
> not determined are actually incorrect. That said ...
> 
> On 15/05/2019 7:03 am, Langer, Christoph wrote:
> > Thanks Daniel.
> >
> > Can anybody help reviewing the changes to:
> > src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> 
> The introduction of the intermediate local variable seems harmless
> (though why it should be necessary is another matter).
> 
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> 
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I dislike seeing a raw type introduced here though.
> 
> > and
> >
> src/java.management/share/classes/java/lang/management/ManagementF
> actory.java ?
> 
> Introducing an unchecked cast seems very crude. I'd want the core-libs
> stream experts to comment on this.
> 
> Cheers,
> David
> ----
> 
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> >> Sent: Dienstag, 14. Mai 2019 18:04
> >> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-
> libs-
> >> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> >> Cc: compiler-dev at openjdk.java.net
> >> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with
> the
> >> Eclipse Java Compiler
> >>
> >> Hi Christoph,
> >>
> >> That looks much better, thanks!
> >> (but still not commenting on the other changes ;-))
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 14/05/2019 13:57, Langer, Christoph wrote:
> >>> Hi Daniel,
> >>>
> >>>>> unfortunately, your proposed solution does not work with javac. I get
> >> this
> >>>> in the build:
> >>>>
> >>>> Oh darn. I should have double checked.
> >>>> Can we at least reduce the scope of the @SuppressedWarnings by
> >>>> introducing a private method that just has the return call?
> >>>
> >>> Sure, what about this one:
> >> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> >>>
> >>> Thanks
> >>> Christoph
> >>>
> >

From chris.hegarty at oracle.com  Wed May 15 14:02:32 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 May 2019 15:02:32 +0100
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
 <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
 <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>
 <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>
Message-ID: <8cbaa1e6-a2e8-9c4a-ae54-62f36c8f3798@oracle.com>

Daniel,

On 15/05/2019 14:38, Daniel Fuchs wrote:
> ...
> http://cr.openjdk.java.net/~dfuchs/webrev_8223880/webrev.01/

I think this looks ok. ( we should consolidate into a single test FTP
server at some point, but cut'n'paste is fine for now )

-Chris.

From aeubanks at google.com  Wed May 15 15:03:30 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 08:03:30 -0700
Subject: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
 literal addresses correctly
In-Reply-To: <DB6P192MB02001B075D9C59ED35E5724BDF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <CAPW48sr=6Pi498Vngn0L_+w21z+CvjeOewHk87YW+WTq=Q4DjQ@mail.gmail.com>
 <1bd1230f-044b-681c-f14f-c8fc5f53e2f0@oracle.com>
 <CAPW48soZGuP+mvkF_QkGhDo132ae5T-BcGrbk6hJ4aS5AdeBNQ@mail.gmail.com>
 <DB6P192MB0200F7B7008A57C8A78EA894DF0F0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
 <290A4FC8-DA0B-4D4D-92C7-1B8959609F22@oracle.com>
 <DB6P192MB02005FB68555804559ECC1E2DF080@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
 <CAPW48spx=Rrgur5tKE_6EzoR53ifWe=fyYXqR1qAaFbTPH9xig@mail.gmail.com>
 <DB6P192MB02001B075D9C59ED35E5724BDF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <CAPW48sqUQn3bghzJfZa_0x=1pFZYMDQrcEcY_rzwVq90696_Cw@mail.gmail.com>

Awesome, thanks.

*From: *mark sheppard <macanaoire at hotmail.com>
*Date: *Wed, May 15, 2019 at 2:53 AM
*To: *Arthur Eubanks
*Cc: *Chris Hegarty, OpenJDK Network Dev list

Hi Arthur,
>     yes all good ??   thanks
>
> regards
> Mark
>
> ------------------------------
> *From:* Arthur Eubanks <aeubanks at google.com>
> *Sent:* Wednesday 15 May 2019 02:06
> *To:* mark sheppard
> *Cc:* Chris Hegarty; OpenJDK Network Dev list
> *Subject:* Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle
> IPv6 literal addresses correctly
>
>
>
> On Tue, May 14, 2019 at 4:14 AM mark sheppard <macanaoire at hotmail.com>
> wrote:
>
> Hi Chris,
>     yes understood,  thanks for that ... all good  :+1  ... just wanted to
> highlight how the current mechanism worked
> and
>     that on  a Windows lapper there is a potential anomaly with the
> standard platform names service with the reverse lookup scenario.
>
> regards
> Mark
>
> Mark, is the +1 for a review for this change or for Mark's explanation?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/0426c6ef/attachment.html>

From chris.hegarty at oracle.com  Wed May 15 15:17:37 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 May 2019 16:17:37 +0100
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
 should be more resilient to unexpected traffic
In-Reply-To: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
References: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
Message-ID: <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>

Daniel

On 13/05/2019 19:29, Daniel Fuchs wrote:
> ...
> http://cr.openjdk.java.net/~dfuchs/webrev_8223716/webrev.00/

I think the approach of pushing this improvement, and filing a
separate issue to track the minor loosening of the constraints
is reasonable.

I believe workers should be volatile/synchronized, as it is
written and read from different threads, no?

-Chris.

From aeubanks at google.com  Wed May 15 15:17:36 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 08:17:36 -0700
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <8cbaa1e6-a2e8-9c4a-ae54-62f36c8f3798@oracle.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
 <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
 <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>
 <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>
 <8cbaa1e6-a2e8-9c4a-ae54-62f36c8f3798@oracle.com>
Message-ID: <CAPW48sqA6+t5b174Q8joYRWsiK-es_FyuWcQW4+bbgD4iGcDDg@mail.gmail.com>

Looks good.

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Wed, May 15, 2019 at 7:03 AM
*To: *Daniel Fuchs
*Cc: *OpenJDK Network Dev list

Daniel,
>
> On 15/05/2019 14:38, Daniel Fuchs wrote:
> > ...
> > http://cr.openjdk.java.net/~dfuchs/webrev_8223880/webrev.01/
>
> I think this looks ok. ( we should consolidate into a single test FTP
> server at some point, but cut'n'paste is fine for now )
>
> -Chris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/2e0fe4eb/attachment.html>

From aeubanks at google.com  Wed May 15 15:19:19 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 08:19:19 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
 <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
 <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>
Message-ID: <CAPW48sq2TOuEgVBaBCp5skjABuXmDtmVQnuF5TiOcDRrEVDmLg@mail.gmail.com>

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Tue, May 14, 2019 at 2:44 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list

Arthur,
>
> On 11 May 2019, at 11:48, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> Arthur,
>
> On 10 May 2019, at 17:37, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Sounds good.
> New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/
>
> This is almost exactly the changes we made internally to this file.
>
>
> Good that we eventually converged on the same substantive solution.
> Bad that we went in a little circle first ( though it does give an
> additional level of confidence that we ended up in a similar place).
>
> I think that this latest webrev looks good. I?ll do some testing with
> it and report back the results.
>
>
> All good. I see no issues when running various tests.
>
> -Chris.
>
> Thanks, still need one more reviewer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/ccc82777/attachment.html>

From aeubanks at google.com  Wed May 15 15:19:55 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 08:19:55 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
Message-ID: <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>

Ping.

*From: *Arthur Eubanks <aeubanks at google.com>
*Date: *Tue, May 7, 2019 at 1:36 PM
*To: *Chris Hegarty
*Cc: *OpenJDK Network Dev list

Arthur,
>>
>> On 1 May 2019, at 23:53, Arthur Eubanks <aeubanks at google.com> wrote:
>>
>> Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
>>
>>
>> I think the changes are good.
>>
>> Minor comment: after this changes, the Inet6AddressImpl class-level
>> comment is a little misleading. Maybe it would benefit from a small
>> update.
>>
>>  * If InetAddress.preferIPv6Address is true then anyLocalAddress(),
>>  * loopbackAddress(), and localHost() will return IPv6 addresses,
>>  * otherwise IPv4 addresses.
>>
> Updated the comment.
>
>>
>> In your patch queue have you got any similar-ish changes relating to
>> `anyLocalAddress`? The reason I ask ( and it may not be an immediate
>> issue ) is that it is somewhat related, but kinda masked by code in the
>> native NET_InetAddressToSockaddr function, that maps the IPv4 wildcard
>> address to the IPv6 equivalent.
>>
> I don't see any other changes that are related to Inet6AddressImpl.
>
>>
>> This change reminds me that; InetAddress getLoopbackAddress and
>> anyLocalAddress remove the need by the developer to think about the
>> particular IP version in use, as the methods should return an
>> appropriate address for the platform and environment in use. But
>> sometimes you just want the IPv4 loopback or the IPv6 loopback, etc.
>> Should we add public API points for just this?
>>
>>    Inet4Address::getIPv4LoopbackAddress
>>    Inet6Address::getIPv6LoopbackAddress
>>    Inet4Address::wildcardAddress
>>    Inet6Address::wildcardAddress
>>
> I think that makes sense. We could also refactor some of these patches to
> use those rather than specifying "::1" or {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}.
>
> New webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.01/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/118c2a3a/attachment.html>

From daniel.fuchs at oracle.com  Wed May 15 15:56:46 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 16:56:46 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48sq2TOuEgVBaBCp5skjABuXmDtmVQnuF5TiOcDRrEVDmLg@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
 <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
 <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>
 <CAPW48sq2TOuEgVBaBCp5skjABuXmDtmVQnuF5TiOcDRrEVDmLg@mail.gmail.com>
Message-ID: <a836b53c-65d7-23d6-8f65-ab2a2bf3215b@oracle.com>

On 15/05/2019 16:19, Arthur Eubanks wrote:
>>>     New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/
> 
>     All good. I see no issues when running various tests.
> 
>     -Chris.
> 
> Thanks, still need one more reviewer.

Hi Arthur,

This is not hotspot - I don't think you do :-)

But FWIW this last webrev looks good to me too.

best regards,

-- daniel


From chris.hegarty at oracle.com  Wed May 15 15:56:45 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 May 2019 16:56:45 +0100
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
Message-ID: <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>

Arthur,

> On 15 May 2019, at 16:19, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Ping.
> 
> From: Arthur Eubanks <aeubanks@ <mailto:aeubanks at google.com>google.com> wrote:
> New webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.01/ <http://cr.openjdk.java.net/~aeubanks/8223214/webrev.01/> 

You have my Review.

-Chris.

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

From aleksej.efimov at oracle.com  Wed May 15 16:07:31 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 15 May 2019 17:07:31 +0100
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
Message-ID: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>

Hi,

Another part of test fixes to address intermittent networking test 
failures can be viewed here:
http://cr.openjdk.java.net/~aefimov/8223798/00/

Could I please ask for the help to review it?

JBS:
https://bugs.openjdk.java.net/browse/JDK-8223798


With Best Regards,
Aleksei

From aeubanks at google.com  Wed May 15 16:11:24 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 09:11:24 -0700
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <a836b53c-65d7-23d6-8f65-ab2a2bf3215b@oracle.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
 <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
 <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>
 <CAPW48sq2TOuEgVBaBCp5skjABuXmDtmVQnuF5TiOcDRrEVDmLg@mail.gmail.com>
 <a836b53c-65d7-23d6-8f65-ab2a2bf3215b@oracle.com>
Message-ID: <CAPW48soRQaAUJOst+LMNRqeGBkYKoyrLFs33nooepM3+FNzc-w@mail.gmail.com>

>
> Hi Arthur,
>
> This is not hotspot - I don't think you do :-)
>
> But FWIW this last webrev looks good to me too.
>
> best regards,
>
> -- daniel
>
> I thought I always needed two people to say the change looks good. Is only
needing one reviewer a JDK policy or a net-dev policy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/1ce25f07/attachment.html>

From daniel.fuchs at oracle.com  Wed May 15 16:32:39 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 17:32:39 +0100
Subject: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in
 NetworkInterface.c if IPv4 is not supported
In-Reply-To: <CAPW48soRQaAUJOst+LMNRqeGBkYKoyrLFs33nooepM3+FNzc-w@mail.gmail.com>
References: <CAPW48srdgokFnPt_eYjDhS8Ngo16DiHMFWbiwHhdHK=NRLtgHQ@mail.gmail.com>
 <3792b38a-d5db-fcff-d4ba-1a874a16bf9f@oracle.com>
 <b1808a6f-5a2e-8ee9-957e-1a9b1876225e@oracle.com>
 <fbffef24-7765-0592-efd7-a25b686d5386@oracle.com>
 <CAPW48spGbWNa37_CuoRXRb6Uvne4cgYHF8hYBmj7Op9D_p4xFQ@mail.gmail.com>
 <2E0B719A-FC0D-432D-8E9F-4BE7B04CEA2D@oracle.com>
 <CAPW48sqa-q+FGCnJtGAkfXjgejE5G2YdMK7utZOhgcrZ7Em22w@mail.gmail.com>
 <e716d76d-6808-d5b7-dde8-383f1f058949@oracle.com>
 <CAPW48spUU2TvFBHVBPS01n0EeZm_pvh62LFPs28_pc4JeP+02g@mail.gmail.com>
 <B10623E1-E446-4DA9-BFA0-4DAF9168DE63@oracle.com>
 <B3829C17-535D-4990-AC7A-BF1885B34EC6@oracle.com>
 <CAPW48sq2TOuEgVBaBCp5skjABuXmDtmVQnuF5TiOcDRrEVDmLg@mail.gmail.com>
 <a836b53c-65d7-23d6-8f65-ab2a2bf3215b@oracle.com>
 <CAPW48soRQaAUJOst+LMNRqeGBkYKoyrLFs33nooepM3+FNzc-w@mail.gmail.com>
Message-ID: <c9d3f483-c9a5-c9ff-6c84-cae345fe26d0@oracle.com>

Hi Arthur,

On 15/05/2019 17:11, Arthur Eubanks wrote:
> I thought I always needed two people to say the change looks good. Is 
> only needing one reviewer a JDK policy or a net-dev policy?

It depends on the project/group rules.
AFAIK you only need two reviewers when you contribute
changes to hotspot.

best regards,

-- daniel

From daniel.fuchs at oracle.com  Wed May 15 16:59:47 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 17:59:47 +0100
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
In-Reply-To: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
References: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
Message-ID: <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>

Hi Aleksei,

On 15/05/2019 17:07, Aleks Efimov wrote:
> Hi,
> 
> Another part of test fixes to address intermittent networking test 
> failures can be viewed here:
> http://cr.openjdk.java.net/~aefimov/8223798/00/

Socket_getInputStream_read.java:
Socket_getOutputStream_write.java:

I think you could simply move the initialization of
lh above the line that creates the server socket
and bind the server socket to lh instead. That
would keep the changes minimal.

The rest looks good - but there are a few long lines.
If you can break them before pushing that would be good.

best regards,

-- daniel

> 
> Could I please ask for the help to review it?
> 
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8223798
> 
> 
> With Best Regards,
> Aleksei


From vyommani at gmail.com  Wed May 15 17:06:49 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 15 May 2019 22:36:49 +0530
Subject: RFR: 8223880: Update sun/net/ftp/FtpURL.java and
 sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
In-Reply-To: <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>
References: <ebf6c33e-5594-1132-25e8-464b13616694@oracle.com>
 <CAPW48sq7kM50Q_-hFM=AzDA48OLVmAJWYQvWvGzGtjuTmEf4VA@mail.gmail.com>
 <62e8c20e-7355-73fe-2e2e-6598a70e71ba@oracle.com>
 <CAKysZ8yY8x0xS2FxfpJ3mf4h8bpZdYdN62x__Ym6zR5r2nnjeQ@mail.gmail.com>
 <d8a2c309-8f81-12c1-3ac4-eb5d1b90b159@oracle.com>
Message-ID: <CAKysZ8ygh3a1caq_e7+z18Y+wau1k0xZCKw_E3rtkhzJvbowgg@mail.gmail.com>

Hi Daniel,

latest change looks good to me.

Even  i wanted to remove duplicate "FtpServer code" that we had copy and
pasted but somehow I did not got time do it.

Thanks,
Vyom

On Wed, May 15, 2019 at 7:08 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Vyom,
>
> On 15/05/2019 11:25, Vyom Tiwari wrote:
> > Hi Daniel,
> >
> > Changes looks good to me,
>
> Thanks!
>
> > as you said code is copied from one test to
> > another, i found FtpGetContent.java where same FtpServer code is
> > copied.  Are you planning to fix FtpGetContent.java as well  ?.
>
> Well - I wasn't intending to but it looks like a low
> hanging fruit. All other tests in that directory either
> do not use PASV or already support EPSV so it seems like
> a low hanging fruit to bundle the same change FtpGetContent.java
> and then we'll be done with it...
>
> Here it goes...
> http://cr.openjdk.java.net/~dfuchs/webrev_8223880/webrev.01/
>
> best regards,
>
> -- daniel
>
>
> >
> > Thanks,
> > Vyom
>
>

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

From aleksej.efimov at oracle.com  Wed May 15 17:41:59 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 15 May 2019 18:41:59 +0100
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
In-Reply-To: <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>
References: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
 <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>
Message-ID: <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>

Hi Daniel,

Thanks for the review. I've modified Socket_getInputStream_[read|write] 
to follow your suggestion:
-??????????? ServerSocket ss = new ServerSocket(0);
 ???????????? InetAddress lh = InetAddress.getLocalHost();
+??????????? ServerSocket ss = new ServerSocket(0, 0, lh);

Also I've broke the long lines in few places. Will push the changes shortly.

With Best Regards,
Aleksei

On 15/05/2019 17:59, Daniel Fuchs wrote:
> Hi Aleksei,
>
> On 15/05/2019 17:07, Aleks Efimov wrote:
>> Hi,
>>
>> Another part of test fixes to address intermittent networking test 
>> failures can be viewed here:
>> http://cr.openjdk.java.net/~aefimov/8223798/00/
>
> Socket_getInputStream_read.java:
> Socket_getOutputStream_write.java:
>
> I think you could simply move the initialization of
> lh above the line that creates the server socket
> and bind the server socket to lh instead. That
> would keep the changes minimal.
>
> The rest looks good - but there are a few long lines.
> If you can break them before pushing that would be good.
>
> best regards,
>
> -- daniel
>
>>
>> Could I please ask for the help to review it?
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8223798
>>
>>
>> With Best Regards,
>> Aleksei
>


From daniel.fuchs at oracle.com  Wed May 15 17:48:14 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 18:48:14 +0100
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
In-Reply-To: <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>
References: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
 <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>
 <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>
Message-ID: <2903e458-8386-ea52-1814-692a2aea0153@oracle.com>

On 15/05/2019 18:41, Aleks Efimov wrote:
> Hi Daniel,
> 
> Thanks for the review. I've modified Socket_getInputStream_[read|write] 
> to follow your suggestion:
> -??????????? ServerSocket ss = new ServerSocket(0);
>  ???????????? InetAddress lh = InetAddress.getLocalHost();
> +??????????? ServerSocket ss = new ServerSocket(0, 0, lh);
> 
> Also I've broke the long lines in few places. Will push the changes 
> shortly.

Thanks Aleksej. LGTM.

> 
> With Best Regards,
> Aleksei

From daniel.fuchs at oracle.com  Wed May 15 17:49:42 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 May 2019 18:49:42 +0100
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
 should be more resilient to unexpected traffic
In-Reply-To: <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>
References: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
 <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>
Message-ID: <75d58c27-6f34-61c2-4fe5-229fb384c63d@oracle.com>

On 15/05/2019 16:17, Chris Hegarty wrote:
> I believe workers should be volatile/synchronized, as it is
> written and read from different threads, no?

Thanks Chris.

workers is a concurrent queue, but the variable should
be final. I'll do it before pushing.

best regards,

-- daniel

> 
> -Chris.


From vyommani at gmail.com  Wed May 15 17:51:12 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 15 May 2019 23:21:12 +0530
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
In-Reply-To: <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>
References: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
 <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>
 <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>
Message-ID: <CAKysZ8zJJNzWg_-faza6FHVxcXPQyUFzW=+ZWzMG6Q7ir2dYkg@mail.gmail.com>

Hi Aleks,
latest changes looks good to me .
Thanks,
Vyom

On Wed, May 15, 2019 at 11:12 PM Aleks Efimov <aleksej.efimov at oracle.com>
wrote:

> Hi Daniel,
>
> Thanks for the review. I've modified Socket_getInputStream_[read|write]
> to follow your suggestion:
> -            ServerSocket ss = new ServerSocket(0);
>               InetAddress lh = InetAddress.getLocalHost();
> +            ServerSocket ss = new ServerSocket(0, 0, lh);
>
> Also I've broke the long lines in few places. Will push the changes
> shortly.
>
> With Best Regards,
> Aleksei
>
> On 15/05/2019 17:59, Daniel Fuchs wrote:
> > Hi Aleksei,
> >
> > On 15/05/2019 17:07, Aleks Efimov wrote:
> >> Hi,
> >>
> >> Another part of test fixes to address intermittent networking test
> >> failures can be viewed here:
> >> http://cr.openjdk.java.net/~aefimov/8223798/00/
> >
> > Socket_getInputStream_read.java:
> > Socket_getOutputStream_write.java:
> >
> > I think you could simply move the initialization of
> > lh above the line that creates the server socket
> > and bind the server socket to lh instead. That
> > would keep the changes minimal.
> >
> > The rest looks good - but there are a few long lines.
> > If you can break them before pushing that would be good.
> >
> > best regards,
> >
> > -- daniel
> >
> >>
> >> Could I please ask for the help to review it?
> >>
> >> JBS:
> >> https://bugs.openjdk.java.net/browse/JDK-8223798
> >>
> >>
> >> With Best Regards,
> >> Aleksei
> >
>
>

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

From aleksej.efimov at oracle.com  Wed May 15 18:30:58 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 15 May 2019 19:30:58 +0100
Subject: [teststabilization] RFR: 8223798 : Replace wildcard address with
 loopback or local host in tests - part 7
In-Reply-To: <CAKysZ8zJJNzWg_-faza6FHVxcXPQyUFzW=+ZWzMG6Q7ir2dYkg@mail.gmail.com>
References: <21f21158-1022-9635-ee7f-31715bc3c28c@oracle.com>
 <17be03cc-8db3-4cea-00fc-6921ecd47f2a@oracle.com>
 <c943f71f-519c-ce95-153c-7fb0ff12b590@oracle.com>
 <CAKysZ8zJJNzWg_-faza6FHVxcXPQyUFzW=+ZWzMG6Q7ir2dYkg@mail.gmail.com>
Message-ID: <9f421a45-9a35-043e-c31b-33ce02b8c06a@oracle.com>

Vyom, Daniel,

Thanks for your reviews!

Best Regards,
Aleksei

On 15/05/2019 18:51, Vyom Tiwari wrote:
> Hi Aleks,
> latest changes looks good to me .
> Thanks,
> Vyom
>
> On Wed, May 15, 2019 at 11:12 PM Aleks Efimov 
> <aleksej.efimov at oracle.com <mailto:aleksej.efimov at oracle.com>> wrote:
>
>     Hi Daniel,
>
>     Thanks for the review. I've modified
>     Socket_getInputStream_[read|write]
>     to follow your suggestion:
>     -??????????? ServerSocket ss = new ServerSocket(0);
>     ????????????? InetAddress lh = InetAddress.getLocalHost();
>     +??????????? ServerSocket ss = new ServerSocket(0, 0, lh);
>
>     Also I've broke the long lines in few places. Will push the
>     changes shortly.
>
>     With Best Regards,
>     Aleksei
>
>     On 15/05/2019 17:59, Daniel Fuchs wrote:
>     > Hi Aleksei,
>     >
>     > On 15/05/2019 17:07, Aleks Efimov wrote:
>     >> Hi,
>     >>
>     >> Another part of test fixes to address intermittent networking test
>     >> failures can be viewed here:
>     >> http://cr.openjdk.java.net/~aefimov/8223798/00/
>     >
>     > Socket_getInputStream_read.java:
>     > Socket_getOutputStream_write.java:
>     >
>     > I think you could simply move the initialization of
>     > lh above the line that creates the server socket
>     > and bind the server socket to lh instead. That
>     > would keep the changes minimal.
>     >
>     > The rest looks good - but there are a few long lines.
>     > If you can break them before pushing that would be good.
>     >
>     > best regards,
>     >
>     > -- daniel
>     >
>     >>
>     >> Could I please ask for the help to review it?
>     >>
>     >> JBS:
>     >> https://bugs.openjdk.java.net/browse/JDK-8223798
>     >>
>     >>
>     >> With Best Regards,
>     >> Aleksei
>     >
>
>
>
> -- 
> Thanks,
> Vyom

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

From aeubanks at google.com  Wed May 15 23:24:22 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 16:24:22 -0700
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java
 in IPv6 only environment
Message-ID: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>

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

In https://bugs.openjdk.java.net/browse/JDK-8220673, I missed
skipping test/jdk/java/net/NetworkInterface/IPv4Only.java when running in
an IPv6 only environment. It should have a call to
IPSupport.throwSkippedExceptionIfNonOperational().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/8aad9de9/attachment-0001.html>

From macanaoire at hotmail.com  Wed May 15 23:35:31 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 15 May 2019 23:35:31 +0000
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
 should be more resilient to unexpected traffic
In-Reply-To: <75d58c27-6f34-61c2-4fe5-229fb384c63d@oracle.com>
References: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
 <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>,
 <75d58c27-6f34-61c2-4fe5-229fb384c63d@oracle.com>
Message-ID: <DB6P192MB02001D415D715412E6DF5DC6DF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>

Hi Daniel,
  a little feedback on the test and some observations.
was curious about this test, mainly that debug wasn't synchronized
and expected to see interleaved output from clients and servers.
So ran the test ? had look at the output, which wasn't interleaved
and totals all seemed to matched


as I understand it the test outline is that
create Server
accept client connection
create Worker for connection
start worker

create 5 clients
create HttpUrlConnection to test server
send 20 requests

should see total 100 requests
20 from each client and 20 received by each worker

On looking at the output a little closer things seemed a little off
or my observations maybe wrong. Each of the workers i.e. the client
handlers in the server didn't receive 20 request but a random number
of requests. This seems to exhibit some of the pathology of the original bug ?

Ran the test multiple times and a total of 100 requests received but randomly distributed across
the workers

To observe the client side output I amended test constructor to take an  int clientId and used that
in that clients debug output.

FWIW attached in a file with analysis of a few test runs output.

regards
Mark


msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests
$ /cygdrive/c/Development/jdk-installs/jdk-12/bin/java MultiThreadedHttpUrlConnectionTest > MTHUCT-4.out?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ more MTHUCT-4.out?
server: calling accept.?
server: return accept.?
server: Started worker 0?
server: calling accept.?
server: return accept.?
worker 0: Read request from client (162 bytes).?
server: Started worker 1?
server: calling accept.?
server: return accept.?
worker 1: Read request from client (162 bytes).?
server: Started worker 2?
server: calling accept.?
server: return accept.?
server: Started worker 3?
server: calling accept.?
server: return accept.?
worker 2: Read request from client (162 bytes).?
server: Started worker 4?
server: calling accept.?
client 0: read 11 bytes?
client 3: read 11 bytes?
client 1: read 11 bytes?
worker 3: Read request from client (162 bytes).?
worker 0: Read request from client (162 bytes).?
worker 2: Read request from client (162 bytes).?
worker 1: Read request from client (162 bytes).?
worker 4: Read request from client (162 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
client 1: read 11 bytes?
client 0: read 11 bytes?
worker 2: Read request from client (162 bytes).?
worker 0: Read request from client (163 bytes).?
worker 1: Read request from client (162 bytes).?
worker 3: Read request from client (163 bytes).?
client 4: read 11 bytes?
client 1: read 11 bytes?
client 3: read 11 bytes?
worker 1: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
client 0: read 11 bytes?
client 4: read 11 bytes?
client 1: read 11 bytes?
worker 3: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
client 4: read 11 bytes?
client 3: read 11 bytes?
client 0: read 11 bytes?
client 1: read 11 bytes?
worker 1: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
client 4: read 11 bytes?
client 3: read 11 bytes?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 2: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
client 4: read 11 bytes?
client 3: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 0: read 11 bytes?
worker 2: Read request from client (163 bytes).?
client 1: read 11 bytes?
client 4: read 11 bytes?
client 3: read 11 bytes?
worker 3: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
client 0: read 11 bytes?
client 1: read 11 bytes?
client 3: read 11 bytes?
client 4: read 11 bytes?
worker 3: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 0: read 11 bytes?
client 3: read 11 bytes?
client 1: read 11 bytes?
client 4: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
client 0: read 11 bytes?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
client 0: read 11 bytes?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
client 0: read 11 bytes?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
client 3: read 11 bytes?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 4: read 11 bytes?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 2: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 4: read 11 bytes?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
client 4: read 11 bytes?
worker 3: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 3: read 11 bytes?
client 0: read 11 bytes?
worker 1: Read request from client (163 bytes).?
client 4: read 11 bytes?
worker 2: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
client 1: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 0: read 11 bytes?
client 3: read 11 bytes?
worker 1: Read request from client (163 bytes).?
client 4: read 11 bytes?
worker 2: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
client 1: read 11 bytes?
client 0: read 11 bytes?
client 3: read 11 bytes?
worker 0: Read request from client (163 bytes).?
worker 2: Read request from client (163 bytes).?
worker 3: Read request from client (163 bytes).?
worker 1: Read request from client (163 bytes).?
client 0: read 11 bytes?
worker 2: Read request from client (163 bytes).?
client 3: read 11 bytes?
client: end - PT0.110116S?
client 1: read 11 bytes?
client 0: read 11 bytes?
client: end - PT0.1141757S?
worker 1: Read request from client (163 bytes).?
client 1: read 11 bytes?
client: end - PT0.1141736S?
client 2: read 11 bytes?
client 4: read 11 bytes?
worker 0: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
worker 0: Read request from client (163 bytes).?
client 2: read 11 bytes?
client 4: read 11 bytes?
client: end - PT0.1164921S?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
worker 4: Read request from client (163 bytes).?
client 2: read 11 bytes?
client: end - PT0.1238189S?
Connections = 5?
Requests = 100?
Connection count = 5 Request count = 100?
server: STE?
server: Shuting down.?
worker: 4: Shutdown?
worker: 0: Shutdown?
worker: 1: Shutdown?
worker: 4 end - PT20.0052845S?
worker: 2: Shutdown?
worker: 3: Shutdown?
worker: 0 end - PT20.0111739S?
worker: 3 end - PT20.0097619S?
worker: 1 end - PT20.0113868S?
worker: 2 end - PT20.0108762S?
main thread end - PT20.0743989S?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "worker 0: Read" MTHUCT-4.out | wc?
     21     168    1029?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "worker 1: Read" MTHUCT-4.out | wc?
     21     168    1029?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "worker 2: Read" MTHUCT-4.out | wc?
     21     168    1029?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "worker 3: Read" MTHUCT-4.out | wc?
     18     144     882?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "worker 4: Read" MTHUCT-4.out | wc?
     19     152     931?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 4: Read" MTHUCT-4.out | wc?
      0       0       0?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 4: read" MTHUCT-4.out | wc?
     20     100     500?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 0: read" MTHUCT-4.out | wc?
     20     100     500?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 1: read" MTHUCT-4.out | wc?
     20     100     500?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 2: read" MTHUCT-4.out | wc?
     20     100     500?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 3: read" MTHUCT-4.out | wc?
     20     100     500?
?
msheppard at MARKS-LAPTOP /cygdrive/c/Users/msheppard/eclipse-workspace/JDK-Tests?
$ grep  "client 4: read" MTHUCT-4.out | wc?
     20     100     500

________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Wednesday 15 May 2019 17:49
To: Chris Hegarty; OpenJDK Network Dev list
Subject: Re: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic

On 15/05/2019 16:17, Chris Hegarty wrote:
> I believe workers should be volatile/synchronized, as it is
> written and read from different threads, no?

Thanks Chris.

workers is a concurrent queue, but the variable should
be final. I'll do it before pushing.

best regards,

-- daniel

>
> -Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/0255613c/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MultiThreadedHttpUrlConnectionTest.txt
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/0255613c/MultiThreadedHttpUrlConnectionTest-0001.txt>

From aeubanks at google.com  Thu May 16 00:45:18 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 17:45:18 -0700
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
 assumes IPv4 is always available
Message-ID: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>

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

test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
NetworkConfiguration.probe().ip4MulticastInterfaces().iterator() always has
at least one NetworkInterface. Instead it should do something like the IPv6
code right after it where it checks that the iterator is not empty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/e276da56/attachment.html>

From aeubanks at google.com  Thu May 16 00:46:31 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 15 May 2019 17:46:31 -0700
Subject: [ipv6]: 8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java
 assume IPv4 is available
Message-ID: <CAPW48sqHBCH1E0vX7ddXBx=pASjw+_=mdWQbeuznZo2hZcEz7A@mail.gmail.com>

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

test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java both assume that IPv4 is
available. They will currently bail if IPv6 is not available. They should
also bail if IPv4 is not available.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190515/24726957/attachment.html>

From Alan.Bateman at oracle.com  Thu May 16 06:48:46 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 07:48:46 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
Message-ID: <8b6a9cf1-0d1d-eb13-fb6e-d0eda7f1a464@oracle.com>

On 16/05/2019 01:45, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224019
> webrev: http://cr.openjdk.java.net/~aeubanks/8224019/webrev.00/index.html
>
> test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java 
> assumes 
> NetworkConfiguration.probe().ip4MulticastInterfaces().iterator() 
> always has at least one NetworkInterface. Instead it should do 
> something like the IPv6 code right after it where it checks that the 
> iterator is not empty.
I think this test will require other changes to do what you want. In 
particular, expectionTests should be run if there is IPv4 or IPv6 
available. It might be that expectionTests needs the family agnostic 
tests split out, or maybe it needs parameter to indicate the family and 
multicast groups to use.

-Alan.

From aoqi at loongson.cn  Thu May 16 07:41:36 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Thu, 16 May 2019 15:41:36 +0800
Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770
Message-ID: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>

Hi,

I found build is failed on CentOS 7.6, because of loop initial
declarations. Could I please get reviews for this?

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

Webrev:
http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/

Tested:
linux-x86_64-server-release tier1

Thanks,
Ao Qi

From daniel.fuchs at oracle.com  Thu May 16 09:19:23 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 10:19:23 +0100
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
 should be more resilient to unexpected traffic
In-Reply-To: <DB6P192MB02001D415D715412E6DF5DC6DF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
References: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
 <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>
 <75d58c27-6f34-61c2-4fe5-229fb384c63d@oracle.com>
 <DB6P192MB02001D415D715412E6DF5DC6DF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>
Message-ID: <addcd9cb-acff-26bb-3d35-a7981c0c64db@oracle.com>

Hi Mark,

AFAIU the test wants to verify that connections are reused.
It does that by creating N (N=5) threads that will hammer
at the server concurrently.

Because there are N threads, then there can't be more than
N concurrent requests, and therefore there should not be
more than N connections and therefore N workers.

What we observe is that from time to time the server receives
N+1 connections. It happens very infrequently - but I've seen it
a couple of times.

When that happens - I usually that the 6th connection is created
much later in the game - and by that time one of the other connections
(usually worker 0) no longer seems to receive anything.

So for some reason one connection has been closed, and a
new one has been created to take up the load.
I have yet not clue why that happens, and JDK-8223783 has
been logged to followup on this.

In the mean time I modified the test to not fail but
print a warning when N+1 connections are created when N are
expected.

best regards,

-- daniel


On 16/05/2019 00:35, mark sheppard wrote:
> Hi Daniel,
>  ? a little feedback on the test and some observations.
> was curious about this test, mainly that debug wasn't synchronized
> and expected to see interleaved output from clients and servers.
> So ran the test ? had look at the output, which wasn't interleaved
> and totals all seemed to matched
> 
> 
> as I understand it the test outline is that
> create Server
> accept client connection
> create Worker for connection
> start worker
> 
> create 5 clients
> create HttpUrlConnection to test server
> send 20 requests
> 
> should see total 100 requests
> 20 from each client and 20 received by each worker
> 
> On looking at the output a little closer things seemed a little off
> or my observations maybe wrong. Each of the workers i.e. the client
> handlers in the server didn't receive 20 request but a random number
> of requests. This seems to exhibit some of the pathology of the original 
> bug ?
> 
> Ran the test multiple times and a total of 100 requests received but 
> randomly distributed across
> the workers
> 
> To observe the client side output I amended test constructor to take an  
> int clientId and used that
> in that clients debug output.
> 
> FWIW attached in a file with analysis of a few test runs output.
> 
> regards
> Mark

From daniel.fuchs at oracle.com  Thu May 16 09:41:03 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 10:41:03 +0100
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
Message-ID: <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>

Hi Ao Qi,

I'm adding serviceability-dev, since this is for jdwp.

The proposed changes look good to me - but please get
someone from the serviceability team to review this.

best regards,

-- daniel


On 16/05/2019 08:41, Ao Qi wrote:
> Hi,
> 
> I found build is failed on CentOS 7.6, because of loop initial
> declarations. Could I please get reviews for this?
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8224028
> 
> Webrev:
> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
> 
> Tested:
> linux-x86_64-server-release tier1
> 
> Thanks,
> Ao Qi
> 


From daniel.fuchs at oracle.com  Thu May 16 09:43:43 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 10:43:43 +0100
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
In-Reply-To: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
Message-ID: <5e9b4315-34f5-4454-2e95-28be911db0c9@oracle.com>

Hi Arthur,

Looks good to me. Reviewed.

best regards,

-- daniel

On 16/05/2019 00:24, Arthur Eubanks wrote:
> webrev: http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8224014
> 
> In https://bugs.openjdk.java.net/browse/JDK-8220673, I missed
> skipping test/jdk/java/net/NetworkInterface/IPv4Only.java when running 
> in an IPv6 only environment. It should have a call to 
> IPSupport.throwSkippedExceptionIfNonOperational().


From daniel.fuchs at oracle.com  Thu May 16 09:52:42 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 10:52:42 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
Message-ID: <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>

Hi Arthur,

Shouldn't there be a version of
  221             exceptionTests(nif);
that works with IPv6?

If no machine has IPv4 available, then these exceptions
won't be tested any more.

I suspect the test made the assumption that IPv4 was always available,
and therefore testing exceptions with IPv4 addresses was sufficient.
Now if IPv4 is not available, then maybe those exceptional
cases should be tested with IPv6 instead?

(Note: you can log a follow-up issue if you don't want to tackle
  that immediately)

best regards,

-- daniel


On 16/05/2019 01:45, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224019
> webrev: http://cr.openjdk.java.net/~aeubanks/8224019/webrev.00/index.html
> 
> test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java 
> assumes NetworkConfiguration.probe().ip4MulticastInterfaces().iterator() 
> always has at least one NetworkInterface. Instead it should do something 
> like the IPv6 code right after it where it checks that the iterator is 
> not empty.


From daniel.fuchs at oracle.com  Thu May 16 09:56:42 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 10:56:42 +0100
Subject: [ipv6]: 8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java
 assume IPv4 is available
In-Reply-To: <CAPW48sqHBCH1E0vX7ddXBx=pASjw+_=mdWQbeuznZo2hZcEz7A@mail.gmail.com>
References: <CAPW48sqHBCH1E0vX7ddXBx=pASjw+_=mdWQbeuznZo2hZcEz7A@mail.gmail.com>
Message-ID: <e0d1eb24-c650-8b90-26a2-518a70849273@oracle.com>

Hi Arthur,

Looks good to me!

best regards,

-- daniel

On 16/05/2019 01:46, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224018
> webrev: http://cr.openjdk.java.net/~aeubanks/8224018/webrev.00/
> 
> test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java both assume that IPv4 is 
> available. They will currently bail if IPv6 is not available. They 
> should also bail if IPv4 is not available.
> 


From serguei.spitsyn at oracle.com  Thu May 16 09:59:07 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 16 May 2019 02:59:07 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
Message-ID: <9bf0741f-d480-2835-5077-ada1228caed4@oracle.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/499b807b/attachment.html>

From chris.hegarty at oracle.com  Thu May 16 10:09:31 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 May 2019 11:09:31 +0100
Subject: [ipv6]: 8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java
 assume IPv4 is available
In-Reply-To: <e0d1eb24-c650-8b90-26a2-518a70849273@oracle.com>
References: <CAPW48sqHBCH1E0vX7ddXBx=pASjw+_=mdWQbeuznZo2hZcEz7A@mail.gmail.com>
 <e0d1eb24-c650-8b90-26a2-518a70849273@oracle.com>
Message-ID: <0EA8D058-E81D-4D39-B82A-FE2090E3AFC7@oracle.com>

+1

-Chris.

> On 16 May 2019, at 10:56, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Arthur,
> 
> Looks good to me!
> 
> best regards,
> 
> -- daniel
> 
> On 16/05/2019 01:46, Arthur Eubanks wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8224018
>> webrev: http://cr.openjdk.java.net/~aeubanks/8224018/webrev.00/
>> test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java both assume that IPv4 is available. They will currently bail if IPv6 is not available. They should also bail if IPv4 is not available.
> 


From chris.hegarty at oracle.com  Thu May 16 10:52:37 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 May 2019 11:52:37 +0100
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
In-Reply-To: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
Message-ID: <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>

Arthur,

> On 16 May 2019, at 00:24, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> webrev: http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/ <http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8224014 <https://bugs.openjdk.java.net/browse/JDK-8224014>
> 
> In https://bugs.openjdk.java.net/browse/JDK-8220673 <https://bugs.openjdk.java.net/browse/JDK-8220673>, I missed 
> skipping test/jdk/java/net/NetworkInterface/IPv4Only.java when running in an IPv6 only environment. It should have a call to IPSupport.throwSkippedExceptionIfNonOperational().

After the change for 8223532 in NetworkInterface.c, it is no longer
required that AF_INET sockets be able to be created, coupled with
-Djava.net.preferIPv4Stack=true, enumInterfaces may return NULL, which
in turn bubbles up to the Java layer, in this case getNetworkInterfaces,
as null ( rather than a collection containing the interfaces ).

The specification for NetworkInterface::getNetworkInterfaces guarantees
that there be at least one element in the returned collection, but there
cannot be since the system is mis-configured ( the underlying platform
is IPv6-only coupled with -Djava.net.preferIPv4Stack=true ). The only
sensible thing for the NetworkInterface implementation to do is to throw
an exception ( which is perfectly fine as per its specification,
"java.net.SocketException: No network interfaces configured" ).

Rather than skipping the test, which will clearly work, an alternative
is to ensure that an exception is thrown for this case, e.g.

    if (IPSupport.hasIPv4()) {
        out.println("Testing IPv4");
        Enumeration<NetworkInterface> nifs = NetworkInterface.getNetworkInterfaces();
        while (nifs.hasMoreElements()) {
            NetworkInterface nif = nifs.nextElement();
            Enumeration<InetAddress> addrs = nif.getInetAddresses();
            while (addrs.hasMoreElements()) {
               InetAddress hostAddr = addrs.nextElement();
               if ( hostAddr instanceof Inet6Address ){
                    throw new RuntimeException( "NetworkInterfaceV6List failed - found v6 address " + hostAddr.getHostAddress() );
               }
            }
        }
    } else {
        // No platform IPv4 support & -Djava.net.preferIPv4Stack=true
        out.println("Testing without IPv4 support");
        try {
            NetworkInterface.getNetworkInterfaces();
        } catch (SocketException expected) {
            out.println("caught expected exception: " + expected);
        }

        try {
            NetworkInterface.networkInterfaces();
        } catch (SocketException expected) {
            out.println("caught expected exception: " + expected);
        }
    }

-Chris.

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

From macanaoire at hotmail.com  Thu May 16 11:40:43 2019
From: macanaoire at hotmail.com (mark sheppard)
Date: Thu, 16 May 2019 11:40:43 +0000
Subject: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java
 should be more resilient to unexpected traffic
In-Reply-To: <addcd9cb-acff-26bb-3d35-a7981c0c64db@oracle.com>
References: <6d2cbe94-77ba-95d1-335e-da6a6d0ddbf9@oracle.com>
 <ebfe89b2-bdfe-4eb3-0ba5-6c24c5df27e2@oracle.com>
 <75d58c27-6f34-61c2-4fe5-229fb384c63d@oracle.com>
 <DB6P192MB02001D415D715412E6DF5DC6DF090@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>,
 <addcd9cb-acff-26bb-3d35-a7981c0c64db@oracle.com>
Message-ID: <DB6P192MB0200CBD3E1233872870505BEDF0A0@DB6P192MB0200.EURP192.PROD.OUTLOOK.COM>


Hi Daniel,
     thanks for the reply and clarifications
apologies for the distraction

regards
Mark

________________________________
From: Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Thursday 16 May 2019 09:19
To: mark sheppard; Chris Hegarty; OpenJDK Network Dev list
Subject: Re: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic

Hi Mark,

AFAIU the test wants to verify that connections are reused.
It does that by creating N (N=5) threads that will hammer
at the server concurrently.

Because there are N threads, then there can't be more than
N concurrent requests, and therefore there should not be
more than N connections and therefore N workers.

What we observe is that from time to time the server receives
N+1 connections. It happens very infrequently - but I've seen it
a couple of times.

When that happens - I usually that the 6th connection is created
much later in the game - and by that time one of the other connections
(usually worker 0) no longer seems to receive anything.

So for some reason one connection has been closed, and a
new one has been created to take up the load.
I have yet not clue why that happens, and JDK-8223783 has
been logged to followup on this.

In the mean time I modified the test to not fail but
print a warning when N+1 connections are created when N are
expected.

best regards,

-- daniel


On 16/05/2019 00:35, mark sheppard wrote:
> Hi Daniel,
>    a little feedback on the test and some observations.
> was curious about this test, mainly that debug wasn't synchronized
> and expected to see interleaved output from clients and servers.
> So ran the test ? had look at the output, which wasn't interleaved
> and totals all seemed to matched
>
>
> as I understand it the test outline is that
> create Server
> accept client connection
> create Worker for connection
> start worker
>
> create 5 clients
> create HttpUrlConnection to test server
> send 20 requests
>
> should see total 100 requests
> 20 from each client and 20 received by each worker
>
> On looking at the output a little closer things seemed a little off
> or my observations maybe wrong. Each of the workers i.e. the client
> handlers in the server didn't receive 20 request but a random number
> of requests. This seems to exhibit some of the pathology of the original
> bug ?
>
> Ran the test multiple times and a total of 100 requests received but
> randomly distributed across
> the workers
>
> To observe the client side output I amended test constructor to take an
> int clientId and used that
> in that clients debug output.
>
> FWIW attached in a file with analysis of a few test runs output.
>
> regards
> Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/cb869b93/attachment.html>

From daniel.fuchs at oracle.com  Thu May 16 12:23:13 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 May 2019 13:23:13 +0100
Subject: [teststabilization] RFR: 8223856: Replace wildcard address with
 loopback or local host in tests - part 8
Message-ID: <2302a02f-5f7a-2c9d-49c1-758b5fa85573@oracle.com>

Hi,

Please find below a fix for [1]:
8223856: Replace wildcard address with loopback or local host in
          tests - part 8

http://cr.openjdk.java.net/~dfuchs/webrev_8223856/webrev.00/index.html

Some of the test failures weren't all attributable to the use
of the wildcard: in some cases tests make assumptions that
are not guaranteed to be true - e.g. given two different
interfaces `i1` and `i2` you may not assume that because you
can bind to i1 with port `p`, ephemerally allocated, you should
also be able to bind to `i2` with the same port `p`.

In such a case I have taken the liberty to add a retry mechanism,
(that is: try again the whole thing) in the hope
of decreasing the probability that someone else might
be again bound to the new ephemeral port on the other interface.

best regards,

-- daniel

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

From david.holmes at oracle.com  Thu May 16 12:30:29 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 May 2019 22:30:29 +1000
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
Message-ID: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>

What compiler was used here? We shouldn't be using anything that doesn't 
handle loop variable declarations!

Thanks,
David

On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
> Hi Ao Qi,
> 
> I'm adding serviceability-dev, since this is for jdwp.
> 
> The proposed changes look good to me - but please get
> someone from the serviceability team to review this.
> 
> best regards,
> 
> -- daniel
> 
> 
> On 16/05/2019 08:41, Ao Qi wrote:
>> Hi,
>>
>> I found build is failed on CentOS 7.6, because of loop initial
>> declarations. Could I please get reviews for this?
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8224028
>>
>> Webrev:
>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>>
>> Tested:
>> linux-x86_64-server-release tier1
>>
>> Thanks,
>> Ao Qi
>>
> 

From aoqi at loongson.cn  Thu May 16 13:41:12 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Thu, 16 May 2019 21:41:12 +0800
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
Message-ID: <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>

Hi Serguei,

I saw your email [1], but I didn't receive it yet. Thanks for your
review! I updated:

http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/

On Thu, May 16, 2019 at 8:30 PM David Holmes <david.holmes at oracle.com> wrote:
>
> What compiler was used here? We shouldn't be using anything that doesn't
> handle loop variable declarations!

The compiler I used is gcc 4.8.5. This machine is used for testing
jdk/jdk for months. As far as I remember, loop variable declarations
issue never been found. If gcc 4.8.5 is not a supported compiler, I
think we should update building doc [2].

>
> Thanks,
> David
>
> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
> > Hi Ao Qi,
> >
> > I'm adding serviceability-dev, since this is for jdwp.
> >
> > The proposed changes look good to me - but please get
> > someone from the serviceability team to review this.

Thanks Daniel!

Cheers,
Ao Qi

[1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
[2] https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc


> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 16/05/2019 08:41, Ao Qi wrote:
> >> Hi,
> >>
> >> I found build is failed on CentOS 7.6, because of loop initial
> >> declarations. Could I please get reviews for this?
> >>
> >> Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-8224028
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
> >>
> >> Tested:
> >> linux-x86_64-server-release tier1
> >>
> >> Thanks,
> >> Ao Qi
> >>
> >

From aleksej.efimov at oracle.com  Thu May 16 13:48:09 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 16 May 2019 14:48:09 +0100
Subject: [teststabilization] RFR: 8223856: Replace wildcard address with
 loopback or local host in tests - part 8
In-Reply-To: <2302a02f-5f7a-2c9d-49c1-758b5fa85573@oracle.com>
References: <2302a02f-5f7a-2c9d-49c1-758b5fa85573@oracle.com>
Message-ID: <20f74cb9-5cfa-02e4-b1ef-5c1214b15c09@oracle.com>

Hi Daniel,

The changes looks good to me!

Best Regards,
Aleksei


On 16/05/2019 13:23, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for [1]:
> 8223856: Replace wildcard address with loopback or local host in
> ???????? tests - part 8
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8223856/webrev.00/index.html
>
> Some of the test failures weren't all attributable to the use
> of the wildcard: in some cases tests make assumptions that
> are not guaranteed to be true - e.g. given two different
> interfaces `i1` and `i2` you may not assume that because you
> can bind to i1 with port `p`, ephemerally allocated, you should
> also be able to bind to `i2` with the same port `p`.
>
> In such a case I have taken the liberty to add a retry mechanism,
> (that is: try again the whole thing) in the hope
> of decreasing the probability that someone else might
> be again bound to the new ephemeral port on the other interface.
>
> best regards,
>
> -- daniel
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223856


From jcbeyler at google.com  Thu May 16 14:26:10 2019
From: jcbeyler at google.com (Jean Christophe Beyler)
Date: Thu, 16 May 2019 07:26:10 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
Message-ID: <CAF9BGBxhXC_bLmsmLCtfThKk-Y=4gnW_N8CNzrEOmzQsasj6LA@mail.gmail.com>

>From my experience, some compiler in Solaris/Windows complain about this
(or used to a year ago via the submit repo); Serguei and I had to do this
dance when we were getting the heap monitoring tests in. An alternative is
to move the file to a C++ file. Adding an extern "C" at the top would make
symbols not be mangled and it should "work"  without having to go to old-C
requirements.

Thanks,
Jc

On Thu, May 16, 2019 at 5:31 AM David Holmes <david.holmes at oracle.com>
wrote:

> What compiler was used here? We shouldn't be using anything that doesn't
> handle loop variable declarations!
>
> Thanks,
> David
>
> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
> > Hi Ao Qi,
> >
> > I'm adding serviceability-dev, since this is for jdwp.
> >
> > The proposed changes look good to me - but please get
> > someone from the serviceability team to review this.
> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 16/05/2019 08:41, Ao Qi wrote:
> >> Hi,
> >>
> >> I found build is failed on CentOS 7.6, because of loop initial
> >> declarations. Could I please get reviews for this?
> >>
> >> Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-8224028
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
> >>
> >> Tested:
> >> linux-x86_64-server-release tier1
> >>
> >> Thanks,
> >> Ao Qi
> >>
> >
>


-- 

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

From alexey.menkov at oracle.com  Thu May 16 16:38:27 2019
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Thu, 16 May 2019 09:38:27 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
Message-ID: <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com>



On 05/16/2019 06:41, Ao Qi wrote:
> Hi Serguei,
> 
> I saw your email [1], but I didn't receive it yet. Thanks for your
> review! I updated:
> 
> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/

Looks good.

--alex

> 
> On Thu, May 16, 2019 at 8:30 PM David Holmes <david.holmes at oracle.com> wrote:
>>
>> What compiler was used here? We shouldn't be using anything that doesn't
>> handle loop variable declarations!
> 
> The compiler I used is gcc 4.8.5. This machine is used for testing
> jdk/jdk for months. As far as I remember, loop variable declarations
> issue never been found. If gcc 4.8.5 is not a supported compiler, I
> think we should update building doc [2].
> 
>>
>> Thanks,
>> David
>>
>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
>>> Hi Ao Qi,
>>>
>>> I'm adding serviceability-dev, since this is for jdwp.
>>>
>>> The proposed changes look good to me - but please get
>>> someone from the serviceability team to review this.
> 
> Thanks Daniel!
> 
> Cheers,
> Ao Qi
> 
> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
> [2] https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
> 
> 
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>> On 16/05/2019 08:41, Ao Qi wrote:
>>>> Hi,
>>>>
>>>> I found build is failed on CentOS 7.6, because of loop initial
>>>> declarations. Could I please get reviews for this?
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8224028
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>>>>
>>>> Tested:
>>>> linux-x86_64-server-release tier1
>>>>
>>>> Thanks,
>>>> Ao Qi
>>>>
>>>

From serguei.spitsyn at oracle.com  Thu May 16 16:44:59 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 16 May 2019 09:44:59 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com>
Message-ID: <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com>

Hi Ao Qi,

Thank you for the update.
It looks good to me.

Do you need a sponsor for integration?

Thanks,
Serguei


On 5/16/19 09:38, Alex Menkov wrote:
>
>
> On 05/16/2019 06:41, Ao Qi wrote:
>> Hi Serguei,
>>
>> I saw your email [1], but I didn't receive it yet. Thanks for your
>> review! I updated:
>>
>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/
>
> Looks good.
>
> --alex
>
>>
>> On Thu, May 16, 2019 at 8:30 PM David Holmes 
>> <david.holmes at oracle.com> wrote:
>>>
>>> What compiler was used here? We shouldn't be using anything that 
>>> doesn't
>>> handle loop variable declarations!
>>
>> The compiler I used is gcc 4.8.5. This machine is used for testing
>> jdk/jdk for months. As far as I remember, loop variable declarations
>> issue never been found. If gcc 4.8.5 is not a supported compiler, I
>> think we should update building doc [2].
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
>>>> Hi Ao Qi,
>>>>
>>>> I'm adding serviceability-dev, since this is for jdwp.
>>>>
>>>> The proposed changes look good to me - but please get
>>>> someone from the serviceability team to review this.
>>
>> Thanks Daniel!
>>
>> Cheers,
>> Ao Qi
>>
>> [1] 
>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
>> [2] 
>> https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
>>
>>
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>
>>>> On 16/05/2019 08:41, Ao Qi wrote:
>>>>> Hi,
>>>>>
>>>>> I found build is failed on CentOS 7.6, because of loop initial
>>>>> declarations. Could I please get reviews for this?
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224028
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>>>>>
>>>>> Tested:
>>>>> linux-x86_64-server-release tier1
>>>>>
>>>>> Thanks,
>>>>> Ao Qi
>>>>>
>>>>


From aeubanks at google.com  Thu May 16 17:01:23 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 16 May 2019 10:01:23 -0700
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java
 in IPv6 only environment
In-Reply-To: <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
 <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
Message-ID: <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>

*From: *Chris Hegarty <chris.hegarty at oracle.com>
*Date: *Thu, May 16, 2019 at 3:52 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list

Arthur,
>
> On 16 May 2019, at 00:24, Arthur Eubanks <aeubanks at google.com> wrote:
>
> webrev: http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8224014
>
> In https://bugs.openjdk.java.net/browse/JDK-8220673, I missed
> skipping test/jdk/java/net/NetworkInterface/IPv4Only.java when running in
> an IPv6 only environment. It should have a call to
> IPSupport.throwSkippedExceptionIfNonOperational().
>
>
> After the change for 8223532 in NetworkInterface.c, it is no longer
> required that AF_INET sockets be able to be created, coupled with
> -Djava.net.preferIPv4Stack=true, enumInterfaces may return NULL, which
> in turn bubbles up to the Java layer, in this case getNetworkInterfaces,
> as null ( rather than a collection containing the interfaces ).
>
> The specification for NetworkInterface::getNetworkInterfaces guarantees
> that there be at least one element in the returned collection, but there
> cannot be since the system is mis-configured ( the underlying platform
> is IPv6-only coupled with -Djava.net.preferIPv4Stack=true ). The only
> sensible thing for the NetworkInterface implementation to do is to throw
> an exception ( which is perfectly fine as per its specification,
> "java.net.SocketException: No network interfaces configured" ).
>
> Rather than skipping the test, which will clearly work, an alternative
> is to ensure that an exception is thrown for this case, e.g.
>
>     if (IPSupport.hasIPv4()) {
>         out.println("Testing IPv4");
>         Enumeration<NetworkInterface> nifs =
> NetworkInterface.getNetworkInterfaces();
>         while (nifs.hasMoreElements()) {
>             NetworkInterface nif = nifs.nextElement();
>             Enumeration<InetAddress> addrs = nif.getInetAddresses();
>             while (addrs.hasMoreElements()) {
>                InetAddress hostAddr = addrs.nextElement();
>                if ( hostAddr instanceof Inet6Address ){
>                     throw new RuntimeException( "NetworkInterfaceV6List
> failed - found v6 address " + hostAddr.getHostAddress() );
>                }
>             }
>         }
>     } else {
>         // No platform IPv4 support & -Djava.net.preferIPv4Stack=true
>         out.println("Testing without IPv4 support");
>         try {
>             NetworkInterface.getNetworkInterfaces();
>         } catch (SocketException expected) {
>             out.println("caught expected exception: " + expected);
>         }
>
>         try {
>             NetworkInterface.networkInterfaces();
>         } catch (SocketException expected) {
>             out.println("caught expected exception: " + expected);
>         }
>     }
>
> -Chris.
>
>
Good idea, done. PTAL. Tested with and without IPv4 support.
http://cr.openjdk.java.net/~aeubanks/8224014/webrev.01/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/1d1ec06f/attachment.html>

From aoqi at loongson.cn  Thu May 16 18:25:37 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Fri, 17 May 2019 02:25:37 +0800
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com>
 <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com>
Message-ID: <CALjzQn7aDk_ko4ibjQ_ru_Vfk9j95MEzc5qRsXyD-6Fs+JnAqg@mail.gmail.com>

On Fri, May 17, 2019 at 12:44 AM serguei.spitsyn at oracle.com
<serguei.spitsyn at oracle.com> wrote:
>
> Hi Ao Qi,
>
> Thank you for the update.
> It looks good to me.

Thanks!

>
> Do you need a sponsor for integration?

Yes:)

>
> Thanks,
> Serguei
>
>
> On 5/16/19 09:38, Alex Menkov wrote:
> >
> >
> > On 05/16/2019 06:41, Ao Qi wrote:
> >> Hi Serguei,
> >>
> >> I saw your email [1], but I didn't receive it yet. Thanks for your
> >> review! I updated:
> >>
> >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/
> >
> > Looks good.
> >
> > --alex
> >
> >>
> >> On Thu, May 16, 2019 at 8:30 PM David Holmes
> >> <david.holmes at oracle.com> wrote:
> >>>
> >>> What compiler was used here? We shouldn't be using anything that
> >>> doesn't
> >>> handle loop variable declarations!
> >>
> >> The compiler I used is gcc 4.8.5. This machine is used for testing
> >> jdk/jdk for months. As far as I remember, loop variable declarations
> >> issue never been found. If gcc 4.8.5 is not a supported compiler, I
> >> think we should update building doc [2].
> >>
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
> >>>> Hi Ao Qi,
> >>>>
> >>>> I'm adding serviceability-dev, since this is for jdwp.
> >>>>
> >>>> The proposed changes look good to me - but please get
> >>>> someone from the serviceability team to review this.
> >>
> >> Thanks Daniel!
> >>
> >> Cheers,
> >> Ao Qi
> >>
> >> [1]
> >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
> >> [2]
> >> https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
> >>
> >>
> >>>>
> >>>> best regards,
> >>>>
> >>>> -- daniel
> >>>>
> >>>>
> >>>> On 16/05/2019 08:41, Ao Qi wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I found build is failed on CentOS 7.6, because of loop initial
> >>>>> declarations. Could I please get reviews for this?
> >>>>>
> >>>>> Bug:
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8224028
> >>>>>
> >>>>> Webrev:
> >>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
> >>>>>
> >>>>> Tested:
> >>>>> linux-x86_64-server-release tier1
> >>>>>
> >>>>> Thanks,
> >>>>> Ao Qi
> >>>>>
> >>>>
>

From stuart.marks at oracle.com  Thu May 16 22:09:21 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 May 2019 15:09:21 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
Message-ID: <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>



On 5/14/19 9:16 PM, Martin Buchholz wrote:
>> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java

Regarding the change in this particular file, I'd suggest the following:


diff -r 006dadb903ab -r 92e1fdce45e0 
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Thu May 16 15:04:30 2019 -0700
@@ -1712,9 +1712,7 @@
          Map<?,?> m = (Map<?,?>) o;
          try {
              Comparator<? super K> cmp = comparator;
-            @SuppressWarnings("unchecked")
-            Iterator<Map.Entry<?,?>> it =
-                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
+            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
              if (m instanceof SortedMap &&
                  ((SortedMap<?,?>)m).comparator() == cmp) {
                  Node<K,V> b, n;



I have no idea if it will be accepted by the Eclipse IDE, but this seems like a 
cleaner change to me than introducing a raw type.

***

Christoph,

On the general issue of compilation differences between javac and the Eclipse 
IDE, have you raised a bug with them?

s'marks

From david.holmes at oracle.com  Thu May 16 22:21:17 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 May 2019 08:21:17 +1000
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CAF9BGBxhXC_bLmsmLCtfThKk-Y=4gnW_N8CNzrEOmzQsasj6LA@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CAF9BGBxhXC_bLmsmLCtfThKk-Y=4gnW_N8CNzrEOmzQsasj6LA@mail.gmail.com>
Message-ID: <04e91b4d-0caf-9772-746a-d12bebbce8d4@oracle.com>

On 17/05/2019 12:26 am, Jean Christophe Beyler wrote:
>  From my experience, some compiler in Solaris/Windows complain about 
> this (or used to a year ago via the submit repo); Serguei and I had to 
> do this dance when we were getting the heap monitoring tests in. An 

I think the tests are different. This file is part of the main build and 
is being built the same way as all the other .c files in the core 
libraries. The Windows and Solaris sources already contain code with 
loop variable declarations. Yet much to my surprise the shared sources 
do not - seems gcc is the weak link here. :(

> alternative is to move the file to a C++ file. Adding an extern "C" at 
> the top would make symbols not be mangled and it should "work"? without 
> having to go to old-C requirements.

Not sure if that's feasible.

Cheers,
David
-----

> Thanks,
> Jc
> 
> On Thu, May 16, 2019 at 5:31 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     What compiler was used here? We shouldn't be using anything that
>     doesn't
>     handle loop variable declarations!
> 
>     Thanks,
>     David
> 
>     On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
>      > Hi Ao Qi,
>      >
>      > I'm adding serviceability-dev, since this is for jdwp.
>      >
>      > The proposed changes look good to me - but please get
>      > someone from the serviceability team to review this.
>      >
>      > best regards,
>      >
>      > -- daniel
>      >
>      >
>      > On 16/05/2019 08:41, Ao Qi wrote:
>      >> Hi,
>      >>
>      >> I found build is failed on CentOS 7.6, because of loop initial
>      >> declarations. Could I please get reviews for this?
>      >>
>      >> Bug:
>      >> https://bugs.openjdk.java.net/browse/JDK-8224028
>      >>
>      >> Webrev:
>      >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>      >>
>      >> Tested:
>      >> linux-x86_64-server-release tier1
>      >>
>      >> Thanks,
>      >> Ao Qi
>      >>
>      >
> 
> 
> 
> -- 
> 
> Thanks,
> Jc

From david.holmes at oracle.com  Thu May 16 22:25:21 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 May 2019 08:25:21 +1000
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
Message-ID: <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>

On 16/05/2019 11:41 pm, Ao Qi wrote:
> Hi Serguei,
> 
> I saw your email [1], but I didn't receive it yet. Thanks for your
> review! I updated:
> 
> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/
> 
> On Thu, May 16, 2019 at 8:30 PM David Holmes <david.holmes at oracle.com> wrote:
>>
>> What compiler was used here? We shouldn't be using anything that doesn't
>> handle loop variable declarations!
> 
> The compiler I used is gcc 4.8.5. This machine is used for testing
> jdk/jdk for months. As far as I remember, loop variable declarations
> issue never been found. If gcc 4.8.5 is not a supported compiler, I
> think we should update building doc [2].

I'm surprised the out-of-the-box settings for 4.8.5 result in such an 
archaic version of C being supported. I thought we had addressed such 
limitations quite a while ago. :(

That said perhaps it is time to bump the minimum gcc level beyond 4.8 ...

Thanks,
David
-----

>>
>> Thanks,
>> David
>>
>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
>>> Hi Ao Qi,
>>>
>>> I'm adding serviceability-dev, since this is for jdwp.
>>>
>>> The proposed changes look good to me - but please get
>>> someone from the serviceability team to review this.
> 
> Thanks Daniel!
> 
> Cheers,
> Ao Qi
> 
> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
> [2] https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
> 
> 
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>> On 16/05/2019 08:41, Ao Qi wrote:
>>>> Hi,
>>>>
>>>> I found build is failed on CentOS 7.6, because of loop initial
>>>> declarations. Could I please get reviews for this?
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8224028
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>>>>
>>>> Tested:
>>>> linux-x86_64-server-release tier1
>>>>
>>>> Thanks,
>>>> Ao Qi
>>>>
>>>

From aeubanks at google.com  Thu May 16 22:38:38 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 16 May 2019 15:38:38 -0700
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
 assumes IPv4 is always available
In-Reply-To: <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
Message-ID: <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>

I've added testing exceptions to IPv6 as well, PTAL.
This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4 and
IPv6 code paths. Else DatagramChannel.join() fails since you can't mix IPv4
and IPv6 addresses, and InetAddress.getLocalHost() can only be one of those.

http://cr.openjdk.java.net/~aeubanks/8224019/webrev.01/

On Thu, May 16, 2019 at 2:52 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthur,
>
> Shouldn't there be a version of
>   221             exceptionTests(nif);
> that works with IPv6?
>
> If no machine has IPv4 available, then these exceptions
> won't be tested any more.
>
> I suspect the test made the assumption that IPv4 was always available,
> and therefore testing exceptions with IPv4 addresses was sufficient.
> Now if IPv4 is not available, then maybe those exceptional
> cases should be tested with IPv6 instead?
>
> (Note: you can log a follow-up issue if you don't want to tackle
>   that immediately)
>
> best regards,
>
> -- daniel
>
>
> On 16/05/2019 01:45, Arthur Eubanks wrote:
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224019
> > webrev:
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.00/index.html
> >
> > test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
> > assumes NetworkConfiguration.probe().ip4MulticastInterfaces().iterator()
> > always has at least one NetworkInterface. Instead it should do something
> > like the IPv6 code right after it where it checks that the iterator is
> > not empty.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/c02d487f/attachment.html>

From martinrb at google.com  Thu May 16 22:57:49 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 May 2019 15:57:49 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
Message-ID: <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>

Maybe you just need to ask gcc to use a more modern -std=...
It might reasonably be defaulting to gnu89
https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu

On Thu, May 16, 2019 at 3:25 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 16/05/2019 11:41 pm, Ao Qi wrote:
> > Hi Serguei,
> >
> > I saw your email [1], but I didn't receive it yet. Thanks for your
> > review! I updated:
> >
> > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/
> >
> > On Thu, May 16, 2019 at 8:30 PM David Holmes <david.holmes at oracle.com>
> wrote:
> >>
> >> What compiler was used here? We shouldn't be using anything that doesn't
> >> handle loop variable declarations!
> >
> > The compiler I used is gcc 4.8.5. This machine is used for testing
> > jdk/jdk for months. As far as I remember, loop variable declarations
> > issue never been found. If gcc 4.8.5 is not a supported compiler, I
> > think we should update building doc [2].
>
> I'm surprised the out-of-the-box settings for 4.8.5 result in such an
> archaic version of C being supported. I thought we had addressed such
> limitations quite a while ago. :(
>
> That said perhaps it is time to bump the minimum gcc level beyond 4.8 ...
>
> Thanks,
> David
> -----
>
> >>
> >> Thanks,
> >> David
> >>
> >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
> >>> Hi Ao Qi,
> >>>
> >>> I'm adding serviceability-dev, since this is for jdwp.
> >>>
> >>> The proposed changes look good to me - but please get
> >>> someone from the serviceability team to review this.
> >
> > Thanks Daniel!
> >
> > Cheers,
> > Ao Qi
> >
> > [1]
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
> > [2]
> https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
> >
> >
> >>>
> >>> best regards,
> >>>
> >>> -- daniel
> >>>
> >>>
> >>> On 16/05/2019 08:41, Ao Qi wrote:
> >>>> Hi,
> >>>>
> >>>> I found build is failed on CentOS 7.6, because of loop initial
> >>>> declarations. Could I please get reviews for this?
> >>>>
> >>>> Bug:
> >>>> https://bugs.openjdk.java.net/browse/JDK-8224028
> >>>>
> >>>> Webrev:
> >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
> >>>>
> >>>> Tested:
> >>>> linux-x86_64-server-release tier1
> >>>>
> >>>> Thanks,
> >>>> Ao Qi
> >>>>
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/0d090faa/attachment-0001.html>

From david.holmes at oracle.com  Thu May 16 23:05:52 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 May 2019 09:05:52 +1000
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
 <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>
Message-ID: <a1d2e0f9-ac7f-2464-3362-100f385d0c53@oracle.com>

On 17/05/2019 8:57 am, Martin Buchholz wrote:
> Maybe you just need to ask gcc to use a more modern -std=...
> It might reasonably be defaulting to gnu89
> https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu

Yes, but I thought we'd already done this dance. Solaris was setting a 
flag to use C89 IIRC and we removed it.

Cheers,
David

> On Thu, May 16, 2019 at 3:25 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 16/05/2019 11:41 pm, Ao Qi wrote:
>      > Hi Serguei,
>      >
>      > I saw your email [1], but I didn't receive it yet. Thanks for your
>      > review! I updated:
>      >
>      > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/
>      >
>      > On Thu, May 16, 2019 at 8:30 PM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>      >>
>      >> What compiler was used here? We shouldn't be using anything that
>     doesn't
>      >> handle loop variable declarations!
>      >
>      > The compiler I used is gcc 4.8.5. This machine is used for testing
>      > jdk/jdk for months. As far as I remember, loop variable declarations
>      > issue never been found. If gcc 4.8.5 is not a supported compiler, I
>      > think we should update building doc [2].
> 
>     I'm surprised the out-of-the-box settings for 4.8.5 result in such an
>     archaic version of C being supported. I thought we had addressed such
>     limitations quite a while ago. :(
> 
>     That said perhaps it is time to bump the minimum gcc level beyond
>     4.8 ...
> 
>     Thanks,
>     David
>     -----
> 
>      >>
>      >> Thanks,
>      >> David
>      >>
>      >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote:
>      >>> Hi Ao Qi,
>      >>>
>      >>> I'm adding serviceability-dev, since this is for jdwp.
>      >>>
>      >>> The proposed changes look good to me - but please get
>      >>> someone from the serviceability team to review this.
>      >
>      > Thanks Daniel!
>      >
>      > Cheers,
>      > Ao Qi
>      >
>      > [1]
>     https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html
>      > [2]
>     https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc
>      >
>      >
>      >>>
>      >>> best regards,
>      >>>
>      >>> -- daniel
>      >>>
>      >>>
>      >>> On 16/05/2019 08:41, Ao Qi wrote:
>      >>>> Hi,
>      >>>>
>      >>>> I found build is failed on CentOS 7.6, because of loop initial
>      >>>> declarations. Could I please get reviews for this?
>      >>>>
>      >>>> Bug:
>      >>>> https://bugs.openjdk.java.net/browse/JDK-8224028
>      >>>>
>      >>>> Webrev:
>      >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/
>      >>>>
>      >>>> Tested:
>      >>>> linux-x86_64-server-release tier1
>      >>>>
>      >>>> Thanks,
>      >>>> Ao Qi
>      >>>>
>      >>>
> 

From martinrb at google.com  Thu May 16 23:14:24 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 May 2019 16:14:24 -0700
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <a1d2e0f9-ac7f-2464-3362-100f385d0c53@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
 <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>
 <a1d2e0f9-ac7f-2464-3362-100f385d0c53@oracle.com>
Message-ID: <CA+kOe09_oFQChVUaennnwJj0Bi60q_pZ+aoBT+one3n8acUB7g@mail.gmail.com>

On Thu, May 16, 2019 at 4:05 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 17/05/2019 8:57 am, Martin Buchholz wrote:
> > Maybe you just need to ask gcc to use a more modern -std=...
> > It might reasonably be defaulting to gnu89
> >
> https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu
>
> Yes, but I thought we'd already done this dance. Solaris was setting a
> flag to use C89 IIRC and we removed it.
>

A flag to use C89 is obviously bad if you're using features from a later
standard.
I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I would
go whole hog to C11)

 $ gcc -v --help |& grep std=.*' C '
  -std=c11                    Conform to the ISO 2011 C standard
  -std=c89                    Conform to the ISO 1990 C standard
  -std=c90                    Conform to the ISO 1990 C standard
  -std=c99                    Conform to the ISO 1999 C standard
  -std=gnu11                  Conform to the ISO 2011 C standard with GNU
  -std=gnu89                  Conform to the ISO 1990 C standard with GNU
  -std=gnu90                  Conform to the ISO 1990 C standard with GNU
  -std=gnu99                  Conform to the ISO 1999 C standard with GNU
  -std=iso9899:1990           Conform to the ISO 1990 C standard
  -std=iso9899:199409         Conform to the ISO 1990 C standard as amended
in
  -std=iso9899:1999           Conform to the ISO 1999 C standard
  -std=iso9899:2011           Conform to the ISO 2011 C standard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/6492d86f/attachment.html>

From aeubanks at google.com  Thu May 16 23:16:28 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 16 May 2019 16:16:28 -0700
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
Message-ID: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>

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

Tests that try to use SOCKS v4 will fail in an IPv6 only environment since
SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/71c02386/attachment.html>

From aeubanks at google.com  Thu May 16 23:18:56 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 16 May 2019 16:18:56 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
Message-ID: <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>

I've tried to run this through the submit repo twice, haven't gotten a
result from either run. Could somebody check what's happened to those runs?
The branch names are "JDK-8223214" and "JDK-8223214-1".

On Wed, May 15, 2019 at 8:56 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> On 15 May 2019, at 16:19, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Ping.
>
> *From: *Arthur Eubanks <aeubanks@ <aeubanks at google.com>google.com> wrote:
>
> New webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.01/
>>
>
> You have my Review.
>
> -Chris.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/684be667/attachment.html>

From david.holmes at oracle.com  Fri May 17 00:19:05 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 May 2019 10:19:05 +1000
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <CA+kOe09_oFQChVUaennnwJj0Bi60q_pZ+aoBT+one3n8acUB7g@mail.gmail.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
 <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>
 <a1d2e0f9-ac7f-2464-3362-100f385d0c53@oracle.com>
 <CA+kOe09_oFQChVUaennnwJj0Bi60q_pZ+aoBT+one3n8acUB7g@mail.gmail.com>
Message-ID: <aaa93ac8-7c32-7e72-63e6-d1c79888626a@oracle.com>

On 17/05/2019 9:14 am, Martin Buchholz wrote:
> On Thu, May 16, 2019 at 4:05 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 17/05/2019 8:57 am, Martin Buchholz wrote:
>      > Maybe you just need to ask gcc to use a more modern -std=...
>      > It might reasonably be defaulting to gnu89
>      >
>     https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu
> 
>     Yes, but I thought we'd already done this dance. Solaris was setting a
>     flag to use C89 IIRC and we removed it.
> 
> 
> A flag to use C89 is obviously bad if you're using features from a later 
> standard.
> I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I 
> would go whole hog to C11)

Again I thought we had done this dance. We set -std=gnu++98 but that 
only affects .cpp files. We need a similar thing for .c files. I know 
this has been discussed so I'll see if I can dig up the history and find 
out why we didn't do it. I'll file a build bug if needed.

Cheers,
David


>  ?$ gcc -v --help |& grep std=.*' C '
>  ? -std=c11? ? ? ? ? ? ? ? ? ? Conform to the ISO 2011 C standard
>  ? -std=c89? ? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard
>  ? -std=c90? ? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard
>  ? -std=c99? ? ? ? ? ? ? ? ? ? Conform to the ISO 1999 C standard
>  ? -std=gnu11? ? ? ? ? ? ? ? ? Conform to the ISO 2011 C standard with GNU
>  ? -std=gnu89? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard with GNU
>  ? -std=gnu90? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard with GNU
>  ? -std=gnu99? ? ? ? ? ? ? ? ? Conform to the ISO 1999 C standard with GNU
>  ? -std=iso9899:1990? ? ? ? ? ?Conform to the ISO 1990 C standard
>  ? -std=iso9899:199409? ? ? ? ?Conform to the ISO 1990 C standard as 
> amended in
>  ? -std=iso9899:1999? ? ? ? ? ?Conform to the ISO 1999 C standard
>  ? -std=iso9899:2011? ? ? ? ? ?Conform to the ISO 2011 C standard

From martinrb at google.com  Fri May 17 02:32:37 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 May 2019 19:32:37 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
 <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>
Message-ID: <CA+kOe08JHUyrDXbc7rKFcU8EEix5y39nQb4LNwtW0OxuGDtWXw@mail.gmail.com>

Stuart's cool type system hack is hard for me to grok, but it seems alright
to put into ConcurrentSkipListMap.java.  We could add it to the current
jsr166 integration.


*From: *Stuart Marks <stuart.marks at oracle.com>
*Date: *Thu, May 16, 2019 at 3:11 PM
*To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christoph
*Cc: *compiler-dev at openjdk.java.net, core-libs-dev, net-dev

On 5/14/19 9:16 PM, Martin Buchholz wrote:
> >>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Regarding the change in this particular file, I'd suggest the following:
>
>
> diff -r 006dadb903ab -r 92e1fdce45e0
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Thu May 16 15:04:30 2019 -0700
> @@ -1712,9 +1712,7 @@
>           Map<?,?> m = (Map<?,?>) o;
>           try {
>               Comparator<? super K> cmp = comparator;
> -            @SuppressWarnings("unchecked")
> -            Iterator<Map.Entry<?,?>> it =
> -                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
> +            Iterator<? extends Map.Entry<?,?>> it =
> m.entrySet().iterator();
>               if (m instanceof SortedMap &&
>                   ((SortedMap<?,?>)m).comparator() == cmp) {
>                   Node<K,V> b, n;
>
>
>
> I have no idea if it will be accepted by the Eclipse IDE, but this seems
> like a
> cleaner change to me than introducing a raw type.
>
> ***
>
> Christoph,
>
> On the general issue of compilation differences between javac and the
> Eclipse
> IDE, have you raised a bug with them?
>
> s'marks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/2ecacb85/attachment.html>

From vyommani at gmail.com  Fri May 17 02:44:00 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 17 May 2019 08:14:00 +0530
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
Message-ID: <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>

Hi Arthur,
do we need "Integer.toString(4)" to convert int to string in
SocksProxyVersion ?
Thanks,
Vyom

On Fri, May 17, 2019 at 4:46 AM Arthur Eubanks <aeubanks at google.com> wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8224081
> webrev: http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html
>
> Tests that try to use SOCKS v4 will fail in an IPv6 only environment since
> SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.
>


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

From aeubanks at google.com  Fri May 17 05:57:34 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 16 May 2019 22:57:34 -0700
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
Message-ID: <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>

On Thu, May 16, 2019 at 7:44 PM Vyom Tiwari <vyommani at gmail.com> wrote:

> Hi Arthur,
> do we need "Integer.toString(4)" to convert int to string in
> SocksProxyVersion ?
> Thanks,
> Vyom
>
Fixed.
http://cr.openjdk.java.net/~aeubanks/8224081/webrev.01/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190516/5a2964b2/attachment.html>

From Alan.Bateman at oracle.com  Fri May 17 06:41:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 07:41:15 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
Message-ID: <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>

On 16/05/2019 23:38, Arthur Eubanks wrote:
> I've added testing exceptions to IPv6 as well, PTAL.
> This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4 
> and IPv6 code paths. Else DatagramChannel.join() fails since you can't 
> mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost() can only 
> be one of those.
>
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.01/
>
Adding back nio-dev as it seems to have been dropped from thread again.

On webrev.01, I think the approach looks okay but would you have 
re-ordering the parameters to both membershipKeyTests and exceptionTests 
so that the protocol family is first, then the groups, then the 
NetworkInterface as that will align with the usages and the join methods 
where the order is always group, networkInterface (and optionally source).

-Alan

From daniel.fuchs at oracle.com  Fri May 17 09:46:15 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 May 2019 10:46:15 +0100
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
In-Reply-To: <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
 <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
 <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>
Message-ID: <5d5a2eea-f232-1fe2-fe27-60267aed61f1@oracle.com>

Hi Arthur,

On 16/05/2019 18:01, Arthur Eubanks wrote:
> Good idea, done. PTAL. Tested with and without IPv4 support.
> http://cr.openjdk.java.net/~aeubanks/8224014/webrev.01/index.html

Shouldn't you remove:

   38         IPSupport.throwSkippedExceptionIfNonOperational();

In this case?

best regards,

-- daniel

From daniel.fuchs at oracle.com  Fri May 17 10:00:04 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 May 2019 11:00:04 +0100
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
Message-ID: <de434216-0c9f-c287-1055-e6240600d270@oracle.com>

Hi Arthur,

On 17/05/2019 00:16, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224081
> webrev: http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html
> 
> Tests that try to use SOCKS v4 will fail in an IPv6 only environment 
> since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.

Your changes to java/net/Socks/SocksProxyVersion.java look good to me.

However I'd like your changes to
test/jdk/sun/security/x509/URICertStore/SocksProxy.java
to be reviewed by the security-dev team which I have added
in cc:, since I believe this falls into their area.

best regards,

-- daniel


From vyommani at gmail.com  Fri May 17 10:02:27 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 17 May 2019 15:32:27 +0530
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <de434216-0c9f-c287-1055-e6240600d270@oracle.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <de434216-0c9f-c287-1055-e6240600d270@oracle.com>
Message-ID: <CAKysZ8ye4C=WYnutL9UiSBMFPz8gxsmmiDeFvFUYEgi436B3Nw@mail.gmail.com>

+1

On Fri, May 17, 2019 at 3:29 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthur,
>
> On 17/05/2019 00:16, Arthur Eubanks wrote:
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224081
> > webrev:
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html
> >
> > Tests that try to use SOCKS v4 will fail in an IPv6 only environment
> > since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6.
>
> Your changes to java/net/Socks/SocksProxyVersion.java look good to me.
>
> However I'd like your changes to
> test/jdk/sun/security/x509/URICertStore/SocksProxy.java
> to be reviewed by the security-dev team which I have added
> in cc:, since I believe this falls into their area.
>
> best regards,
>
> -- daniel
>
>

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

From daniel.fuchs at oracle.com  Fri May 17 11:13:58 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 May 2019 12:13:58 +0100
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
 <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
Message-ID: <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>

Hi Arthur,

On 17/05/2019 00:18, Arthur Eubanks wrote:
> I've tried to run this through the submit repo twice, haven't gotten a 
> result from either run. Could somebody check what's happened to those runs?
> The branch names are "JDK-8223214" and "JDK-8223214-1".

I'm not seeing anything for JDK-8223214 in the history.
When did you submit those? It looks as they never run,
as I can see jobs from some month ago. Maybe the trigger
didn't work (whatever that is).

Can you submit a again and let me know - and I'll try
to have a look at the jdk-submit CI?

best regards,

-- daniel

From chris.hegarty at oracle.com  Fri May 17 12:06:11 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 17 May 2019 13:06:11 +0100
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
Message-ID: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>

Arthur,

On 17/05/2019 06:57, Arthur Eubanks wrote:
> 
> 
> On Thu, May 16, 2019 at 7:44 PM Vyom Tiwari <vyommani at gmail.com 
> <mailto:vyommani at gmail.com>> wrote:
> 
>     Hi Arthur,
>     do we need "Integer.toString(4)" to convert int to string in
>     SocksProxyVersion ?
>     Thanks,
>     Vyom
> 
> Fixed.
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.01/index.html

Looks good.

Trivially, maybe amend the comment to be more explicit

   86       // SOCKS V4 ( requires IPv4 )

-Chris.

From aoqi at loongson.cn  Fri May 17 15:11:53 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Fri, 17 May 2019 23:11:53 +0800
Subject: RFR: JDK-8224028: loop initial declarations introduced by
 JDK-8184770 (jdwp)
In-Reply-To: <aaa93ac8-7c32-7e72-63e6-d1c79888626a@oracle.com>
References: <CALjzQn7S1ULQ=x5mdcmj-+D079PjoTpjP2P70xM_w3BmBJ+VBA@mail.gmail.com>
 <cedb78fb-c682-739f-f7c3-4d7580c4d1c2@oracle.com>
 <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com>
 <CALjzQn4mBWZqE2aU7mHj95h3MfuWPCL-D3HnQCqqoj2+0zztrg@mail.gmail.com>
 <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com>
 <CA+kOe08APHEyt9R=mn3vfd9QuOw=XXwGZ7Gj8emKpxadj6O4XQ@mail.gmail.com>
 <a1d2e0f9-ac7f-2464-3362-100f385d0c53@oracle.com>
 <CA+kOe09_oFQChVUaennnwJj0Bi60q_pZ+aoBT+one3n8acUB7g@mail.gmail.com>
 <aaa93ac8-7c32-7e72-63e6-d1c79888626a@oracle.com>
Message-ID: <CALjzQn4mRQBF5Tda-7BQpGoWbQFtjtWHLS18SzvN349WEHZjDg@mail.gmail.com>

Hi,

Aleksey has helped to push:
http://hg.openjdk.java.net/jdk/jdk/rev/3205f4c40716. Thank you all!

Cheers,
Ao Qi

On Fri, May 17, 2019 at 8:19 AM David Holmes <david.holmes at oracle.com> wrote:
>
> On 17/05/2019 9:14 am, Martin Buchholz wrote:
> > On Thu, May 16, 2019 at 4:05 PM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     On 17/05/2019 8:57 am, Martin Buchholz wrote:
> >      > Maybe you just need to ask gcc to use a more modern -std=...
> >      > It might reasonably be defaulting to gnu89
> >      >
> >     https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu
> >
> >     Yes, but I thought we'd already done this dance. Solaris was setting a
> >     flag to use C89 IIRC and we removed it.
> >
> >
> > A flag to use C89 is obviously bad if you're using features from a later
> > standard.
> > I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I
> > would go whole hog to C11)
>
> Again I thought we had done this dance. We set -std=gnu++98 but that
> only affects .cpp files. We need a similar thing for .c files. I know
> this has been discussed so I'll see if I can dig up the history and find
> out why we didn't do it. I'll file a build bug if needed.
>
> Cheers,
> David
>
>
> >   $ gcc -v --help |& grep std=.*' C '
> >    -std=c11                    Conform to the ISO 2011 C standard
> >    -std=c89                    Conform to the ISO 1990 C standard
> >    -std=c90                    Conform to the ISO 1990 C standard
> >    -std=c99                    Conform to the ISO 1999 C standard
> >    -std=gnu11                  Conform to the ISO 2011 C standard with GNU
> >    -std=gnu89                  Conform to the ISO 1990 C standard with GNU
> >    -std=gnu90                  Conform to the ISO 1990 C standard with GNU
> >    -std=gnu99                  Conform to the ISO 1999 C standard with GNU
> >    -std=iso9899:1990           Conform to the ISO 1990 C standard
> >    -std=iso9899:199409         Conform to the ISO 1990 C standard as
> > amended in
> >    -std=iso9899:1999           Conform to the ISO 1999 C standard
> >    -std=iso9899:2011           Conform to the ISO 2011 C standard

From aeubanks at google.com  Fri May 17 16:50:18 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 09:50:18 -0700
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
Message-ID: <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>

>
> Looks good.
>
> Trivially, maybe amend the comment to be more explicit
>
>    86       // SOCKS V4 ( requires IPv4 )
>
> -Chris.
>
Done
http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/

I will wait for another review from security-dev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/f06b611c/attachment.html>

From chris.hegarty at oracle.com  Fri May 17 16:53:31 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 17 May 2019 17:53:31 +0100
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
 <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
Message-ID: <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>

Arthur,

> On 17 May 2019, at 17:50, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> Looks good.
> 
> Trivially, maybe amend the comment to be more explicit
> 
>    86       // SOCKS V4 ( requires IPv4 )
> 
> -Chris.
> Done
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ <http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/>
> 
> I will wait for another review from security-dev.

You have my Review ( conditional on a Reviewer for the test in the security area ).

-Chris.

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

From aeubanks at google.com  Fri May 17 16:55:49 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 09:55:49 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
 <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
 <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>
Message-ID: <CAPW48spuhzReTTrrv2O4reDbkHjG=EifR56aZRCo3-yu+mFZ+Q@mail.gmail.com>

On Fri, May 17, 2019 at 4:13 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthur,
>
> On 17/05/2019 00:18, Arthur Eubanks wrote:
> > I've tried to run this through the submit repo twice, haven't gotten a
> > result from either run. Could somebody check what's happened to those
> runs?
> > The branch names are "JDK-8223214" and "JDK-8223214-1".
>
> I'm not seeing anything for JDK-8223214 in the history.
> When did you submit those? It looks as they never run,
> as I can see jobs from some month ago. Maybe the trigger
> didn't work (whatever that is).
>
I (actually Jiangli for me) submitted one Wednesday and one Thursday.

>
> Can you submit a again and let me know - and I'll try
> to have a look at the jdk-submit CI?
>
Yes I will try again. Thanks for looking at this.

>
> best regards,
>
> -- daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/7ab21311/attachment.html>

From aeubanks at google.com  Fri May 17 17:02:29 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 10:02:29 -0700
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java
 in IPv6 only environment
In-Reply-To: <5d5a2eea-f232-1fe2-fe27-60267aed61f1@oracle.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
 <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
 <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>
 <5d5a2eea-f232-1fe2-fe27-60267aed61f1@oracle.com>
Message-ID: <CAPW48sq+v1iPEW1NV4MuorLsw8KP04e_-1KO90nDTGqg=OC+nQ@mail.gmail.com>

On Fri, May 17, 2019 at 2:47 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthur,
>
> On 16/05/2019 18:01, Arthur Eubanks wrote:
> > Good idea, done. PTAL. Tested with and without IPv4 support.
> > http://cr.openjdk.java.net/~aeubanks/8224014/webrev.01/index.html
>
> Shouldn't you remove:
>
>    38         IPSupport.throwSkippedExceptionIfNonOperational();
>
> In this case?
>
> best regards,
>
> -- daniel
>
Oh yes, http://cr.openjdk.java.net/~aeubanks/8224014/webrev.02/
Made sure that the "caught expected exception" lines were printed out under
IPv6-only environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/565b771a/attachment-0001.html>

From jianglizhou at google.com  Fri May 17 17:14:03 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 17 May 2019 10:14:03 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48spuhzReTTrrv2O4reDbkHjG=EifR56aZRCo3-yu+mFZ+Q@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
 <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
 <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>
 <CAPW48spuhzReTTrrv2O4reDbkHjG=EifR56aZRCo3-yu+mFZ+Q@mail.gmail.com>
Message-ID: <CALrW1jzcvFrVj3J=_20AQjzL7JdvwudA9VJ5v5btEvt6Vb25-w@mail.gmail.com>

On Fri, May 17, 2019 at 9:56 AM Arthur Eubanks <aeubanks at google.com> wrote:
>
>
>
> On Fri, May 17, 2019 at 4:13 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Arthur,
>>
>> On 17/05/2019 00:18, Arthur Eubanks wrote:
>> > I've tried to run this through the submit repo twice, haven't gotten a
>> > result from either run. Could somebody check what's happened to those runs?
>> > The branch names are "JDK-8223214" and "JDK-8223214-1".
>>
>> I'm not seeing anything for JDK-8223214 in the history.
>> When did you submit those? It looks as they never run,
>> as I can see jobs from some month ago. Maybe the trigger
>> didn't work (whatever that is).
>
> I (actually Jiangli for me) submitted one Wednesday and one Thursday.

That's strange those two jobs didn't show up. The job between those
did complete.

>>
>>
>> Can you submit a again and let me know - and I'll try
>> to have a look at the jdk-submit CI?
>
> Yes I will try again. Thanks for looking at this.

Let me try it from a new cloned repo again...

Thanks,
Jiangli

>>
>>
>> best regards,
>>
>> -- daniel

From aeubanks at google.com  Fri May 17 17:22:36 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 10:22:36 -0700
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
 assumes IPv4 is always available
In-Reply-To: <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
Message-ID: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>

On Thu, May 16, 2019 at 11:41 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 16/05/2019 23:38, Arthur Eubanks wrote:
> > I've added testing exceptions to IPv6 as well, PTAL.
> > This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4
> > and IPv6 code paths. Else DatagramChannel.join() fails since you can't
> > mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost() can only
> > be one of those.
> >
> > http://cr.openjdk.java.net/~aeubanks/8224019/webrev.01/
> >
> Adding back nio-dev as it seems to have been dropped from thread again.
>
> On webrev.01, I think the approach looks okay but would you have
> re-ordering the parameters to both membershipKeyTests and exceptionTests
> so that the protocol family is first, then the groups, then the
> NetworkInterface as that will align with the usages and the join methods
> where the order is always group, networkInterface (and optionally source).
>
> -Alan
>
Done, order is protocol family, group/notGroup InetAddress,
NetworkInterface, source InetAddress
http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/1e5a5eca/attachment.html>

From Alan.Bateman at oracle.com  Fri May 17 17:49:12 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 18:49:12 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <891ff1c3-cce1-1f5e-1041-376e19e227b7@oracle.com>

On 17/05/2019 18:22, Arthur Eubanks wrote:
>
> Done, order is protocol family, group/notGroup InetAddress, 
> NetworkInterface, source InetAddress
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/
Thanks, this version looks okay to me.

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

From daniel.fuchs at oracle.com  Fri May 17 19:14:04 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 May 2019 20:14:04 +0100
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
In-Reply-To: <CAPW48sq+v1iPEW1NV4MuorLsw8KP04e_-1KO90nDTGqg=OC+nQ@mail.gmail.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
 <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
 <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>
 <5d5a2eea-f232-1fe2-fe27-60267aed61f1@oracle.com>
 <CAPW48sq+v1iPEW1NV4MuorLsw8KP04e_-1KO90nDTGqg=OC+nQ@mail.gmail.com>
Message-ID: <c3470dad-3fd7-4f06-59de-a9f9161c6924@oracle.com>

On 17/05/19 18:02, Arthur Eubanks wrote:
> 
> Oh yes, http://cr.openjdk.java.net/~aeubanks/8224014/webrev.02/
> Made sure that the "caught expected exception" lines were printed out 
> under IPv6-only environment.

Yes, looks good!

best regards,

-- daniel


From stuart.marks at oracle.com  Fri May 17 22:56:27 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 17 May 2019 15:56:27 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>

Hi Christoph,

I'm still not entirely sure why this is so, but the introduction of a local 
variable in MethodHandles.java seems to make things work for Eclipse. Addition 
of a local variable seems to be minimally invasive, so it makes sense to see if 
this technique can be applied to other cases.

(In ConcurrentSkipListMap the issue seems to be solved by addition of wildcards, 
as I had suggested previously, and it cleans up the unchecked cast that was 
there in the first place. So I think that one is ok already.)

In ManagementFactory.java, an unchecked cast and warnings suppression is 
introduced, and in ExchangeImpl.java a helper method was introduced. I've found 
ways to introduce local variables that make Eclipse happy for these cases. 
(Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See 
diffs below.

The type of the local variable in ExchangeImpl.java is a mouthful. Interestingly 
I had to change Function.identity() to the lambda x -> x. I think this is 
because Function.identity() returns a function that doesn't allow its return 
type to vary from its argument, whereas x -> x allows a widening conversion. 
(This might provide a clue as to the differences between javac and Eclipse here, 
but a full understanding eludes me.)

s'marks



diff -r 006dadb903ab 
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Fri May 17 15:46:14 2019 -0700
@@ -1712,9 +1712,7 @@
          Map<?,?> m = (Map<?,?>) o;
          try {
              Comparator<? super K> cmp = comparator;
-            @SuppressWarnings("unchecked")
-            Iterator<Map.Entry<?,?>> it =
-                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
+            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
              if (m instanceof SortedMap &&
                  ((SortedMap<?,?>)m).comparator() == cmp) {
                  Node<K,V> b, n;
diff -r 006dadb903ab 
src/java.management/share/classes/java/lang/management/ManagementFactory.java
--- 
a/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Fri May 17 15:46:14 2019 -0700
@@ -872,12 +872,12 @@
      public static Set<Class<? extends PlatformManagedObject>>
             getPlatformManagementInterfaces()
      {
-        return platformComponents()
+        Stream<Class<? extends PlatformManagedObject>> pmos = platformComponents()
                  .stream()
                  .flatMap(pc -> pc.mbeanInterfaces().stream())
                  .filter(clazz -> 
PlatformManagedObject.class.isAssignableFrom(clazz))
-                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
-                .collect(Collectors.toSet());
+                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
+         return pmos.collect(Collectors.toSet());
      }

      private static final String NOTIF_EMITTER =
diff -r 006dadb903ab 
src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
--- a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Mon May 13 17:15:56 2019 -0700
+++ b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Fri May 17 15:46:14 2019 -0700
@@ -92,8 +92,9 @@
              CompletableFuture<Http2Connection> c2f = 
c2.getConnectionFor(request, exchange);
              if (debug.on())
                  debug.log("get: Trying to get HTTP/2 connection");
-            return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection))
-                    .thenCompose(Function.identity());
+            CompletableFuture<CompletableFuture<? extends ExchangeImpl<U>>> fxi =
+                c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection));
+            return fxi.thenCompose(x -> x);
          }
      }



From aeubanks at google.com  Fri May 17 23:25:27 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 16:25:27 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CALrW1jzcvFrVj3J=_20AQjzL7JdvwudA9VJ5v5btEvt6Vb25-w@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
 <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
 <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>
 <CAPW48spuhzReTTrrv2O4reDbkHjG=EifR56aZRCo3-yu+mFZ+Q@mail.gmail.com>
 <CALrW1jzcvFrVj3J=_20AQjzL7JdvwudA9VJ5v5btEvt6Vb25-w@mail.gmail.com>
Message-ID: <CAPW48spbLC6+NVAN_b5bLho1C4vrjVWyQb0pK+t4axfRXJmtxA@mail.gmail.com>

On Fri, May 17, 2019 at 10:14 AM Jiangli Zhou <jianglizhou at google.com>
wrote:

> On Fri, May 17, 2019 at 9:56 AM Arthur Eubanks <aeubanks at google.com>
> wrote:
> >
> >
> >
> > On Fri, May 17, 2019 at 4:13 AM Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
> >>
> >> Hi Arthur,
> >>
> >> On 17/05/2019 00:18, Arthur Eubanks wrote:
> >> > I've tried to run this through the submit repo twice, haven't gotten a
> >> > result from either run. Could somebody check what's happened to those
> runs?
> >> > The branch names are "JDK-8223214" and "JDK-8223214-1".
> >>
> >> I'm not seeing anything for JDK-8223214 in the history.
> >> When did you submit those? It looks as they never run,
> >> as I can see jobs from some month ago. Maybe the trigger
> >> didn't work (whatever that is).
> >
> > I (actually Jiangli for me) submitted one Wednesday and one Thursday.
>
> That's strange those two jobs didn't show up. The job between those
> did complete.
>
> >>
> >>
> >> Can you submit a again and let me know - and I'll try
> >> to have a look at the jdk-submit CI?
> >
> > Yes I will try again. Thanks for looking at this.
>
> Let me try it from a new cloned repo again...
>
> Thanks,
> Jiangli
>
> >>
> >>
> >> best regards,
> >>
> >> -- daniel
>
Finally got a result, it looks good.

With this change, I think I can start burning down the test failures by
properly running them in our IPv6-only environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/b1b4ef6b/attachment.html>

From jianglizhou at google.com  Fri May 17 23:31:14 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 17 May 2019 16:31:14 -0700
Subject: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should
 choose loopback address that is available
In-Reply-To: <CAPW48spbLC6+NVAN_b5bLho1C4vrjVWyQb0pK+t4axfRXJmtxA@mail.gmail.com>
References: <CAPW48sofkK9qtcrcjrCnABD_K+my75hG=cK+hvXmNUgDVqfWcA@mail.gmail.com>
 <DC0D11DC-2896-41C8-B9D5-05A211B9DED7@oracle.com>
 <CAPW48srqmBWaW=HNOPE93GYsj-Bymed6xyD8gLhcw+Wzcrk0mQ@mail.gmail.com>
 <CAPW48spkWG5ynMXMJ7xLkwSgb8u6sqtF3Gsg+NbH4F0yg7woqA@mail.gmail.com>
 <4556144B-9DB9-451C-AE64-564A39E00851@oracle.com>
 <CAPW48srY10g=hF0DS8ZOKYWR1r8V7WcAGddCmMdgn39bimRkig@mail.gmail.com>
 <018eab06-0c34-9e1b-043d-1297475dcdbb@oracle.com>
 <CAPW48spuhzReTTrrv2O4reDbkHjG=EifR56aZRCo3-yu+mFZ+Q@mail.gmail.com>
 <CALrW1jzcvFrVj3J=_20AQjzL7JdvwudA9VJ5v5btEvt6Vb25-w@mail.gmail.com>
 <CAPW48spbLC6+NVAN_b5bLho1C4vrjVWyQb0pK+t4axfRXJmtxA@mail.gmail.com>
Message-ID: <CALrW1jw+uFYtUpBV2StdvMgRY5pe3c1tWEpXw-adXtNz5h3TMQ@mail.gmail.com>

Great!

Thanks,
Jiangli

On Fri, May 17, 2019 at 4:25 PM Arthur Eubanks <aeubanks at google.com> wrote:

>
>
> On Fri, May 17, 2019 at 10:14 AM Jiangli Zhou <jianglizhou at google.com>
> wrote:
>
>> On Fri, May 17, 2019 at 9:56 AM Arthur Eubanks <aeubanks at google.com>
>> wrote:
>> >
>> >
>> >
>> > On Fri, May 17, 2019 at 4:13 AM Daniel Fuchs <daniel.fuchs at oracle.com>
>> wrote:
>> >>
>> >> Hi Arthur,
>> >>
>> >> On 17/05/2019 00:18, Arthur Eubanks wrote:
>> >> > I've tried to run this through the submit repo twice, haven't gotten
>> a
>> >> > result from either run. Could somebody check what's happened to
>> those runs?
>> >> > The branch names are "JDK-8223214" and "JDK-8223214-1".
>> >>
>> >> I'm not seeing anything for JDK-8223214 in the history.
>> >> When did you submit those? It looks as they never run,
>> >> as I can see jobs from some month ago. Maybe the trigger
>> >> didn't work (whatever that is).
>> >
>> > I (actually Jiangli for me) submitted one Wednesday and one Thursday.
>>
>> That's strange those two jobs didn't show up. The job between those
>> did complete.
>>
>> >>
>> >>
>> >> Can you submit a again and let me know - and I'll try
>> >> to have a look at the jdk-submit CI?
>> >
>> > Yes I will try again. Thanks for looking at this.
>>
>> Let me try it from a new cloned repo again...
>>
>> Thanks,
>> Jiangli
>>
>> >>
>> >>
>> >> best regards,
>> >>
>> >> -- daniel
>>
> Finally got a result, it looks good.
>
> With this change, I think I can start burning down the test failures by
> properly running them in our IPv6-only environment.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190517/2327cb24/attachment.html>

From chris.hegarty at oracle.com  Mon May 20 09:50:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 May 2019 10:50:51 +0100
Subject: [teststabilization] RFR: 8223856: Replace wildcard address with
 loopback or local host in tests - part 8
In-Reply-To: <2302a02f-5f7a-2c9d-49c1-758b5fa85573@oracle.com>
References: <2302a02f-5f7a-2c9d-49c1-758b5fa85573@oracle.com>
Message-ID: <e000b22f-069a-181e-c4c0-1f02f13be4e9@oracle.com>

Daniel,

On 16/05/2019 13:23, Daniel Fuchs wrote:
> Hi,
> 
> Please find below a fix for [1]:
> 8223856: Replace wildcard address with loopback or local host in
>  ???????? tests - part 8
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8223856/webrev.00/index.html

Looks good.

> Some of the test failures weren't all attributable to the use
> of the wildcard: in some cases tests make assumptions that
> are not guaranteed to be true - e.g. given two different
> interfaces `i1` and `i2` you may not assume that because you
> can bind to i1 with port `p`, ephemerally allocated, you should
> also be able to bind to `i2` with the same port `p`.
> 
> In such a case I have taken the liberty to add a retry mechanism,
> (that is: try again the whole thing) in the hope
> of decreasing the probability that someone else might
> be again bound to the new ephemeral port on the other interface.

It's unfortunate that we have to do such things, but I agree
with the pragmatic approach. It should improve the reliability
of these few tests.

-Chris.

From chris.hegarty at oracle.com  Mon May 20 10:02:07 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 May 2019 11:02:07 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <da4b186f-8221-6169-1c6b-bc4a3d2ba36b@oracle.com>

Arthur,

On 17/05/2019 18:22, Arthur Eubanks wrote:
> ...
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/

Looks good.

-Chris.

From chris.hegarty at oracle.com  Mon May 20 10:03:33 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 May 2019 11:03:33 +0100
Subject: [ipv6]: 8224014: Don't run
 test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
In-Reply-To: <CAPW48sq+v1iPEW1NV4MuorLsw8KP04e_-1KO90nDTGqg=OC+nQ@mail.gmail.com>
References: <CAPW48so2PvnP49n6wWGTMGJkEeefO2s2hkyu37QJCXEvDHs_9w@mail.gmail.com>
 <6B9C96A0-0FED-4B1E-BB1B-9FCFD9249A4F@oracle.com>
 <CAPW48sqyjmQbqYMiD2ERJ2cQptpkFZ+vyDwCKWd4QamNBnMktg@mail.gmail.com>
 <5d5a2eea-f232-1fe2-fe27-60267aed61f1@oracle.com>
 <CAPW48sq+v1iPEW1NV4MuorLsw8KP04e_-1KO90nDTGqg=OC+nQ@mail.gmail.com>
Message-ID: <a1039f74-179d-4754-372f-4251ca70cbff@oracle.com>

Arthur,

On 17/05/2019 18:02, Arthur Eubanks wrote:
> ...
> Oh yes, http://cr.openjdk.java.net/~aeubanks/8224014/webrev.02/

Looks good.

-Chris.

From daniel.fuchs at oracle.com  Mon May 20 11:23:43 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 20 May 2019 12:23:43 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <b1d5ff41-44f3-c393-8c41-93975b5a10e3@oracle.com>

On 17/05/2019 18:22, Arthur Eubanks wrote:
> Done, order is protocol family, group/notGroup InetAddress, 
> NetworkInterface, source InetAddress
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/

Looks good to me as well Arthur!

best regard,

-- daniel

From aeubanks at google.com  Mon May 20 21:30:37 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 20 May 2019 14:30:37 -0700
Subject: [ipv6] RFR: 8224248: test/jdk/java/net/InetAddress/CheckJNI.java
 assumes 127.0.0.1 is available
Message-ID: <CAPW48srb14dPGh-_hazOR_=t7ukS4bCAgkrEtBQUYDFA3qnoPg@mail.gmail.com>

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

test/jdk/java/net/InetAddress/CheckJNI.java fails in IPv6-only environments
because 127.0.0.1 is not available.

Cleaned up the test a bit. 127.0.0.1 is now only tested when IPv4 is
available. Added tests for InetAddress.getLoopbackAddress() regardless of
IPv4/IPv6 availability for more coverage (since there is a comment saying
try to invoke as much native code as possible).
Verified this passes in an IPv6-only environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190520/cb565d88/attachment.html>

From aeubanks at google.com  Mon May 20 23:50:57 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 20 May 2019 16:50:57 -0700
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java
 hardcodes 127.0.0.1
Message-ID: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>

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

test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a
security manager works with "http://127.0.0.1". This fails on IPv6-only
systems.

This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 is
available. Created a new class for testing ::1 since we can't have
duplicate classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190520/0cf8da35/attachment.html>

From daniel.fuchs at oracle.com  Tue May 21 17:25:05 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 21 May 2019 18:25:05 +0100
Subject: [teststabilization] RFR: 8224204: Replace wildcard address with
 loopback or local host in tests - part 10
Message-ID: <df7a8cb0-e188-b0af-de2b-197af6ebcf3f@oracle.com>

Hi,

Please find below a patch for:

8224204: Replace wildcard address with loopback or local host in
          tests - part 10
https://bugs.openjdk.java.net/browse/JDK-8224204

which fixes a bunch of sun/net/* tests that were observed failing:

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8224204/webrev.00/index.html

DefaultCaching.java: was modifying a file in the source tree!
                      the rest is mostly editorial changes

Other test are modified to bind to either the local host address
or to the loopback address, instead of the wildcard.

best regards,

-- daniel

From chris.hegarty at oracle.com  Tue May 21 18:36:15 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 21 May 2019 19:36:15 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch
 to spec 
Message-ID: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>

The get/setOption methods of java.net Socket, ServerSocket, and
DatagramSocket, are specified to throw NullPointerException if the given
option name is null ( rather than UnsupportedOperationException, which
is currently thrown ). The implementation correctly did this in JDK 9 (
on *nix platforms at least ), when the methods were added, but has since
regressed.

The fix is straight forward; explicitly check the given option name
using Objects::requireNonNull, and update an existing regression test to
ensure that this behaviour does not unwittingly regress.

Webrev:
  https://cr.openjdk.java.net/~chegar/8224477/webrev.00/

-Chris.


From Alan.Bateman at oracle.com  Tue May 21 19:05:22 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 May 2019 20:05:22 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
Message-ID: <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>

On 21/05/2019 19:36, Chris Hegarty wrote:
> The get/setOption methods of java.net Socket, ServerSocket, and
> DatagramSocket, are specified to throw NullPointerException if the given
> option name is null ( rather than UnsupportedOperationException, which
> is currently thrown ). The implementation correctly did this in JDK 9 (
> on *nix platforms at least ), when the methods were added, but has since
> regressed.
>
> The fix is straight forward; explicitly check the given option name
> using Objects::requireNonNull, and update an existing regression test to
> ensure that this behaviour does not unwittingly regress.
>
> Webrev:
>    https://cr.openjdk.java.net/~chegar/8224477/webrev.00/
>
There are two parts to the issue, one is missing null change (those 
changes are fine), the other is throwing SocketException instead of 
IllegalArgumentException for bad values. Maybe you are splitting that out?

I've had to do a big clean-up to OptionsTest as part of JDK-8221481 so 
we might have to merge the changes.? One nit is the patch here is all 
the "->s" lines in nulls are missing a space.

-Alan

From daniel.fuchs at oracle.com  Wed May 22 08:59:16 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 May 2019 09:59:16 +0100
Subject: [ipv6] RFR: 8224248: test/jdk/java/net/InetAddress/CheckJNI.java
 assumes 127.0.0.1 is available
In-Reply-To: <CAPW48srb14dPGh-_hazOR_=t7ukS4bCAgkrEtBQUYDFA3qnoPg@mail.gmail.com>
References: <CAPW48srb14dPGh-_hazOR_=t7ukS4bCAgkrEtBQUYDFA3qnoPg@mail.gmail.com>
Message-ID: <9f183c26-b56d-1e36-5966-db4b906ceae2@oracle.com>

Hi Arthur,

This looks good to me.

BTW: I sent your patch through our test system and didn't see
any failures.

Reviewed!

best regards,

-- daniel

On 20/05/2019 22:30, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224248
> webrev: http://cr.openjdk.java.net/~aeubanks/8224248/webrev.00/
> 
> test/jdk/java/net/InetAddress/CheckJNI.java fails in IPv6-only 
> environments because 127.0.0.1 is not available.
> 
> Cleaned up the test a bit. 127.0.0.1 is now only tested when IPv4 is 
> available. Added tests for InetAddress.getLoopbackAddress() regardless 
> of IPv4/IPv6 availability for more coverage (since there is a comment 
> saying try to invoke as much native code as possible).
> Verified this passes in an IPv6-only environment.


From chris.hegarty at oracle.com  Wed May 22 12:35:15 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 22 May 2019 13:35:15 +0100
Subject: [teststabilization] RFR: 8224204: Replace wildcard address with
 loopback or local host in tests - part 10
In-Reply-To: <df7a8cb0-e188-b0af-de2b-197af6ebcf3f@oracle.com>
References: <df7a8cb0-e188-b0af-de2b-197af6ebcf3f@oracle.com>
Message-ID: <42AA6686-EEFB-4847-BA49-C10CD8A36ADE@oracle.com>



> On 21 May 2019, at 18:25, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch for:
> 
> 8224204: Replace wildcard address with loopback or local host in
>         tests - part 10
> https://bugs.openjdk.java.net/browse/JDK-8224204
> 
> which fixes a bunch of sun/net/* tests that were observed failing:
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224204/webrev.00/index.html <http://cr.openjdk.java.net/~dfuchs/webrev_8224204/webrev.00/index.html>

Looks ok Daniel.

Trivially, 

  47             try (NTLMServer server  = startServer(new ServerSocket(0, 0, loopback), false)) {

  double space between `server` and `=`.


-Chris.

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

From chris.hegarty at oracle.com  Wed May 22 12:54:22 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 22 May 2019 13:54:22 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
Message-ID: <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>

Alan,

> On 21 May 2019, at 20:05, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 21/05/2019 19:36, Chris Hegarty wrote:
>> The get/setOption methods of java.net Socket, ServerSocket, and
>> DatagramSocket, are specified to throw NullPointerException if the given
>> option name is null ( rather than UnsupportedOperationException, which
>> is currently thrown ). The implementation correctly did this in JDK 9 (
>> on *nix platforms at least ), when the methods were added, but has since
>> regressed.
>> 
>> The fix is straight forward; explicitly check the given option name
>> using Objects::requireNonNull, and update an existing regression test to
>> ensure that this behaviour does not unwittingly regress.
>> 
>> Webrev:
>>   https://cr.openjdk.java.net/~chegar/8224477/webrev.00/
>> 
> There are two parts to the issue, one is missing null change (those changes are fine), the other is throwing SocketException instead of IllegalArgumentException for bad values. Maybe you are splitting that out?

While we're here, let's address both the NPE and the IAE.

Updated webrev:
  https://cr.openjdk.java.net/~chegar/8224477/webrev.01/index.html

The code to check that specific option values are within the specified
range is independent of the particular socket type. I decided to add it
to StandardSocketOptions for two reasons: 1) co-location with its
textual range specification, and 2) is it currently only required by the
plain socket implementations. This could be located elsewhere, and
possibly shared by other code performing range checking ( since these
checks need to be consistent ).

Since the test is more involved now, I created and new separate test, so
there will be no conflict with upcoming changes to OptionsTest.

I verified the test against the NioSocketImpl, and it passes fine for
all cases except one, SO_REUSEADDR. The NioSocketImpl::setOption method
throws NPE instead of IAE when passed a null value. Easy to resolve,
then both socket implementations behave consistently, with regard to 
exceptions being thrown for bad input.

Once we agree the code changes, I'll file a CSR to track the change in
behaviour.

-Chris.

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

From chris.hegarty at oracle.com  Wed May 22 13:28:45 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 22 May 2019 14:28:45 +0100
Subject: [ipv6] RFR: 8224248: test/jdk/java/net/InetAddress/CheckJNI.java
 assumes 127.0.0.1 is available
In-Reply-To: <CAPW48srb14dPGh-_hazOR_=t7ukS4bCAgkrEtBQUYDFA3qnoPg@mail.gmail.com>
References: <CAPW48srb14dPGh-_hazOR_=t7ukS4bCAgkrEtBQUYDFA3qnoPg@mail.gmail.com>
Message-ID: <7D17010F-6119-4B94-8D05-F100D33E21F2@oracle.com>

Arthur,

> On 20 May 2019, at 22:30, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224248 <https://bugs.openjdk.java.net/browse/JDK-8224248>webrev: http://cr.openjdk.java.net/~aeubanks/8224248/webrev.00/ <http://cr.openjdk.java.net/~aeubanks/8224248/webrev.00/>
Looks ok.

-Chris.

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

From chris.hegarty at oracle.com  Wed May 22 13:29:25 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 22 May 2019 14:29:25 +0100
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
Message-ID: <80EDAE74-208E-4B7F-9E4E-CF2879D92C13@oracle.com>

Arthur,

> On 21 May 2019, at 00:50, Arthur Eubanks <aeubanks at google.com <mailto:aeubanks at google.com>> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224256 <https://bugs.openjdk.java.net/browse/JDK-8224256>webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html <http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html>
> 
> test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a security manager works with "http://127.0.0.1 <http://127.0.0.1/>". This fails on IPv6-only systems.
> 
> This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 is available. Created a new class for testing ::1 since we can't have duplicate classes.

I think this is ok.

I?ve included security-dev, as the test in question is in their area.

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

From chris.hegarty at oracle.com  Wed May 22 13:32:07 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 22 May 2019 14:32:07 +0100
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
Message-ID: <CD36046E-A040-4399-9E80-6A0EC536795C@oracle.com>

Arthur,

> On 21 May 2019, at 00:50, Arthur Eubanks <aeubanks at google.com <mailto:aeubanks at google.com>> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224256 <https://bugs.openjdk.java.net/browse/JDK-8224256>webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html <http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html>
> 
> test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a security manager works with "http://127.0.0.1 <http://127.0.0.1/>". This fails on IPv6-only systems.
> 
> This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 is available. Created a new class for testing ::1 since we can't have duplicate classes.

I think this is ok.

I?ve included security-dev, as the test in question is in their area.

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

From daniel.fuchs at oracle.com  Wed May 22 14:14:07 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 May 2019 15:14:07 +0100
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
Message-ID: <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>

Hi Arthur,

   18 // For IPSupport
   19 grant {
   20     permission java.net.SocketPermission "localhost:0", 
"listen,resolve";
   21     permission java.util.PropertyPermission 
"java.net.preferIPv4Stack", "read";
   22 };

It might be better if these permissions were granted to the
library only.

   90     // Base64 encoded bytes of simple class: "package bar2; public 
class Bar2 {}"
   91     private final static String BAR2_CLASS =
   92 
"yv66vgAAADQADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEA" +
...

Which version of javac did you use to generate the class?
I wonder if it should have the same major/minor version than
the other classes in that file. But maybe it doesn't matter.

best regards,

-- daniel

On 21/05/2019 00:50, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224256
> webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html
> 
> test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a 
> security manager works with "http://127.0.0.1". This fails on IPv6-only 
> systems.
> 
> This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 
> is available. Created a new class for testing ::1 since we can't have 
> duplicate classes.


From daniel.fuchs at oracle.com  Wed May 22 14:15:05 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 May 2019 15:15:05 +0100
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
Message-ID: <7985fd58-3d71-b8c3-1114-cd10cc851bea@oracle.com>

Hi Arthur, [adding security-dev]

   18 // For IPSupport
   19 grant {
   20     permission java.net.SocketPermission "localhost:0", 
"listen,resolve";
   21     permission java.util.PropertyPermission 
"java.net.preferIPv4Stack", "read";
   22 };

It might be better if these permissions were granted to the
library only.

   90     // Base64 encoded bytes of simple class: "package bar2; public 
class Bar2 {}"
   91     private final static String BAR2_CLASS =
   92 "yv66vgAAADQADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEA" +
...

Which version of javac did you use to generate the class?
I wonder if it should have the same major/minor version than
the other classes in that file. But maybe it doesn't matter.

best regards,

-- daniel

On 21/05/2019 00:50, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224256
> webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html
> 
> test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a 
> security manager works with "http://127.0.0.1". This fails on IPv6-only 
> systems.
> 
> This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 
> is available. Created a new class for testing ::1 since we can't have 
> duplicate classes.


From aeubanks at google.com  Wed May 22 17:28:35 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 22 May 2019 10:28:35 -0700
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java
 hardcodes 127.0.0.1
In-Reply-To: <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
Message-ID: <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>

On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Arthur,
>
>    18 // For IPSupport
>    19 grant {
>    20     permission java.net.SocketPermission "localhost:0",
> "listen,resolve";
>    21     permission java.util.PropertyPermission
> "java.net.preferIPv4Stack", "read";
>    22 };
>
> It might be better if these permissions were granted to the
> library only.
>
Done.

>
>    90     // Base64 encoded bytes of simple class: "package bar2; public
> class Bar2 {}"
>    91     private final static String BAR2_CLASS =
>    92
> "yv66vgAAADQADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEA" +
> ...
>
> Which version of javac did you use to generate the class?
> I wonder if it should have the same major/minor version than
> the other classes in that file. But maybe it doesn't matter.
>
I believe I used a JDK 8 javac. But yes I don't think it should matter.

>
> best regards,
>
> -- daniel


New webrev:  http://cr.openjdk.java.net/~aeubanks/8224256/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190522/39512b19/attachment.html>

From daniel.fuchs at oracle.com  Wed May 22 17:35:16 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 May 2019 18:35:16 +0100
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
Message-ID: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>

Hi,

Please find below a patch for the next batch of tests
that have been observed failing intermittently.

JBS: https://bugs.openjdk.java.net/browse/JDK-8224603

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

One of them has just acquired a /othervm keyword: it is setting
a default authenticator - which requires running in its own
VM.

best regards,

-- daniel

From daniel.fuchs at oracle.com  Wed May 22 17:40:23 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 May 2019 18:40:23 +0100
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
 <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
Message-ID: <8cc82969-d102-6839-f488-ab93aad8dd50@oracle.com>

Hi Arthur,

On 22/05/2019 18:28, Arthur Eubanks wrote:
> New webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.01/

Looks good to me - please just get someone from security-dev
to review too.

best regards,

-- daniel

From sean.mullan at oracle.com  Wed May 22 19:12:15 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 22 May 2019 15:12:15 -0400
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
 <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
Message-ID: <06ef68d4-db2f-bd58-71f7-f8f4d6e676e5@oracle.com>

On 5/22/19 1:28 PM, Arthur Eubanks wrote:
> On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto:daniel.fuchs at oracle.com>> wrote:
> 
>     Hi Arthur,
> 
>      ? ?18 // For IPSupport
>      ? ?19 grant {
>      ? ?20? ? ?permission java.net.SocketPermission "localhost:0",
>     "listen,resolve";
>      ? ?21? ? ?permission java.util.PropertyPermission
>     "java.net.preferIPv4Stack", "read";
>      ? ?22 };
> 
>     It might be better if these permissions were granted to the
>     library only.
> 
> Done.

Have you tested that with jtreg? I believe it may not work because of 
the way the SecurityManager is enabled inside the test (rather than 
using the jtreg java.security.policy option). You may find that you also 
need to grant those permissions to jtreg.jar since it is higher in the 
call stack. If that is the case, you are probably better off granting 
the permissions to all code, or restructuring the test to use the jtreg 
java.security.policy option, where jtreg installs its own 
SecurityManager to grant itself the proper permissions. However, that 
will require some code changes and granting some additional permissions 
to the test that are needed (for adding a security provider, etc) before 
it currently enables a SM. And that is probably more than you want to do 
for this fix.

--Sean



From aeubanks at google.com  Wed May 22 19:33:15 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 22 May 2019 12:33:15 -0700
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java
 hardcodes 127.0.0.1
In-Reply-To: <06ef68d4-db2f-bd58-71f7-f8f4d6e676e5@oracle.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
 <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
 <06ef68d4-db2f-bd58-71f7-f8f4d6e676e5@oracle.com>
Message-ID: <CAPW48srQEF1qme-3cMn7rPnE6-Uttn4kdGf_RL6rxPG9p051fQ@mail.gmail.com>

On Wed, May 22, 2019 at 12:12 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> On 5/22/19 1:28 PM, Arthur Eubanks wrote:
> > On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs <daniel.fuchs at oracle.com
> > <mailto:daniel.fuchs at oracle.com>> wrote:
> >
> >     Hi Arthur,
> >
> >         18 // For IPSupport
> >         19 grant {
> >         20     permission java.net.SocketPermission "localhost:0",
> >     "listen,resolve";
> >         21     permission java.util.PropertyPermission
> >     "java.net.preferIPv4Stack", "read";
> >         22 };
> >
> >     It might be better if these permissions were granted to the
> >     library only.
> >
> > Done.
>
> Have you tested that with jtreg? I believe it may not work because of
> the way the SecurityManager is enabled inside the test (rather than
> using the jtreg java.security.policy option). You may find that you also
> need to grant those permissions to jtreg.jar since it is higher in the
> call stack. If that is the case, you are probably better off granting
> the permissions to all code, or restructuring the test to use the jtreg
> java.security.policy option, where jtreg installs its own
> SecurityManager to grant itself the proper permissions. However, that
> will require some code changes and granting some additional permissions
> to the test that are needed (for adding a security provider, etc) before
> it currently enables a SM. And that is probably more than you want to do
> for this fix.
>
> --Sean
>
Tried it directly with jtreg
$ ~/jtreg/build/images/jtreg/bin/jtreg -jdk:./images/jdk/
../test/jdk/java/security/SecureClassLoader/DefineClass.java
and it passes. Verified that removing the newly added permissions makes it
fail again.
There was some discussion on IPSupport and SecurityManagers when IPSupport
was first introduced: https://markmail.org/message/vvemfm367ja3qllj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190522/6e47de90/attachment.html>

From sean.mullan at oracle.com  Wed May 22 19:48:16 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 22 May 2019 15:48:16 -0400
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
In-Reply-To: <CAPW48srQEF1qme-3cMn7rPnE6-Uttn4kdGf_RL6rxPG9p051fQ@mail.gmail.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
 <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
 <06ef68d4-db2f-bd58-71f7-f8f4d6e676e5@oracle.com>
 <CAPW48srQEF1qme-3cMn7rPnE6-Uttn4kdGf_RL6rxPG9p051fQ@mail.gmail.com>
Message-ID: <85932be8-8f33-b91a-c1c7-fb510410c5db@oracle.com>

On 5/22/19 3:33 PM, Arthur Eubanks wrote:
> 
> 
> On Wed, May 22, 2019 at 12:12 PM Sean Mullan <sean.mullan at oracle.com 
> <mailto:sean.mullan at oracle.com>> wrote:
> 
>     On 5/22/19 1:28 PM, Arthur Eubanks wrote:
>      > On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs
>     <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>      > <mailto:daniel.fuchs at oracle.com
>     <mailto:daniel.fuchs at oracle.com>>> wrote:
>      >
>      >? ? ?Hi Arthur,
>      >
>      >? ? ? ? ?18 // For IPSupport
>      >? ? ? ? ?19 grant {
>      >? ? ? ? ?20? ? ?permission java.net.SocketPermission "localhost:0",
>      >? ? ?"listen,resolve";
>      >? ? ? ? ?21? ? ?permission java.util.PropertyPermission
>      >? ? ?"java.net.preferIPv4Stack", "read";
>      >? ? ? ? ?22 };
>      >
>      >? ? ?It might be better if these permissions were granted to the
>      >? ? ?library only.
>      >
>      > Done.
> 
>     Have you tested that with jtreg? I believe it may not work because of
>     the way the SecurityManager is enabled inside the test (rather than
>     using the jtreg java.security.policy option). You may find that you
>     also
>     need to grant those permissions to jtreg.jar since it is higher in the
>     call stack. If that is the case, you are probably better off granting
>     the permissions to all code, or restructuring the test to use the jtreg
>     java.security.policy option, where jtreg installs its own
>     SecurityManager to grant itself the proper permissions. However, that
>     will require some code changes and granting some additional permissions
>     to the test that are needed (for adding a security provider, etc)
>     before
>     it currently enables a SM. And that is probably more than you want
>     to do
>     for this fix.
> 
>     --Sean
> 
> Tried it directly with jtreg
> $?~/jtreg/build/images/jtreg/bin/jtreg -jdk:./images/jdk/ 
> ../test/jdk/java/security/SecureClassLoader/DefineClass.java
> and it passes. Verified that removing the newly added permissions makes 
> it fail again.
> There was some discussion on IPSupport and SecurityManagers when 
> IPSupport was first introduced: 
> https://markmail.org/message/vvemfm367ja3qllj

Ok, the fix looks good then to me.

--Sean

From aeubanks at google.com  Thu May 23 02:36:26 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 22 May 2019 19:36:26 -0700
Subject: [ipv6] RFR: 8224256:
 test/jdk/java/security/SecureClassLoader/DefineClass.java
 hardcodes 127.0.0.1
In-Reply-To: <85932be8-8f33-b91a-c1c7-fb510410c5db@oracle.com>
References: <CAPW48sry0fckU+osTd_C97NW=Uby=MY_NUL0A_-F7sYaAtcqZQ@mail.gmail.com>
 <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com>
 <CAPW48spUh_koRxAq+YHiwLvHv8Qxuxns=WaSuMs12O63yuuyTQ@mail.gmail.com>
 <06ef68d4-db2f-bd58-71f7-f8f4d6e676e5@oracle.com>
 <CAPW48srQEF1qme-3cMn7rPnE6-Uttn4kdGf_RL6rxPG9p051fQ@mail.gmail.com>
 <85932be8-8f33-b91a-c1c7-fb510410c5db@oracle.com>
Message-ID: <CAPW48sr_n-GuHunAZVMAryjZ7XdV66PabBMWUNfe4i9_sMnvYQ@mail.gmail.com>

Looks like this test is now failing, I'll take a look tomorrow, sorry about
this.

On Wed, May 22, 2019, 12:48 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> On 5/22/19 3:33 PM, Arthur Eubanks wrote:
> >
> >
> > On Wed, May 22, 2019 at 12:12 PM Sean Mullan <sean.mullan at oracle.com
> > <mailto:sean.mullan at oracle.com>> wrote:
> >
> >     On 5/22/19 1:28 PM, Arthur Eubanks wrote:
> >      > On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs
> >     <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
> >      > <mailto:daniel.fuchs at oracle.com
> >     <mailto:daniel.fuchs at oracle.com>>> wrote:
> >      >
> >      >     Hi Arthur,
> >      >
> >      >         18 // For IPSupport
> >      >         19 grant {
> >      >         20     permission java.net.SocketPermission "localhost:0",
> >      >     "listen,resolve";
> >      >         21     permission java.util.PropertyPermission
> >      >     "java.net.preferIPv4Stack", "read";
> >      >         22 };
> >      >
> >      >     It might be better if these permissions were granted to the
> >      >     library only.
> >      >
> >      > Done.
> >
> >     Have you tested that with jtreg? I believe it may not work because of
> >     the way the SecurityManager is enabled inside the test (rather than
> >     using the jtreg java.security.policy option). You may find that you
> >     also
> >     need to grant those permissions to jtreg.jar since it is higher in
> the
> >     call stack. If that is the case, you are probably better off granting
> >     the permissions to all code, or restructuring the test to use the
> jtreg
> >     java.security.policy option, where jtreg installs its own
> >     SecurityManager to grant itself the proper permissions. However, that
> >     will require some code changes and granting some additional
> permissions
> >     to the test that are needed (for adding a security provider, etc)
> >     before
> >     it currently enables a SM. And that is probably more than you want
> >     to do
> >     for this fix.
> >
> >     --Sean
> >
> > Tried it directly with jtreg
> > $ ~/jtreg/build/images/jtreg/bin/jtreg -jdk:./images/jdk/
> > ../test/jdk/java/security/SecureClassLoader/DefineClass.java
> > and it passes. Verified that removing the newly added permissions makes
> > it fail again.
> > There was some discussion on IPSupport and SecurityManagers when
> > IPSupport was first introduced:
> > https://markmail.org/message/vvemfm367ja3qllj
>
> Ok, the fix looks good then to me.
>
> --Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190522/f5656ac3/attachment-0001.html>

From Alan.Bateman at oracle.com  Thu May 23 08:13:57 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 May 2019 09:13:57 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
Message-ID: <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>

On 22/05/2019 13:54, Chris Hegarty wrote:
>
> While we're here, let's address both the NPE and the IAE.
Okay, I only mentioned it because the JIRA issue had two cases. Also 
it's one that we came across when working on the new implementation (it 
is called out as a compatibility difference in the Risks and Assumptions 
second). Part of this is that Socket.setOption specifies IAE for invalid 
values but SocketImpl.setOption doesn't specify anything. The validation 
of the value has to be done by the SocketImpl as it may relate to socket 
options that the Socket API doesn't know anything about so I think 
SocketImpl.setOption has to specify IAE. I'm not suggesting we expand 
the scope of the issue here but they are related.

>
> Updated webrev:
> https://cr.openjdk.java.net/~chegar/8224477/webrev.01/index.html
>
> The code to check that specific option values are within the specified
> range is independent of the particular socket type. I decided to add it
> to StandardSocketOptions for two reasons: 1) co-location with its
> textual range specification, and 2) is it currently only required by the
> plain socket implementations. This could be located elsewhere, and
> possibly shared by other code performing range checking ( since these
> checks need to be consistent ).
>
> Since the test is more involved now, I created and new separate test, so
> there will be no conflict with upcoming changes to OptionsTest.
I went through the webrev.

The new test looks great. A suggestion for the name is NullsAndBadValues 
as that sort of sums up what it does.

One comment on AbstractPlainSocketImpl.setOption is that it means calls 
to the impl setOption will call PlainSocketImpl.setOption, it will 
delegate to the super class, which will in turn delegate to its super 
class. I'm just wondering if the PlainSocketImpl.setOption can be 
subsumed into AbstractPlainSocketImpl.

I don't think StandardSocketOptions is the right place for 
throwIfIllegalValue. It may be convenient but this class defines 
constants and wasn't really meant to be a helper class too. I guess one 
could make StdSocketOption package private and add a validate check but 
I think that would complicate it too. The check also reminds me that 0 
is valid as the send/receive buffer size in some APIs but not in others. 
This may be something we re-visit in time as it might make sense to have 
IAE throw on platforms where 0 is not valid.

>
> I verified the test against the NioSocketImpl, and it passes fine for
> all cases except one, SO_REUSEADDR. The NioSocketImpl::setOption method
> throws NPE instead of IAE when passed a null value. Easy to resolve,
> then both socket implementations behave consistently, with regard to
> exceptions being thrown for bad input.
Thanks for checking this. Windows uses exclude bind so SO_REUSEADDR is a 
no-op, that code path needs to check the value is null before casting it 
to a Boolean.

>
> Once we agree the code changes, I'll file a CSR to track the change in
> behaviour.
Right, there's behavior change so a CSR make sense.

-Alan

From daniel.fuchs at oracle.com  Thu May 23 10:30:22 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 11:30:22 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
Message-ID: <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>

Hi,

I have observed an intermittent failure on Solaris.
So I changed the patch to problem-list the test on all platform.

Is that still OK?

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

best regards,

-- daniel

On 23/05/2019 10:32, Daniel Fuchs wrote:
> Hi,
> 
> Please find a patch below that temporarily problem lists
> java/security/SecureClassLoader/DefineClass.java
> on linux and windows until JDK-8224635 [1] is fixed:
> 
> 8224656: Problem list java/security/SecureClassLoader/DefineClass.java
>  ???????? until JDK-8224635 is fixed
> https://bugs.openjdk.java.net/browse/JDK-8224656
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/

From Alan.Bateman at oracle.com  Thu May 23 10:31:50 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 May 2019 11:31:50 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
 <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
Message-ID: <2018ec3e-cc90-9117-6467-51d24fdddf59@oracle.com>



On 23/05/2019 11:30, Daniel Fuchs wrote:
> Hi,
>
> I have observed an intermittent failure on Solaris.
> So I changed the patch to problem-list the test on all platform.
>
> Is that still OK?
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01
Looks fine.

From chris.hegarty at oracle.com  Thu May 23 10:34:13 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 May 2019 11:34:13 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
 <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
Message-ID: <B076CFD3-D32C-4D9F-88F7-5AA7539F7C2F@oracle.com>

Daniel,

> On 23 May 2019, at 11:30, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> I have observed an intermittent failure on Solaris.
> So I changed the patch to problem-list the test on all platform.
> 
> Is that still OK?
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 <http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01>

Looks good.

-Chris.

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

From christoph.langer at sap.com  Thu May 23 13:39:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 23 May 2019 13:39:08 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
Message-ID: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Stuart,

big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

So, for ConcurrentSkipListMap.java, the new coding is a real improvement, removing a @SuppressWarnings("unchecked") and a cast which are both unnecessary then.
@Martin Buchholz: What do I have to do to get this into the jsr166 integration 2019-06? Shall I open a separate bug? Or shall it be committed with the fix to JDK-8223553? Please guide me.

In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround.

At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207. 

I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided?

Thank you
Christoph


> -----Original Message-----
> From: Stuart Marks <stuart.marks at oracle.com>
> Sent: Samstag, 18. Mai 2019 00:56
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: David Holmes <david.holmes at oracle.com>; Daniel Fuchs
> <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>; compiler-
> dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm still not entirely sure why this is so, but the introduction of a local
> variable in MethodHandles.java seems to make things work for Eclipse.
> Addition
> of a local variable seems to be minimally invasive, so it makes sense to see if
> this technique can be applied to other cases.
> 
> (In ConcurrentSkipListMap the issue seems to be solved by addition of
> wildcards,
> as I had suggested previously, and it cleans up the unchecked cast that was
> there in the first place. So I think that one is ok already.)
> 
> In ManagementFactory.java, an unchecked cast and warnings suppression is
> introduced, and in ExchangeImpl.java a helper method was introduced. I've
> found
> ways to introduce local variables that make Eclipse happy for these cases.
> (Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See
> diffs below.
> 
> The type of the local variable in ExchangeImpl.java is a mouthful.
> Interestingly
> I had to change Function.identity() to the lambda x -> x. I think this is
> because Function.identity() returns a function that doesn't allow its return
> type to vary from its argument, whereas x -> x allows a widening conversion.
> (This might provide a clue as to the differences between javac and Eclipse
> here,
> but a full understanding eludes me.)
> 
> s'marks
> 
> 
> 
> diff -r 006dadb903ab
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j
> ava
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j
> ava
> Fri May 17 15:46:14 2019 -0700
> @@ -1712,9 +1712,7 @@
>           Map<?,?> m = (Map<?,?>) o;
>           try {
>               Comparator<? super K> cmp = comparator;
> -            @SuppressWarnings("unchecked")
> -            Iterator<Map.Entry<?,?>> it =
> -                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
> +            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
>               if (m instanceof SortedMap &&
>                   ((SortedMap<?,?>)m).comparator() == cmp) {
>                   Node<K,V> b, n;
> diff -r 006dadb903ab
> src/java.management/share/classes/java/lang/management/ManagementF
> actory.java
> ---
> a/src/java.management/share/classes/java/lang/management/Managemen
> tFactory.java
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.management/share/classes/java/lang/management/Managemen
> tFactory.java
> Fri May 17 15:46:14 2019 -0700
> @@ -872,12 +872,12 @@
>       public static Set<Class<? extends PlatformManagedObject>>
>              getPlatformManagementInterfaces()
>       {
> -        return platformComponents()
> +        Stream<Class<? extends PlatformManagedObject>> pmos =
> platformComponents()
>                   .stream()
>                   .flatMap(pc -> pc.mbeanInterfaces().stream())
>                   .filter(clazz ->
> PlatformManagedObject.class.isAssignableFrom(clazz))
> -                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
> -                .collect(Collectors.toSet());
> +                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
> +         return pmos.collect(Collectors.toSet());
>       }
> 
>       private static final String NOTIF_EMITTER =
> diff -r 006dadb903ab
> src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> ---
> a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> Fri May 17 15:46:14 2019 -0700
> @@ -92,8 +92,9 @@
>               CompletableFuture<Http2Connection> c2f =
> c2.getConnectionFor(request, exchange);
>               if (debug.on())
>                   debug.log("get: Trying to get HTTP/2 connection");
> -            return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection))
> -                    .thenCompose(Function.identity());
> +            CompletableFuture<CompletableFuture<? extends
> ExchangeImpl<U>>> fxi =
> +                c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection));
> +            return fxi.thenCompose(x -> x);
>           }
>       }
> 


From daniel.fuchs at oracle.com  Thu May 23 13:47:26 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 14:47:26 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <bea5f221-235d-9138-d039-b449a98e2510@oracle.com>

On 23/05/2019 14:39, Langer, Christoph wrote:
> big thanks for your great updates here. This all looks a lot cleaner:http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

I concur. Thanks Stuart!

best regards,

-- daniel

From aleksej.efimov at oracle.com  Thu May 23 14:01:14 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 23 May 2019 15:01:14 +0100
Subject: [teststabilization] RFR: 8224035 : Replace wildcard address with
 loopback or local host in tests - part 9
Message-ID: <980e10a1-0c05-29af-4318-a2b01307c1a5@oracle.com>

Hi,

Please help to review another part of test fixes to address intermittent 
networking failures:
http://cr.openjdk.java.net/~aefimov/8224035/00

JBS:
https://bugs.openjdk.java.net/browse/JDK-8224035

With Best Regards,
Aleksei

From daniel.fuchs at oracle.com  Thu May 23 14:18:44 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 15:18:44 +0100
Subject: [teststabilization] RFR: 8224035 : Replace wildcard address with
 loopback or local host in tests - part 9
In-Reply-To: <980e10a1-0c05-29af-4318-a2b01307c1a5@oracle.com>
References: <980e10a1-0c05-29af-4318-a2b01307c1a5@oracle.com>
Message-ID: <5190d533-3e2b-365e-a981-481c59994abd@oracle.com>

Hi Aleks,

Looks good to me.

If possible please avoid long lines.
Sometimes a convenient way to do that is to create
a server socket without any arguments and then bind it.
This has the additional advantage of avoiding the 3-args
constructor which Alan doesn't like ;-)

best regards,

-- daniel

On 23/05/2019 15:01, Aleks Efimov wrote:
> Hi,
> 
> Please help to review another part of test fixes to address intermittent 
> networking failures:
> http://cr.openjdk.java.net/~aefimov/8224035/00
> 
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8224035
> 
> With Best Regards,
> Aleksei


From jianglizhou at google.com  Thu May 23 14:34:25 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 23 May 2019 07:34:25 -0700
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java
 until JDK-8224635 is fixed
In-Reply-To: <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
 <ca0f0cb5-9e89-06d9-963f-c0a3787783dd@oracle.com>
Message-ID: <CALrW1jytvV5=dMT9tGgd1BdgKq5+R+pYKQ19zjcBCSMwjtqZWw@mail.gmail.com>

Hi Daniel,

Thanks for the quick action for problem listing the test!

Best regards,
Jiangli

On Thu, May 23, 2019 at 3:30 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
> Hi,
>
> I have observed an intermittent failure on Solaris.
> So I changed the patch to problem-list the test on all platform.
>
> Is that still OK?
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01
>
> best regards,
>
> -- daniel
>
> On 23/05/2019 10:32, Daniel Fuchs wrote:
> > Hi,
> >
> > Please find a patch below that temporarily problem lists
> > java/security/SecureClassLoader/DefineClass.java
> > on linux and windows until JDK-8224635 [1] is fixed:
> >
> > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java
> >           until JDK-8224635 is fixed
> > https://bugs.openjdk.java.net/browse/JDK-8224656
> >
> > webrev:
> > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/

From aeubanks at google.com  Thu May 23 16:08:01 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 23 May 2019 09:08:01 -0700
Subject: [RFR] 8224635: Revert 8224256 and add back
 java/security/SecureClassLoader/DefineClass.java test
Message-ID: <CAPW48sqZxuJSYQ3xwd+94dcK05UvjtXp4+OgMFp6cFK9kfxmEw@mail.gmail.com>

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

Test java/security/SecureClassLoader/DefineClass.java is failing after
JDK-8224256
This change reverts the changes in JDK-8224256 and adds back in the test.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190523/ce96beb8/attachment.html>

From sean.mullan at oracle.com  Thu May 23 16:21:12 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 23 May 2019 12:21:12 -0400
Subject: [RFR] 8224635: Revert 8224256 and add back
 java/security/SecureClassLoader/DefineClass.java test
In-Reply-To: <CAPW48sqZxuJSYQ3xwd+94dcK05UvjtXp4+OgMFp6cFK9kfxmEw@mail.gmail.com>
References: <CAPW48sqZxuJSYQ3xwd+94dcK05UvjtXp4+OgMFp6cFK9kfxmEw@mail.gmail.com>
Message-ID: <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com>

Looks fine although you should update the 8224635 title to match the 
changeset.

Also, I assume you will file a followon bug for the original issue 
(JDK-8224256). I think a new bug must be filed instead of re-opening 
8224256 because a changeset has already been pushed for it.

--Sean

On 5/23/19 12:08 PM, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224635
> webrev: http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html
> 
> Test java/security/SecureClassLoader/DefineClass.java is failing after 
> JDK-8224256
> This change reverts the changes in?JDK-8224256 and adds back in the test.

From aeubanks at google.com  Thu May 23 16:28:33 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 23 May 2019 09:28:33 -0700
Subject: [RFR] 8224635: Revert 8224256 and add back
 java/security/SecureClassLoader/DefineClass.java test
In-Reply-To: <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com>
References: <CAPW48sqZxuJSYQ3xwd+94dcK05UvjtXp4+OgMFp6cFK9kfxmEw@mail.gmail.com>
 <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com>
Message-ID: <CAPW48sq4xS2oMVMvSOV_tMzNBmSTC7cr3i0T0n=y=4=-B_UJPA@mail.gmail.com>

On Thu, May 23, 2019 at 9:23 AM Sean Mullan <sean.mullan at oracle.com> wrote:

> Looks fine although you should update the 8224635 title to match the
> changeset.
>
Done

>
> Also, I assume you will file a followon bug for the original issue
> (JDK-8224256). I think a new bug must be filed instead of re-opening
> 8224256 because a changeset has already been pushed for it.
>
Yes I will file another bug to get this back in, this time making sure that
it passes on mach5 tier2 before submitting.

>
> --Sean
>
> On 5/23/19 12:08 PM, Arthur Eubanks wrote:
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224635
> > webrev:
> http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html
> >
> > Test java/security/SecureClassLoader/DefineClass.java is failing after
> > JDK-8224256
> > This change reverts the changes in JDK-8224256 and adds back in the test.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190523/f11a52f8/attachment.html>

From chris.hegarty at oracle.com  Thu May 23 16:32:53 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 May 2019 17:32:53 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
Message-ID: <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>

Thank you Alan,

I believe that I addressed all your comments and suggestions.

Additionally, while here I noticed an issue where these methods were not
always consistent with their spec to throw IOException when the socket
has been closed.

https://cr.openjdk.java.net/~chegar/8224477/webrev.02/

-Chris.


> On 23 May 2019, at 09:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 22/05/2019 13:54, Chris Hegarty wrote:
>> 
>> While we're here, let's address both the NPE and the IAE.
> Okay, I only mentioned it because the JIRA issue had two cases. Also it's one that we came across when working on the new implementation (it is called out as a compatibility difference in the Risks and Assumptions second). Part of this is that Socket.setOption specifies IAE for invalid values but SocketImpl.setOption doesn't specify anything. The validation of the value has to be done by the SocketImpl as it may relate to socket options that the Socket API doesn't know anything about so I think SocketImpl.setOption has to specify IAE. I'm not suggesting we expand the scope of the issue here but they are related.
> 
>> 
>> Updated webrev:
>> https://cr.openjdk.java.net/~chegar/8224477/webrev.01/index.html
>> 
>> The code to check that specific option values are within the specified
>> range is independent of the particular socket type. I decided to add it
>> to StandardSocketOptions for two reasons: 1) co-location with its
>> textual range specification, and 2) is it currently only required by the
>> plain socket implementations. This could be located elsewhere, and
>> possibly shared by other code performing range checking ( since these
>> checks need to be consistent ).
>> 
>> Since the test is more involved now, I created and new separate test, so
>> there will be no conflict with upcoming changes to OptionsTest.
> I went through the webrev.
> 
> The new test looks great. A suggestion for the name is NullsAndBadValues as that sort of sums up what it does.
> 
> One comment on AbstractPlainSocketImpl.setOption is that it means calls to the impl setOption will call PlainSocketImpl.setOption, it will delegate to the super class, which will in turn delegate to its super class. I'm just wondering if the PlainSocketImpl.setOption can be subsumed into AbstractPlainSocketImpl.
> 
> I don't think StandardSocketOptions is the right place for throwIfIllegalValue. It may be convenient but this class defines constants and wasn't really meant to be a helper class too. I guess one could make StdSocketOption package private and add a validate check but I think that would complicate it too. The check also reminds me that 0 is valid as the send/receive buffer size in some APIs but not in others. This may be something we re-visit in time as it might make sense to have IAE throw on platforms where 0 is not valid.
> 
>> 
>> I verified the test against the NioSocketImpl, and it passes fine for
>> all cases except one, SO_REUSEADDR. The NioSocketImpl::setOption method
>> throws NPE instead of IAE when passed a null value. Easy to resolve,
>> then both socket implementations behave consistently, with regard to
>> exceptions being thrown for bad input.
> Thanks for checking this. Windows uses exclude bind so SO_REUSEADDR is a no-op, that code path needs to check the value is null before casting it to a Boolean.
> 
>> 
>> Once we agree the code changes, I'll file a CSR to track the change in
>> behaviour.
> Right, there's behavior change so a CSR make sense.
> 
> -Alan


From aleksej.efimov at oracle.com  Thu May 23 17:19:08 2019
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 23 May 2019 18:19:08 +0100
Subject: [teststabilization] RFR: 8224035 : Replace wildcard address with
 loopback or local host in tests - part 9
In-Reply-To: <5190d533-3e2b-365e-a981-481c59994abd@oracle.com>
References: <980e10a1-0c05-29af-4318-a2b01307c1a5@oracle.com>
 <5190d533-3e2b-365e-a981-481c59994abd@oracle.com>
Message-ID: <cfc21946-af54-1a14-632f-199685ebaf01@oracle.com>

Hi Daniel,

Thank you for the review.

I've tried to avoid 3-args constructor and/or long lines as you suggested:
http://cr.openjdk.java.net/~aefimov/8224035/01/index.html

Best,
Aleksei

On 23/05/2019 15:18, Daniel Fuchs wrote:
> Hi Aleks,
>
> Looks good to me.
>
> If possible please avoid long lines.
> Sometimes a convenient way to do that is to create
> a server socket without any arguments and then bind it.
> This has the additional advantage of avoiding the 3-args
> constructor which Alan doesn't like ;-)
>
> best regards,
>
> -- daniel
>
> On 23/05/2019 15:01, Aleks Efimov wrote:
>> Hi,
>>
>> Please help to review another part of test fixes to address 
>> intermittent networking failures:
>> http://cr.openjdk.java.net/~aefimov/8224035/00
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8224035
>>
>> With Best Regards,
>> Aleksei
>


From aeubanks at google.com  Thu May 23 17:19:56 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 23 May 2019 10:19:56 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
Message-ID: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>

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

Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
NoSuchElementException on Solaris.

java.util.NoSuchElementException
at java.base/java.util.Spliterators$1Adapter.next(Spliterators.java:688)
at BasicMulticastTests.main(BasicMulticastTests.java:221)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)

at java.base/java.lang.Thread.run(Thread.java:830)

This changes the test to check if any multicast interfaces are available
for IPv4/IPv6 before testing one. This does have the effect of not failing
if no multicast interfaces available, which may or may not be desirable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190523/52d876a9/attachment.html>

From daniel.fuchs at oracle.com  Thu May 23 17:31:07 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 18:31:07 +0100
Subject: [teststabilization] RFR: 8224035 : Replace wildcard address with
 loopback or local host in tests - part 9
In-Reply-To: <cfc21946-af54-1a14-632f-199685ebaf01@oracle.com>
References: <980e10a1-0c05-29af-4318-a2b01307c1a5@oracle.com>
 <5190d533-3e2b-365e-a981-481c59994abd@oracle.com>
 <cfc21946-af54-1a14-632f-199685ebaf01@oracle.com>
Message-ID: <c63e09b3-3655-49c6-fcfd-ea1ea8ca0a71@oracle.com>

Looks good to me!

best regards,

-- daniel

On 23/05/2019 18:19, Aleks Efimov wrote:
> Hi Daniel,
> 
> Thank you for the review.
> 
> I've tried to avoid 3-args constructor and/or long lines as you suggested:
> http://cr.openjdk.java.net/~aefimov/8224035/01/index.html
> 
> Best,
> Aleksei

From stuart.marks at oracle.com  Thu May 23 19:10:52 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 23 May 2019 12:10:52 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>



On 5/23/19 6:39 AM, Langer, Christoph wrote:
> big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

Great, glad to help. While I'm still unsure about the underlying reasons for 
this disagreement between the compilers, that might take a while to resolve. 
Putting in these fixes isn't very intrusive and it seems to make people's lives 
easier, so I don't have any objection to them going in.

> In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround.
> 
> At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207.
> 
> I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided?

Overall, introducing a local variable is more-or-less reasonable even if it's 
used only once. One point is that somebody might come along and "clean up" the 
code and inline local variables and reintroduce the problem. Another point is 
that, hypothetically, if in the future Eclipse is changed to match javac's 
behavior, these changes should be reverted.

The bug database is a good place to capture actions that need to take place in 
the future. Unfortunately, it's pretty far from these locations, so the 
existence of such a bug wouldn't prevent the accidental cleanup from happening. 
That would indicate having a comment in the code at these locations.

On the other hand, if Eclipse is "fixed" and these locations don't get cleaned 
up for a long time, it doesn't seem like that big a deal.

I'd suggest to put a comment at these 3 locations, something like:

     // local variable required here; see JDK-8223553

and not bother with filing another bug report to track this.

I'll defer to Martin as to how he wants to handle the ConcurrentSkipListMap.java 
change.

s'marks

From christoph.langer at sap.com  Thu May 23 21:23:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 23 May 2019 21:23:27 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>
Message-ID: <AM6PR02MB5192D07EFE7EFBE9566B5DDD8A010@AM6PR02MB5192.eurprd02.prod.outlook.com>

> Overall, introducing a local variable is more-or-less reasonable even if it's
> used only once. One point is that somebody might come along and "clean
> up" the
> code and inline local variables and reintroduce the problem. Another point is
> that, hypothetically, if in the future Eclipse is changed to match javac's
> behavior, these changes should be reverted.
>
> The bug database is a good place to capture actions that need to take place in
> the future. Unfortunately, it's pretty far from these locations, so the
> existence of such a bug wouldn't prevent the accidental cleanup from
> happening.
> That would indicate having a comment in the code at these locations.
>
> On the other hand, if Eclipse is "fixed" and these locations don't get cleaned
> up for a long time, it doesn't seem like that big a deal.
>
> I'd suggest to put a comment at these 3 locations, something like:
>
>      // local variable required here; see JDK-8223553
>
> and not bother with filing another bug report to track this.

Ok, good idea. I'll add the comment before I push.

> I'll defer to Martin as to how he wants to handle the
> ConcurrentSkipListMap.java
> change.

As Martin has taken this to the jsr166 integration 2019-06, I'll push the change without ConcurrentSkipListMap.java tomorrow.

Thanks to all involved in this review!
/Christoph


From aeubanks at google.com  Fri May 24 00:14:07 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Thu, 23 May 2019 17:14:07 -0700
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
 <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
 <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>
Message-ID: <CAPW48spwaQ_YBgyY4qd9+vpWav2ovLGT+gfE=EpxwV2EADAMmg@mail.gmail.com>

Ping on a review from security-dev.

On Fri, May 17, 2019 at 9:53 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Arthur,
>
> On 17 May 2019, at 17:50, Arthur Eubanks <aeubanks at google.com> wrote:
>
> Looks good.
>>
>> Trivially, maybe amend the comment to be more explicit
>>
>>    86       // SOCKS V4 ( requires IPv4 )
>>
>> -Chris.
>>
> Done
> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/
>
> I will wait for another review from security-dev.
>
>
> You have my Review ( conditional on a Reviewer for the test in the
> security area ).
>
> -Chris.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190523/bf9e74d0/attachment-0001.html>

From Alan.Bateman at oracle.com  Fri May 24 07:28:50 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 May 2019 08:28:50 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
Message-ID: <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>

On 23/05/2019 17:32, Chris Hegarty wrote:
> Thank you Alan,
>
> I believe that I addressed all your comments and suggestions.
>
> Additionally, while here I noticed an issue where these methods were not
> always consistent with their spec to throw IOException when the socket
> has been closed.
>
> https://cr.openjdk.java.net/~chegar/8224477/webrev.02/
>
The isClosed checks look fine although a Socket/SS/DS could be 
asynchronously closed so needs to be handled by the impl when the Socket 
doesn't provide the coordination with close. This is a long standing 
rats nest of course, and should go away with the new implementation.

The new AfterClose and the now renamed NullsAndBadValues seems very 
comprehensive.

I have a few comments on the new setOption/getOption implementation:

- The value == null check isn't needed as it will be caught by the 
isInstance(value) check

- I think the checks in StdSocketOptionUtil.throwIfBadValue should be 
moved into SocketImpl.setOption and DatagramSocketImpl.setOption.? That 
is, these methods map new to old and I think are the right place to 
reject values that should throw IAE. This should avoid the override need 
to validate the values before delegating to the super class.

- I think SocketImpl.setOption needs the same 
name.type().isInstance(value) check. Not important but would ensure that 
any pre JDK 9 SocketImpls throw the right exception (the issue of 
SocketImpl.setOption not specifying IAE is another issue of course).

-Alan

From chris.hegarty at oracle.com  Fri May 24 13:03:46 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 24 May 2019 14:03:46 +0100
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
In-Reply-To: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
References: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
Message-ID: <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>


On 22/05/2019 18:35, Daniel Fuchs wrote:
> Hi,
> 
> Please find below a patch for the next batch of tests
> that have been observed failing intermittently.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224603
> 
> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8224603/webrev.00/

Looks ok to me Daniel.

-Chris.

From vyommani at gmail.com  Fri May 24 13:36:20 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 24 May 2019 19:06:20 +0530
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
In-Reply-To: <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>
References: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
 <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>
Message-ID: <CAKysZ8zAPRob+NPaf_b0yJEXTzN8ntDbY-wV1aAni7xx8jbg6A@mail.gmail.com>

Hi Daniel,
Overall changes looks good to me, please update the copy write date that
you missed in couple of files. In "TestHttpServer.java"  we are printing
error message on System.err and throwing the RuntimeException both as
below, do you think we need both ?

 System.err.println ("Server could not start: " + e);+ throw new
RuntimeException("Server could not start: " + e, e);

Thanks,
Vyom

On Fri, May 24, 2019 at 6:33 PM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

>
> On 22/05/2019 18:35, Daniel Fuchs wrote:
> > Hi,
> >
> > Please find below a patch for the next batch of tests
> > that have been observed failing intermittently.
> >
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8224603
> >
> > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8224603/webrev.00/
>
> Looks ok to me Daniel.
>
> -Chris.
>


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

From daniel.fuchs at oracle.com  Fri May 24 14:02:52 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 May 2019 15:02:52 +0100
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
In-Reply-To: <CAKysZ8zAPRob+NPaf_b0yJEXTzN8ntDbY-wV1aAni7xx8jbg6A@mail.gmail.com>
References: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
 <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>
 <CAKysZ8zAPRob+NPaf_b0yJEXTzN8ntDbY-wV1aAni7xx8jbg6A@mail.gmail.com>
Message-ID: <1057164e-9425-2ce9-c80c-80b6c6b583c4@oracle.com>

Hi Vyom,

On 24/05/2019 14:36, Vyom Tiwari wrote:
> Hi Daniel,
> Overall changes looks good to me, please update the copy write date that 
> you missed in couple of files.

Which files did I miss?

> In "TestHttpServer.java"? we are printing 
> error message on System.err and throwing the RuntimeException both as 
> below, do you think we need both ?
> 
>   System.err.println ("Server could not start: " + e);
> + throw new RuntimeException("Server could not start: " + e, e);

Yes - if we don't throw the test will fail in timeout instead.
I prefer to fail fast. The exception might be swallowed if the
server is started in an executor thread though - so let's keep
both.

best regards.

-- daniel

> 
> Thanks,
> Vyom
> 
> On Fri, May 24, 2019 at 6:33 PM Chris Hegarty <chris.hegarty at oracle.com 
> <mailto:chris.hegarty at oracle.com>> wrote:
> 
> 
>     On 22/05/2019 18:35, Daniel Fuchs wrote:
>      > Hi,
>      >
>      > Please find below a patch for the next batch of tests
>      > that have been observed failing intermittently.
>      >
>      > JBS: https://bugs.openjdk.java.net/browse/JDK-8224603
>      >
>      > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8224603/webrev.00/
> 
>     Looks ok to me Daniel.
> 
>     -Chris.
> 
> 
> 
> -- 
> Thanks,
> Vyom


From vyommani at gmail.com  Fri May 24 14:37:46 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 24 May 2019 20:07:46 +0530
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
In-Reply-To: <1057164e-9425-2ce9-c80c-80b6c6b583c4@oracle.com>
References: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
 <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>
 <CAKysZ8zAPRob+NPaf_b0yJEXTzN8ntDbY-wV1aAni7xx8jbg6A@mail.gmail.com>
 <1057164e-9425-2ce9-c80c-80b6c6b583c4@oracle.com>
Message-ID: <CAKysZ8zpTZnYKZj6tfNpSA1-aYN49UoPgn-PdumpycRwZFrnTQ@mail.gmail.com>

Hi Daniel,

SocksProxyVersion.java is one of them my local repo it is showing
(Copyright (c) 2011, 2015, Oracle and/or its). I was talking do we need
both(printing message on System.err & throwing exception), as you already
explain throwing exception is required but do we need  same error
message ("Server
could not start:") on System.err as well ?
Thanks,
Vyom

On Fri, May 24, 2019 at 7:32 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Vyom,
>
> On 24/05/2019 14:36, Vyom Tiwari wrote:
> > Hi Daniel,
> > Overall changes looks good to me, please update the copy write date that
> > you missed in couple of files.
>
> Which files did I miss?
>
> > In "TestHttpServer.java"  we are printing
> > error message on System.err and throwing the RuntimeException both as
> > below, do you think we need both ?
> >
> >   System.err.println ("Server could not start: " + e);
> > + throw new RuntimeException("Server could not start: " + e, e);
>
> Yes - if we don't throw the test will fail in timeout instead.
> I prefer to fail fast. The exception might be swallowed if the
> server is started in an executor thread though - so let's keep
> both.
>
> best regards.
>
> -- daniel
>
> >
> > Thanks,
> > Vyom
> >
> > On Fri, May 24, 2019 at 6:33 PM Chris Hegarty <chris.hegarty at oracle.com
> > <mailto:chris.hegarty at oracle.com>> wrote:
> >
> >
> >     On 22/05/2019 18:35, Daniel Fuchs wrote:
> >      > Hi,
> >      >
> >      > Please find below a patch for the next batch of tests
> >      > that have been observed failing intermittently.
> >      >
> >      > JBS: https://bugs.openjdk.java.net/browse/JDK-8224603
> >      >
> >      > webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224603/webrev.00/
> >
> >     Looks ok to me Daniel.
> >
> >     -Chris.
> >
> >
> >
> > --
> > Thanks,
> > Vyom
>
>

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

From daniel.fuchs at oracle.com  Fri May 24 15:19:29 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 May 2019 16:19:29 +0100
Subject: [teststabilization] RFR: 8224603: Replace wildcard address with
 loopback or local host in tests - part 11
In-Reply-To: <CAKysZ8zpTZnYKZj6tfNpSA1-aYN49UoPgn-PdumpycRwZFrnTQ@mail.gmail.com>
References: <1642c11a-aa1d-716f-ed03-99344a0d0e69@oracle.com>
 <8f919d20-ff16-8e68-0c20-929a95b6518d@oracle.com>
 <CAKysZ8zAPRob+NPaf_b0yJEXTzN8ntDbY-wV1aAni7xx8jbg6A@mail.gmail.com>
 <1057164e-9425-2ce9-c80c-80b6c6b583c4@oracle.com>
 <CAKysZ8zpTZnYKZj6tfNpSA1-aYN49UoPgn-PdumpycRwZFrnTQ@mail.gmail.com>
Message-ID: <69dc20a0-f071-1d24-6434-1d19355c841e@oracle.com>

Hi Vyom,

On 24/05/2019 15:37, Vyom Tiwari wrote:
> Hi Daniel,
> 
> SocksProxyVersion.java is one of them my local repo it is showing 
> (Copyright (c) 2011, 2015, Oracle and/or its).

No, that one is correct. But BadProxySelector.java was missing it.
Thanks for catching that.

> I was talking do we need 
> both(printing message on System.err & throwing exception), as you 
> already explain throwing exception is required but do we need? same 
> error message ("Server could not start:") on System.err as well ?

      The exception might be swallowed if the
      server is started in an executor thread though - so let's keep
      both.

I have pushed the changes.
If you see anything else it can go in the next batch :-)

best regards,

-- daniel

From daniel.fuchs at oracle.com  Fri May 24 18:35:49 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 May 2019 19:35:49 +0100
Subject: [teststabilization] RFR: 8224761: Replace wildcard address with
 loopback or local host in tests - part 12
Message-ID: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>

Hi,

Please find a patch that fixes a batch of tests that have been
observed to fail intermittently. Usual symptoms, usual probable
cause, and usual recipe:

8224761: Replace wildcard address with loopback or local host in
          tests - part 12
https://bugs.openjdk.java.net/browse/JDK-8224761

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

Note: I also took the opportunity to add a doPriveleged in the
NetworkConfiguration library class. If the code in question
doesn't have the appropriate permissions it prints truncated
info, which makes it otherwise unhelpful in tests that define
a security manager on the command line.

best regards,

-- daniel

From sean.mullan at oracle.com  Fri May 24 20:56:12 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 24 May 2019 16:56:12 -0400
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <CAPW48spwaQ_YBgyY4qd9+vpWav2ovLGT+gfE=EpxwV2EADAMmg@mail.gmail.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
 <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
 <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>
 <CAPW48spwaQ_YBgyY4qd9+vpWav2ovLGT+gfE=EpxwV2EADAMmg@mail.gmail.com>
Message-ID: <b4a056ea-d24f-c578-12be-15dd22d4aa14@oracle.com>

On 5/23/19 8:14 PM, Arthur Eubanks wrote:
> Ping on a review from security-dev.
> 
> On Fri, May 17, 2019 at 9:53 AM Chris Hegarty <chris.hegarty at oracle.com 
> <mailto:chris.hegarty at oracle.com>> wrote:
> 
>     Arthur,
> 
>>     On 17 May 2019, at 17:50, Arthur Eubanks <aeubanks at google.com
>>     <mailto:aeubanks at google.com>> wrote:
>>
>>         Looks good.
>>
>>         Trivially, maybe amend the comment to be more explicit
>>
>>         ? ?86? ? ? ?// SOCKS V4 ( requires IPv4 )
>>
>>         -Chris.
>>
>>     Done
>>     http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/
>>
>>     I will wait for another review from security-dev.
> 
>     You have my Review ( conditional on a Reviewer for the test in the
>     security area ).

It seems ok but given that this area is a bit unpredictable I would 
recommend you be available/online to monitor CI results after you push 
the fix in case something breaks.

--Sean

From aeubanks at google.com  Fri May 24 20:57:44 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 24 May 2019 13:57:44 -0700
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <b4a056ea-d24f-c578-12be-15dd22d4aa14@oracle.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
 <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
 <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>
 <CAPW48spwaQ_YBgyY4qd9+vpWav2ovLGT+gfE=EpxwV2EADAMmg@mail.gmail.com>
 <b4a056ea-d24f-c578-12be-15dd22d4aa14@oracle.com>
Message-ID: <CAPW48srmev0EAS6K7Choh6_GOh2D=sYRyKniQGCfO4X5ZyY8_w@mail.gmail.com>

On Fri, May 24, 2019 at 1:56 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> On 5/23/19 8:14 PM, Arthur Eubanks wrote:
> > Ping on a review from security-dev.
> >
> > On Fri, May 17, 2019 at 9:53 AM Chris Hegarty <chris.hegarty at oracle.com
> > <mailto:chris.hegarty at oracle.com>> wrote:
> >
> >     Arthur,
> >
> >>     On 17 May 2019, at 17:50, Arthur Eubanks <aeubanks at google.com
> >>     <mailto:aeubanks at google.com>> wrote:
> >>
> >>         Looks good.
> >>
> >>         Trivially, maybe amend the comment to be more explicit
> >>
> >>            86       // SOCKS V4 ( requires IPv4 )
> >>
> >>         -Chris.
> >>
> >>     Done
> >>     http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/
> >>
> >>     I will wait for another review from security-dev.
> >
> >     You have my Review ( conditional on a Reviewer for the test in the
> >     security area ).
>
> It seems ok but given that this area is a bit unpredictable I would
> recommend you be available/online to monitor CI results after you push
> the fix in case something breaks.
>
I will submit next week then. Thanks for the review.

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

From sean.mullan at oracle.com  Fri May 24 20:58:11 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 24 May 2019 16:58:11 -0400
Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6
In-Reply-To: <b4a056ea-d24f-c578-12be-15dd22d4aa14@oracle.com>
References: <CAPW48sqqf58b7GgokobZ8q1qgYeteejy78OseQByhpA9Z16vhA@mail.gmail.com>
 <CAKysZ8z9pWXXoEwOYUvkhsox7-jNPyD5+f3Kd8Orkgp2YSmL-w@mail.gmail.com>
 <CAPW48srpMCnDinC5L+g0r9myT16HyDoHg3Bj6OHZ3mBDBF339w@mail.gmail.com>
 <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com>
 <CAPW48sqGrsCm7jGT73vMRSorH41MTrCv5=rUfSEajbBNAgMK7w@mail.gmail.com>
 <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com>
 <CAPW48spwaQ_YBgyY4qd9+vpWav2ovLGT+gfE=EpxwV2EADAMmg@mail.gmail.com>
 <b4a056ea-d24f-c578-12be-15dd22d4aa14@oracle.com>
Message-ID: <4cb52762-5d4c-dfb0-fc60-ecf88cdca0b0@oracle.com>

On 5/24/19 4:56 PM, Sean Mullan wrote:
> On 5/23/19 8:14 PM, Arthur Eubanks wrote:
>> Ping on a review from security-dev.
>>
>> On Fri, May 17, 2019 at 9:53 AM Chris Hegarty 
>> <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
>>
>> ??? Arthur,
>>
>>> ??? On 17 May 2019, at 17:50, Arthur Eubanks <aeubanks at google.com
>>> ??? <mailto:aeubanks at google.com>> wrote:
>>>
>>> ??????? Looks good.
>>>
>>> ??????? Trivially, maybe amend the comment to be more explicit
>>>
>>> ??????? ? ?86? ? ? ?// SOCKS V4 ( requires IPv4 )
>>>
>>> ??????? -Chris.
>>>
>>> ??? Done
>>> ??? http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/
>>>
>>> ??? I will wait for another review from security-dev.
>>
>> ??? You have my Review ( conditional on a Reviewer for the test in the
>> ??? security area ).
> 
> It seems ok but given that this area is a bit unpredictable I would 
> recommend you be available/online to monitor CI results after you push 
> the fix in case something breaks.

I should add that I would recommend not pushing this until Tuesday 
after the US Memorial Day weekend as many folks probably won't be online.

--Sean

From Alan.Bateman at oracle.com  Sun May 26 18:34:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 May 2019 19:34:03 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <f10dd14b-dd36-ecbe-5b09-fc64fee34527@oracle.com>

On 23/05/2019 18:19, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
>
> Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails 
> with NoSuchElementException on Solaris.
>
> java.util.NoSuchElementException
> at java.base/java.util.Spliterators$1Adapter.next(Spliterators.java:688)
> at BasicMulticastTests.main(BasicMulticastTests.java:221)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) 
>
> at java.base/java.lang.Thread.run(Thread.java:830)
>
> This changes the test to check if any multicast interfaces are 
> available for IPv4/IPv6 before testing one. This does have the effect 
> of not failing if no multicast interfaces available, which may or may 
> not be desirable.
Adding nio-dev as this is a DatagramChannel test.

Might be a bit more readable if you rename "multicasts" to 
"multicastInterfaces" but otherwise looks okay to me.

-Alan.


From vtewar26 at in.ibm.com  Mon May 27 09:32:06 2019
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Mon, 27 May 2019 09:32:06 +0000
Subject: [teststabilization] RFR: 8224761: Replace wildcard address with
 loopback or local host in tests - part 12
In-Reply-To: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>
References: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>
Message-ID: <OF6C3F9C58.04E3681C-ON00258407.003383AE-00258407.003460DC@notes.na.collabserv.com>

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

From daniel.fuchs at oracle.com  Mon May 27 09:49:39 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 May 2019 10:49:39 +0100
Subject: [teststabilization] RFR: 8224761: Replace wildcard address with
 loopback or local host in tests - part 12
In-Reply-To: <OF6C3F9C58.04E3681C-ON00258407.003383AE-00258407.003460DC@notes.na.collabserv.com>
References: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>
 <OF6C3F9C58.04E3681C-ON00258407.003383AE-00258407.003460DC@notes.na.collabserv.com>
Message-ID: <27dc4af5-34cd-f07f-9ba2-4f8289bc5060@oracle.com>

Thanks Vyom,

On 27/05/2019 10:32, Vyom Tewari26 wrote:
> Overall changes looks good to me, in "B6726695.java" you have used 
> ".loopback()" which is not consistent with the other similar URL 
> construction changes although i can see that "ProxyTest.java" uses 
> ".loopback()" as well.

Yes consistency is not that important here.
Sometimes you have the server/server socket address available
and can use that. Sometimes it's not directly available
unless you modify the test to pass it - in which case
using loopback() when you know that the server is
bound to the loopback is also acceptable.

best regards,

-- daniel

From chris.hegarty at oracle.com  Mon May 27 10:48:28 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 May 2019 11:48:28 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
Message-ID: <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>


On 24/05/2019 08:28, Alan Bateman wrote:
> On 23/05/2019 17:32, Chris Hegarty wrote:
>> ...

This next iteration addresses all of Alan's comments and suggestions.

Additionally, while here we can take the opportunity to cleanup the spec
inconsistencies of the getOption/setOption methods across the socket
impls. The current default implementation is also problematic,
undocumented and unspecified. It is highly questionable for code to
depend on it. The default implementation can be simplified, specified,
and a note advising subclasses to override added. ( The CSR contains
specifics, that I won't duplicate here )

Updated webrev:
   https://cr.openjdk.java.net/~chegar/8224477/webrev.03/

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

-Chris.

From pavel.rappo at oracle.com  Mon May 27 10:50:49 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 27 May 2019 11:50:49 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <4352EE27-1098-4583-B069-40DB4E06515A@oracle.com>

I ran that changed test on Solaris many times. Those runs included some of the
machines on which the previous incarnation failed. The runs were successful.
Other platforms looked fine too.

Looks good.

> On 23 May 2019, at 18:19, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
> 
> Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException on Solaris.
> 
> java.util.NoSuchElementException 
> at java.base/java.util.Spliterators$1Adapter.next(Spliterators.java:688) 
> at BasicMulticastTests.main(BasicMulticastTests.java:221) 
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
> at java.base/java.lang.reflect.Method.invoke(Method.java:567) 
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) 
> at java.base/java.lang.Thread.run(Thread.java:830)
> 
> This changes the test to check if any multicast interfaces are available for IPv4/IPv6 before testing one. This does have the effect of not failing if no multicast interfaces available, which may or may not be desirable.


From daniel.fuchs at oracle.com  Mon May 27 10:58:37 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 May 2019 11:58:37 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <1f34b96d-e681-4a24-8344-4370c41b7606@oracle.com>

On 23/05/2019 18:19, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/


Hi Arthur,

I would suggest three things:

1. replace `if (....hasNext()) {` with `while (....hasNext()) {`
2. add a counter, and increment it at the end of the `while` block
    to count how many interfaces where successfully tested
3. In the end, just before exiting main, check the value of
    the counter with something like:


```
         if (count == 1) {
             System.out.println("Tested only " + count
                            + " multicast interface");
         } else if (count > 1) {
             System.out.println("Tested " + count
                            + " multicast interfaces");
         } else {
             NetworkConfiguration.printSystemConfiguration(System.err);
             throw new SkippedException(
                       "No multicast interfaces found!");
         }
```

best regards,

-- daniel

From daniel.fuchs at oracle.com  Mon May 27 11:02:56 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 May 2019 12:02:56 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>

[adding nio-dev]

On 23/05/2019 18:19, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/


Hi Arthur,

I would suggest three things:

1. replace `if (....hasNext()) {` with `while (....hasNext()) {`
2. add a counter, and increment it at the end of the `while` block
    to count how many interfaces where successfully tested
3. In the end, just before exiting main, check the value of
    the counter with something like:


```
         if (count == 1) {
             System.out.println("Tested only " + count
                            + " multicast interface");
         } else if (count > 1) {
             System.out.println("Tested " + count
                            + " multicast interfaces");
         } else {
             NetworkConfiguration.printSystemConfiguration(System.err);
             throw new SkippedException(
                       "No multicast interfaces found!");
         }
```

best regards,

-- daniel

From Alan.Bateman at oracle.com  Mon May 27 11:50:51 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 May 2019 12:50:51 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
 <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
Message-ID: <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>

On 27/05/2019 11:48, Chris Hegarty wrote:
>
> This next iteration addresses all of Alan's comments and suggestions.
>
> Additionally, while here we can take the opportunity to cleanup the spec
> inconsistencies of the getOption/setOption methods across the socket
> impls. The current default implementation is also problematic,
> undocumented and unspecified. It is highly questionable for code to
> depend on it. The default implementation can be simplified, specified,
> and a note advising subclasses to override added. ( The CSR contains
> specifics, that I won't duplicate here )
>
> Updated webrev:
> ? https://cr.openjdk.java.net/~chegar/8224477/webrev.03/
>
> CSR:
> ? https://bugs.openjdk.java.net/browse/JDK-8224792
This looks a good cleanup. There may be an argument to have the default 
implementations of get/setOption throw NPE when name is null.

Does isServer need to be package-private? I didn't spot any usages in 
PSI/PDSI.

For SocketChannelImpl/ServerSocketChannelImp then I'd prefer to use the 
same check that we have in the new NioSocketImpl to test that the value 
type matches the SocketOption::type. We can do the same check in 
DatagramChannelImpl.setOption.

The tests looks good. A suggestion for the TestImplSpec methods is to 
rename them to something like TestDefaultBehavior as I think that is 
better describes what they test.

-Alan


From chris.hegarty at oracle.com  Mon May 27 15:18:18 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 May 2019 16:18:18 +0100
Subject: [teststabilization] RFR: 8224761: Replace wildcard address with
 loopback or local host in tests - part 12
In-Reply-To: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>
References: <dc0e3421-0a84-748a-fa5c-5a99d972a12f@oracle.com>
Message-ID: <9bc2a6cb-da78-fe99-9d0c-7233eabca387@oracle.com>



On 24/05/2019 19:35, Daniel Fuchs wrote:
> Hi,
> 
> Please find a patch that fixes a batch of tests that have been
> observed to fail intermittently. Usual symptoms, usual probable
> cause, and usual recipe:
> 
> 8224761: Replace wildcard address with loopback or local host in
>  ???????? tests - part 12
> https://bugs.openjdk.java.net/browse/JDK-8224761
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224761/webrev.00/

Looks good. Thanks Daniel.

-Chris.


From chris.hegarty at oracle.com  Mon May 27 15:48:11 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 May 2019 16:48:11 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
 <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
 <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>
Message-ID: <519c2ebe-80b3-1e97-2a5b-33f72261af0a@oracle.com>

Alan,

On 27/05/2019 12:50, Alan Bateman wrote:
> ..
> This looks a good cleanup. There may be an argument to have the default 
> implementations of get/setOption throw NPE when name is null.

Good point. Done.

> Does isServer need to be package-private? I didn't spot any usages in 
> PSI/PDSI.

Not yet. It is still used by the unix PlatformSocketImpl, when
creating new instances. A future cleanup opportunity, possibly.

> For SocketChannelImpl/ServerSocketChannelImp then I'd prefer to use the 
> same check that we have in the new NioSocketImpl to test that the value 
> type matches the SocketOption::type. We can do the same check in 
> DatagramChannelImpl.setOption.

Yes. Done.

> The tests looks good. A suggestion for the TestImplSpec methods is to 
> rename them to something like TestDefaultBehavior as I think that is 
> better describes what they test.

Done.

Updated webrev:
   https://cr.openjdk.java.net/~chegar/8224477/webrev.04/

-Chris

From Alan.Bateman at oracle.com  Mon May 27 16:11:38 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 May 2019 17:11:38 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <519c2ebe-80b3-1e97-2a5b-33f72261af0a@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
 <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
 <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>
 <519c2ebe-80b3-1e97-2a5b-33f72261af0a@oracle.com>
Message-ID: <da2b1aa3-84af-1b1b-9f8c-fdadf8fdf96b@oracle.com>

On 27/05/2019 16:48, Chris Hegarty wrote:
>
>
> Updated webrev:
> ? https://cr.openjdk.java.net/~chegar/8224477/webrev.04/
This version looks good.

A minor nit is that there's a blank line added to 
SocketChannelImpl.setOption that separates a comment from the code that 
it documents, I assume this is left over from previous iteration when 
there was a null check in the SO_REUSEADDR handling.

Also the two TestDefaultBehavior tests both name the test impl 
"DelegatingSocketImpl" but it doesn't really delegate, they are really 
no-op impls.

On the CSR. The Problem section suggests that supportedOptions returned 
a set of options that are reasonable for a ServerSocket. I assume this 
should be client Socket as most of the options were not interesting for 
a ServerSocket.

-Alan





From chris.hegarty at oracle.com  Mon May 27 18:37:33 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 27 May 2019 19:37:33 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <da2b1aa3-84af-1b1b-9f8c-fdadf8fdf96b@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
 <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
 <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>
 <519c2ebe-80b3-1e97-2a5b-33f72261af0a@oracle.com>
 <da2b1aa3-84af-1b1b-9f8c-fdadf8fdf96b@oracle.com>
Message-ID: <EA8FC98A-3582-4A80-A3F6-0972D93B37C3@oracle.com>

Alan,

> On 27 May 2019, at 17:11, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 27/05/2019 16:48, Chris Hegarty wrote:
>> 
>> 
>> Updated webrev:
>>   https://cr.openjdk.java.net/~chegar/8224477/webrev.04/
> This version looks good.
> 
> A minor nit is that there's a blank line added to SocketChannelImpl.setOption that separates a comment from the code that it documents, I assume this is left over from previous iteration when there was a null check in the SO_REUSEADDR handling.
> 
> Also the two TestDefaultBehavior tests both name the test impl "DelegatingSocketImpl" but it doesn't really delegate, they are really no-op impls.

Thanks, both issues resolved in-place.

> On the CSR. The Problem section suggests that supportedOptions returned a set of options that are reasonable for a ServerSocket. I assume this should be client Socket as most of the options were not interesting for a ServerSocket.

ServerSocket options are mentioned here as that is the behaviour in 
the current shipping release ( to return the server related options ), not
the client related ones, see
  http://hg.openjdk.java.net/jdk/jdk/file/jdk-12-ga/src/java.base/share/classes/java/net/SocketImpl.java#l472

-Chris.


From Alan.Bateman at oracle.com  Mon May 27 18:42:51 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 May 2019 19:42:51 +0100
Subject: RFR 8224477 [13] java.net.Socket::setOption - implementation
 mismatch to spec
In-Reply-To: <EA8FC98A-3582-4A80-A3F6-0972D93B37C3@oracle.com>
References: <687837FE-3D30-4615-B13A-923DC3BD2C94@oracle.com>
 <2b2a45a6-2cad-2fc1-8cc2-1d3c8f8cfe2c@oracle.com>
 <06969BC9-9F46-4F7D-8434-DE72CE9657D7@oracle.com>
 <0e30ff2c-acc2-c651-c12a-ec8a154ec743@oracle.com>
 <94485F0E-3FBD-4008-9D01-954CD2B7C0DB@oracle.com>
 <f33bf4e7-e1f5-c1bb-56b1-d68802c9ba3a@oracle.com>
 <f79a7574-c3ae-aa86-bf41-1402503ceb62@oracle.com>
 <7cb44023-c6e7-2cda-ba81-c15561eca2b2@oracle.com>
 <519c2ebe-80b3-1e97-2a5b-33f72261af0a@oracle.com>
 <da2b1aa3-84af-1b1b-9f8c-fdadf8fdf96b@oracle.com>
 <EA8FC98A-3582-4A80-A3F6-0972D93B37C3@oracle.com>
Message-ID: <8ed9d7e1-6760-2f99-d765-b333954763ba@oracle.com>



On 27/05/2019 19:37, Chris Hegarty wrote:
> :
> Thanks, both issues resolved in-place.
Looks good.

> :
> ServerSocket options are mentioned here as that is the behaviour in
> the current shipping release ( to return the server related options ), not
> the client related ones, see
>    http://hg.openjdk.java.net/jdk/jdk/file/jdk-12-ga/src/java.base/share/classes/java/net/SocketImpl.java#l472
>
>
Ah okay, a custom SocketImpl has no support in the SPI to know if it's 
for a client or server socket. In that case, I think it looks fine (and 
more reason to return the empty Set as nothing else make sense).

-Alan

From chris.hegarty at oracle.com  Tue May 28 14:39:26 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 28 May 2019 15:39:26 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect 
Message-ID: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>

Please review this small change to ServerSocket::toString so that it
correctly implements its specified behaviour ( to reveal the local
address if SecurityManager::checkConnect succeeds ). Looks like this was
a minor oversight in the implementation that was not caught by testing,
as there was no fine grained test for it. This review contains a
comprehensive test.

Additionally, the ServerSocket::toString specification would benefit
from a minor clarification that checkConnect is only invoked when the
socket is bound. ( A CSR will be filed for this )

https://cr.openjdk.java.net/~chegar/8224730/webrev.00/

-Chris.

From arno.zeller at sap.com  Tue May 28 15:10:14 2019
From: arno.zeller at sap.com (Zeller, Arno)
Date: Tue, 28 May 2019 15:10:14 +0000
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java failed
 with java.net.BindException: Address already in use: Cannot bind
Message-ID: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>

Hi,

I took a look at JDK-8194231 and would like to propose the following fix for the issue.

The problem seems that the test uses fixed port 5050 for testing that is also used by newer Windows versions (Windows 10/Window Server 2016 and newer).
Therefore the test will always fail when run on a newer Windows machine. To avoid such problems in the future I changed the three sub tests that use a fixed port to use a generic port instead.

Bug:
8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind
https://bugs.openjdk.java.net/browse/JDK-8194231

Webrev:
http://cr.openjdk.java.net/~azeller/webrevs/8194231/

Best regards,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190528/60de3733/attachment.html>

From chris.hegarty at oracle.com  Tue May 28 15:20:40 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 28 May 2019 16:20:40 +0100
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java
 failed with java.net.BindException: Address already in use: Cannot bind
In-Reply-To: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
References: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
Message-ID: <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>

Arno,

> On 28 May 2019, at 16:10, Zeller, Arno <arno.zeller at sap.com> wrote:
> 
> Hi,
>  
> I took a look at JDK-8194231 and would like to propose the following fix for the issue.
> 
> The problem seems that the test uses fixed port 5050 for testing that is also used by newer Windows versions (Windows 10/Window Server 2016 and newer).
> Therefore the test will always fail when run on a newer Windows machine. To avoid such problems in the future I changed the three sub tests that use a fixed port to use a generic port instead.
>  
> Bug:
> 8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind
> https://bugs.openjdk.java.net/browse/JDK-8194231
>  
> Webrev:
> http://cr.openjdk.java.net/~azeller/webrevs/8194231/

I think this is good.

I would like to run it through our internal build and test infra, after which
I?ll post the results here.

Trivially, a space is needed after the coma in the copyright header. ?2016, 2019, "

+/* Copyright (c) 2016,2019, Oracle and/or its affiliates. All rights reserved.

-Chris.

From aeubanks at google.com  Tue May 28 17:27:07 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 28 May 2019 10:27:07 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
Message-ID: <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>

>
> Might be a bit more readable if you rename "multicasts" to
> "multicastInterfaces" but otherwise looks okay to me.

Done.


> Hi Arthur,
>
> I would suggest three things:
>
> 1. replace `if (....hasNext()) {` with `while (....hasNext()) {`
> 2. add a counter, and increment it at the end of the `while` block
>     to count how many interfaces where successfully tested
> 3. In the end, just before exiting main, check the value of
>     the counter with something like:
>
>
> ```
>          if (count == 1) {
>              System.out.println("Tested only " + count
>                             + " multicast interface");
>          } else if (count > 1) {
>              System.out.println("Tested " + count
>                             + " multicast interfaces");
>          } else {
>              NetworkConfiguration.printSystemConfiguration(System.err);
>              throw new SkippedException(
>                        "No multicast interfaces found!");
>          }
> ```
>
> best regards,
>
> -- daniel
>
Done.

new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190528/a906bd57/attachment.html>

From arno.zeller at sap.com  Tue May 28 18:51:39 2019
From: arno.zeller at sap.com (Zeller, Arno)
Date: Tue, 28 May 2019 18:51:39 +0000
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java
 failed with java.net.BindException: Address already in use: Cannot bind
In-Reply-To: <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
References: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
 <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
Message-ID: <VE1PR02MB56778144EE029C98A6CEDF86E31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>

Hi Chris,

thanks for having a look and running tests in your infrastructure. 

I updated the webrev in place with the missing whitespace in the copyright header. I hope this is ok!

Best regards,
Arno

-----Original Message-----
From: Chris Hegarty <chris.hegarty at oracle.com> 
Sent: Dienstag, 28. Mai 2019 17:21
To: Zeller, Arno <arno.zeller at sap.com>
Cc: net-dev at openjdk.java.net
Subject: Re: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind

Arno,

> On 28 May 2019, at 16:10, Zeller, Arno <arno.zeller at sap.com> wrote:
> 
> Hi,
>  
> I took a look at JDK-8194231 and would like to propose the following fix for the issue.
> 
> The problem seems that the test uses fixed port 5050 for testing that is also used by newer Windows versions (Windows 10/Window Server 2016 and newer).
> Therefore the test will always fail when run on a newer Windows machine. To avoid such problems in the future I changed the three sub tests that use a fixed port to use a generic port instead.
>  
> Bug:
> 8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind
> https://bugs.openjdk.java.net/browse/JDK-8194231
>  
> Webrev:
> http://cr.openjdk.java.net/~azeller/webrevs/8194231/

I think this is good.

I would like to run it through our internal build and test infra, after which
I?ll post the results here.

Trivially, a space is needed after the coma in the copyright header. ?2016, 2019, "

+/* Copyright (c) 2016,2019, Oracle and/or its affiliates. All rights reserved.

-Chris.

From Alan.Bateman at oracle.com  Wed May 29 06:29:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 07:29:53 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
Message-ID: <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>

On 28/05/2019 18:27, Arthur Eubanks wrote:
> :
>
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.01/
The purpose of L237-244 isn't clear. Maybe it's useful to print the 
count of interfaces supporting multicast but it is necessary to throw 
SkipException when the count is 0? For debugging purposes I think it 
would be much prefer if the value of nif were printed before it runs the 
test on the interface. I think that would eliminate the need for the count.

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

From Alan.Bateman at oracle.com  Wed May 29 07:01:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 08:01:26 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect
In-Reply-To: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
References: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
Message-ID: <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>

On 28/05/2019 15:39, Chris Hegarty wrote:
> Please review this small change to ServerSocket::toString so that it
> correctly implements its specified behaviour ( to reveal the local
> address if SecurityManager::checkConnect succeeds ). Looks like this was
> a minor oversight in the implementation that was not caught by testing,
> as there was no fine grained test for it. This review contains a
> comprehensive test.
>
> Additionally, the ServerSocket::toString specification would benefit
> from a minor clarification that checkConnect is only invoked when the
> socket is bound. ( A CSR will be filed for this )
>
> https://cr.openjdk.java.net/~chegar/8224730/webrev.00/
This looks good. I just wonder if there is any merit is extending the 
test to exercise the socket adaptors returned by 
SocketChannel::socketand ServerSocketChannel::socket or maybe checking a 
separate test. The socket adaptors are often forgotten and I'm only 
bringing it up here while the issue with toString is fresh.

-Alan


From daniel.fuchs at oracle.com  Wed May 29 07:08:47 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 08:08:47 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
Message-ID: <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>

Hi Alan,

On 29/05/2019 07:29, Alan Bateman wrote:
> The purpose of L237-244 isn't clear. Maybe it's useful to print the 
> count of interfaces supporting multicast but it is necessary to throw 
> SkipException when the count is 0? For debugging purposes I think it 
> would be much prefer if the value of nif were printed before it runs the 
> test on the interface. I think that would eliminate the need for the count.

The idea is that if a test machine has no IPv4 and no
IPv6 multicast interfaces then it's probably misconfigured.

Also if a regression is introduced that causes this to happen,
then we'd probably want to see it.

AFAIK the SkippedException is a good match for that.

best regard,

-- daniel

From Alan.Bateman at oracle.com  Wed May 29 07:23:24 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 08:23:24 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
Message-ID: <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>

On 29/05/2019 08:08, Daniel Fuchs wrote:
>
> The idea is that if a test machine has no IPv4 and no
> IPv6 multicast interfaces then it's probably misconfigured.
>
> Also if a regression is introduced that causes this to happen,
> then we'd probably want to see it.
>
> AFAIK the SkippedException is a good match for that.
>
I don't like the dependency on jtreg.SkippedException but if you find it 
useful then okay. I assume we can remove the other messages added at the 
end as they are less useful than printing the value of each network 
interface before testing it.

-Alan

From daniel.fuchs at oracle.com  Wed May 29 07:28:15 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 08:28:15 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
Message-ID: <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>

On 29/05/2019 08:23, Alan Bateman wrote:
>> AFAIK the SkippedException is a good match for that.
>>
> I don't like the dependency on jtreg.SkippedException but if you find it 
> useful then okay.

Would you prefer to throw AssertionError instead? It's also
a possibility. Chris thought it might be "too strong".

> I assume we can remove the other messages added at the 
> end as they are less useful than printing the value of each network 
> interface before testing it.

Right - printing interfaces before testing them would be useful.
But printing all interfaces if no multicast was found is useful
too - it might help figure out why the test was not run.

best regards,

-- daniel


From Alan.Bateman at oracle.com  Wed May 29 07:40:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 08:40:02 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
Message-ID: <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>

On 29/05/2019 08:28, Daniel Fuchs wrote:
>
> Would you prefer to throw AssertionError instead? It's also
> a possibility. Chris thought it might be "too strong".
It might be odd to have a test system configured without multicast 
enabled but it's not wrong. So I think the test should pass.

> :
>
> Right - printing interfaces before testing them would be useful.
> But printing all interfaces if no multicast was found is useful
> too - it might help figure out why the test was not run.
>
I think it would be useful for tests such as this one to print the 
network interface configuration at the start. That might be something 
for a supporting method in jdk.test.lib.NetworkConfiguration (if there 
isn't anything already).

-Alan

From chris.hegarty at oracle.com  Wed May 29 08:19:02 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 29 May 2019 09:19:02 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
Message-ID: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>


> On 29 May 2019, at 08:40, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/05/2019 08:28, Daniel Fuchs wrote:
>> 
>> Would you prefer to throw AssertionError instead? It's also
>> a possibility. Chris thought it might be "too strong".
> It might be odd to have a test system configured without multicast enabled but it's not wrong. So I think the test should pass.

Right, that was my thought too.

It is useful to be able to scan a collection of jtr files and
differentiate between a test that did nothing ( and passed silently )
from a test that actually did do something. Using SkippedException will
make this task a little easier - which could then be used to identify
possibly misconfigured systems.

The test already has a test library dependency, so the addition of 
SkippedException does not introduce any new significant burden
for standalone testing.

>> :
>> 
>> Right - printing interfaces before testing them would be useful.
>> But printing all interfaces if no multicast was found is useful
>> too - it might help figure out why the test was not run.
>> 
> I think it would be useful for tests such as this one to print the network interface configuration at the start. That might be something for a supporting method in jdk.test.lib.NetworkConfiguration (if there isn't anything already).

This already exists.
NetworkConfiguration.printSystemConfiguration(PrintStream)

I think there needs to be a balance between readability and
diagnosability. It's often the case that much debugging statements are
added to a test when investigating a failure. It's good to have some
breadcrumbs to follow when things go wrong, but it should not complicate
the code too much.

It might be useful to just unconditionally printSystemConfiguration, at
the start of the test, and then the nic in use for each iteration. I 
don't think anything more is needed.

-Chris.



From christoph.langer at sap.com  Wed May 29 08:28:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 29 May 2019 08:28:19 +0000
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java
 failed with java.net.BindException: Address already in use: Cannot bind
In-Reply-To: <VE1PR02MB56778144EE029C98A6CEDF86E31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
References: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
 <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
 <VE1PR02MB56778144EE029C98A6CEDF86E31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192CD1BC7FE944874A1B3608A1F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

Thanks, Arno. This looks good to me, too.

@Chris: We were running with this patch in our nightly test system for a while now and we don't see regressions. But looking forward to hear from your results.

Best regards
Christoph

> -----Original Message-----
> From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Zeller,
> Arno
> Sent: Dienstag, 28. Mai 2019 20:52
> To: Chris Hegarty <chris.hegarty at oracle.com>
> Cc: net-dev at openjdk.java.net
> Subject: [CAUTION] RE: [RFR] 8194231:
> java/net/DatagramSocket/ReuseAddressTest.java failed with
> java.net.BindException: Address already in use: Cannot bind
> 
> Hi Chris,
> 
> thanks for having a look and running tests in your infrastructure.
> 
> I updated the webrev in place with the missing whitespace in the copyright
> header. I hope this is ok!
> 
> Best regards,
> Arno
> 
> -----Original Message-----
> From: Chris Hegarty <chris.hegarty at oracle.com>
> Sent: Dienstag, 28. Mai 2019 17:21
> To: Zeller, Arno <arno.zeller at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: [RFR] 8194231:
> java/net/DatagramSocket/ReuseAddressTest.java failed with
> java.net.BindException: Address already in use: Cannot bind
> 
> Arno,
> 
> > On 28 May 2019, at 16:10, Zeller, Arno <arno.zeller at sap.com> wrote:
> >
> > Hi,
> >
> > I took a look at JDK-8194231 and would like to propose the following fix for
> the issue.
> >
> > The problem seems that the test uses fixed port 5050 for testing that is also
> used by newer Windows versions (Windows 10/Window Server 2016 and
> newer).
> > Therefore the test will always fail when run on a newer Windows machine.
> To avoid such problems in the future I changed the three sub tests that use a
> fixed port to use a generic port instead.
> >
> > Bug:
> > 8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with
> java.net.BindException: Address already in use: Cannot bind
> > https://bugs.openjdk.java.net/browse/JDK-8194231
> >
> > Webrev:
> > http://cr.openjdk.java.net/~azeller/webrevs/8194231/
> 
> I think this is good.
> 
> I would like to run it through our internal build and test infra, after which
> I?ll post the results here.
> 
> Trivially, a space is needed after the coma in the copyright header. ?2016,
> 2019, "
> 
> +/* Copyright (c) 2016,2019, Oracle and/or its affiliates. All rights reserved.
> 
> -Chris.

From daniel.fuchs at oracle.com  Wed May 29 09:32:29 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 10:32:29 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
Message-ID: <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>

On 29/05/19 09:19, Chris Hegarty wrote:
> This already exists.
> NetworkConfiguration.printSystemConfiguration(PrintStream)
> 
> I think there needs to be a balance between readability and
> diagnosability. It's often the case that much debugging statements are
> added to a test when investigating a failure. It's good to have some
> breadcrumbs to follow when things go wrong, but it should not complicate
> the code too much.
> 
> It might be useful to just unconditionally printSystemConfiguration, at
> the start of the test, and then the nic in use for each iteration. I
> don't think anything more is needed.

+1

For the record I ran Arthur's webrev.01 through our test system and
got no failures (just tested BasicMulticastTests.java).

best regards,

-- daniel

From Alan.Bateman at oracle.com  Wed May 29 09:57:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 10:57:43 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
Message-ID: <0f8a1d9a-47de-5ea4-4912-9720f6231ee9@oracle.com>

On 29/05/2019 09:19, Chris Hegarty wrote:
> :
> The test already has a test library dependency, so the addition of
> SkippedException does not introduce any new significant burden
> for standalone testing.
There are a couple of tests in the nio/channels area that are useful to 
run outside of the jtreg environment when debugging on specific 
machines. BasicMulticastTests is one of those tests (on several 
occasions I've had to remove the dependent on the test libs too).

> :
>
> It might be useful to just unconditionally printSystemConfiguration, at
> the start of the test, and then the nic in use for each iteration.
That would be good. There may be a few other tests where we do the same 
(when they are next edited).

-Alan

From chris.hegarty at oracle.com  Wed May 29 11:36:59 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 29 May 2019 12:36:59 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect
In-Reply-To: <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>
References: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
 <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>
Message-ID: <8fa8bd8b-a249-953d-6ab0-800063814f3d@oracle.com>

Alan,

On 29/05/2019 08:01, Alan Bateman wrote:
> On 28/05/2019 15:39, Chris Hegarty wrote:
>> ...
>> https://cr.openjdk.java.net/~chegar/8224730/webrev.00/
> This looks good. I just wonder if there is any merit is extending the 
> test to exercise the socket adaptors returned by 
> SocketChannel::socketand ServerSocketChannel::socket or maybe checking a 
> separate test. The socket adaptors are often forgotten and I'm only 
> bringing it up here while the issue with toString is fresh.

Good idea. I've expanded the test to cover the ServerSocket adapter too.
Good news is that it found no issues ( but of course will increase
coverage and catch possible future accidental breakages ).

Webrev:
   https://cr.openjdk.java.net/~chegar/8224730/webrev.01/

CSR - to cover the minor spec clarification:
   https://bugs.openjdk.java.net/browse/JDK-8224972

-Chris.

From Alan.Bateman at oracle.com  Wed May 29 11:50:37 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 12:50:37 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect
In-Reply-To: <8fa8bd8b-a249-953d-6ab0-800063814f3d@oracle.com>
References: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
 <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>
 <8fa8bd8b-a249-953d-6ab0-800063814f3d@oracle.com>
Message-ID: <7c473c15-ee02-e293-4d4e-2612824872db@oracle.com>

On 29/05/2019 12:36, Chris Hegarty wrote:
>
> Good idea. I've expanded the test to cover the ServerSocket adapter too.
> Good news is that it found no issues ( but of course will increase
> coverage and catch possible future accidental breakages ).
>
> Webrev:
> ? https://cr.openjdk.java.net/~chegar/8224730/webrev.01/
One suggestion is to rename the socketAdapterXXX methods to 
serverSocketAdaptorXXX to align with the class name. Otherwise looks good.

>
> CSR - to cover the minor spec clarification:
> ? https://bugs.openjdk.java.net/browse/JDK-8224972
>
I've added myself as Reviewer to the CSR.

-Alan


From chris.hegarty at oracle.com  Wed May 29 13:48:27 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 29 May 2019 14:48:27 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect
In-Reply-To: <7c473c15-ee02-e293-4d4e-2612824872db@oracle.com>
References: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
 <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>
 <8fa8bd8b-a249-953d-6ab0-800063814f3d@oracle.com>
 <7c473c15-ee02-e293-4d4e-2612824872db@oracle.com>
Message-ID: <0d6cf880-4588-0cd6-a5fe-18706792c18e@oracle.com>

Alan,

On 29/05/2019 12:50, Alan Bateman wrote:
> On 29/05/2019 12:36, Chris Hegarty wrote:
>>
>> Good idea. I've expanded the test to cover the ServerSocket adapter too.
>> Good news is that it found no issues ( but of course will increase
>> coverage and catch possible future accidental breakages ).
>>
>> Webrev:
>> ? https://cr.openjdk.java.net/~chegar/8224730/webrev.01/
> One suggestion is to rename the socketAdapterXXX methods to 
> serverSocketAdaptorXXX to align with the class name. Otherwise looks good.

Yes, that is better.

Updated webrev:
   https://cr.openjdk.java.net/~chegar/8224730/webrev.02/

>>
>> CSR - to cover the minor spec clarification:
>> ? https://bugs.openjdk.java.net/browse/JDK-8224972
>>
> I've added myself as Reviewer to the CSR.

Thank you. Finalized.

-Chris.

From aeubanks at google.com  Wed May 29 16:27:45 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 29 May 2019 09:27:45 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
Message-ID: <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>

>
> For the record I ran Arthur's webrev.01 through our test system and
> got no failures (just tested BasicMulticastTests.java).
>
> best regards,
>
> -- daniel
>
Thanks.

Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
removed counting and printing the number of interfaces/throwing
SkippedException.
new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190529/bac5b470/attachment.html>

From Alan.Bateman at oracle.com  Wed May 29 19:56:20 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 20:56:20 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
 <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
Message-ID: <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>

On 29/05/2019 17:27, Arthur Eubanks wrote:
> :
>
> Moved?NetworkConfiguration.printSystemConfiguration() to the 
> beginning, removed counting and printing the number of 
> interfaces/throwing SkippedException.
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
This looks okay to me, the only thing is that the NetworkConfiguration 
is sent to System.err whereas the test proper sends its output to 
System.out. Can you check the .jtr file to see how it looks? I suspect 
it may be easier to read if you send the network configuration to 
System.out.

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

From aeubanks at google.com  Wed May 29 20:08:40 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 29 May 2019 13:08:40 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
 <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
 <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>
Message-ID: <CAPW48spnqhYqXwKhh3iUPMOr=cP-=92q+Q46PeSrKcwGczFPNQ@mail.gmail.com>

>
> Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
> removed counting and printing the number of interfaces/throwing
> SkippedException.
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
>
> This looks okay to me, the only thing is that the NetworkConfiguration is
> sent to System.err whereas the test proper sends its output to System.out.
> Can you check the .jtr file to see how it looks? I suspect it may be easier
> to read if you send the network configuration to System.out.
>
> -Alan
>
I don't think it's a big difference either way, but changed it to
System.out. Also added some extra info to the "Exception Tests" log to show
the addresses it's testing. Now it looks like:

----------System.out:(33/801)----------
*** all system network interface configuration ***
Display name: eth0
Name: eth0
InetAddress: /2620:15c:2ce:200:fb70:ba8c:5c39:dd96%eth0
InetAddress: /fe80:0:0:0:3745:855d:754c:c782%eth0
InetAddress: /100.117.216.36
Up? true
Loopback? false
PointToPoint? false
Supports multicast? true
Virtual? false
Hardware address: [112, 90, 15, 47, 36, 82]
MTU: 1500
Index: 2

Display name: lo
Name: lo
InetAddress: /0:0:0:0:0:0:0:1%lo
InetAddress: /127.0.0.1
Up? true
Loopback? true
PointToPoint? false
Supports multicast? false
Virtual? false
Hardware address: null
MTU: 65536
Index: 1

*** end ***
MembershipKey test using 225.4.5.6 @ eth0
Exception Tests using 225.4.5.6, 1.2.3.4 @ eth0
MembershipKey test using ff02:0:0:0:0:0:0:a @ eth0
Exception Tests using ff02:0:0:0:0:0:0:a, fe80:0:0:0:0:0:0:1234 @ eth0
----------System.err:(1/15)----------
STATUS:Passed.

http://cr.openjdk.java.net/~aeubanks/8224645/webrev.03
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190529/8b5161d7/attachment.html>

From Alan.Bateman at oracle.com  Wed May 29 20:15:38 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 21:15:38 +0100
Subject: RFR [13] 8224730: java.net.ServerSocket::toString not invoking
 checkConnect
In-Reply-To: <0d6cf880-4588-0cd6-a5fe-18706792c18e@oracle.com>
References: <2111CD20-992F-44CC-B197-1060BC41459B@oracle.com>
 <b295e019-0bb0-a0e9-5019-f98270bc9f4d@oracle.com>
 <8fa8bd8b-a249-953d-6ab0-800063814f3d@oracle.com>
 <7c473c15-ee02-e293-4d4e-2612824872db@oracle.com>
 <0d6cf880-4588-0cd6-a5fe-18706792c18e@oracle.com>
Message-ID: <8f341cab-d463-e475-9c8e-83bdff4cd07e@oracle.com>


On 29/05/2019 14:48, Chris Hegarty wrote:
> :
>
> On 29/05/2019 12:50, Alan Bateman wrote:
>> One suggestion is to rename the socketAdapterXXX methods to 
>> serverSocketAdaptorXXX to align with the class name. Otherwise looks 
>> good.
>
> Yes, that is better.
>
> Updated webrev:
> ? https://cr.openjdk.java.net/~chegar/8224730/webrev.02/
Looks good.

From chris.hegarty at oracle.com  Thu May 30 11:04:05 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 30 May 2019 12:04:05 +0100
Subject: RFR [13] 8224973: URLStreamHandler.openConnection(URL,Proxy) - spec
 and implementation mismatch 
Message-ID: <4AAAC32D-BCB4-4AB1-A515-F2283610B9DA@oracle.com>

The current default implementation of openConnection(URL,Proxy) simply
throws UnsupportedOperationException. Pedantically, this violates its
own specification, since it does not throw IllegalArgumentException when
passed a null value.

To resolve this, the default implementation should be updated and
specified. Trivially, perform null argument checking, and subsequently
throw UnsupportedOperationException ( since the URL stream handler
implementation can realistically do nothing more ).

Webrev:
  https://cr.openjdk.java.net/~chegar/8224973/webrev.00/

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

-Chris.

P.S. There are a number of these minor API / default implementation
issues in the java.net package, resulting from evolution over the years.

From Alan.Bateman at oracle.com  Thu May 30 12:42:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 May 2019 13:42:21 +0100
Subject: RFR [13] 8224973: URLStreamHandler.openConnection(URL,Proxy) -
 spec and implementation mismatch
In-Reply-To: <4AAAC32D-BCB4-4AB1-A515-F2283610B9DA@oracle.com>
References: <4AAAC32D-BCB4-4AB1-A515-F2283610B9DA@oracle.com>
Message-ID: <c33b2adc-909d-d749-f5bc-55b54d247556@oracle.com>

On 30/05/2019 12:04, Chris Hegarty wrote:
> The current default implementation of openConnection(URL,Proxy) simply
> throws UnsupportedOperationException. Pedantically, this violates its
> own specification, since it does not throw IllegalArgumentException when
> passed a null value.
>
> To resolve this, the default implementation should be updated and
> specified. Trivially, perform null argument checking, and subsequently
> throw UnsupportedOperationException ( since the URL stream handler
> implementation can realistically do nothing more ).
>
> Webrev:
>    https://cr.openjdk.java.net/~chegar/8224973/webrev.00/
>
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8225047
>
Looks fine. I've added myself as Reviewer to the CSR.

-Alan

From chris.hegarty at oracle.com  Thu May 30 14:54:15 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 30 May 2019 15:54:15 +0100
Subject: RFR [13] 8225060: java.net.DefaultInterface invokes
 NetworkInterface::getInetAddresses without doPriv
Message-ID: <E00D7C93-ABA6-4D67-91FC-0118233880D9@oracle.com>

The test for 8224730 [1] exposes an issue in the macOS package-private
java.net.DefaultInterface - NetworkInterface::getInetAddresses is
invoked without a doPriv. DefaultInterface is loaded by
NetworkInterface's static initializer.

Example stacktrace, as seen from java/net/ServerSocket/TestLocalAddress.java:

    ...
    at java.base/java.net.NetworkInterface.getCheckedInetAddresses(NetworkInterface.java:155)
    at java.base/java.net.NetworkInterface.getInetAddresses(NetworkInterface.java:117)
    at java.base/java.net.DefaultInterface.chooseDefaultInterface(DefaultInterface.java:85)
    at java.base/java.net.DefaultInterface.<clinit>(DefaultInterface.java:46)
    at java.base/java.net.NetworkInterface.<clinit>(NetworkInterface.java:69)
    at java.base/java.net.Inet6AddressImpl.loopbackAddress(Inet6AddressImpl.java:126)
    at java.base/java.net.InetAddress.getLoopbackAddress(InetAddress.java:1363)
    at java.base/sun.nio.ch.Net.getLoopbackAddress(Net.java:229)
    at java.base/sun.nio.ch.Net.getRevealedLocalAddress(Net.java:218)
    at java.base/sun.nio.ch.ServerSocketAdaptor.getInetAddress(ServerSocketAdaptor.java:92)
    at java.base/java.net.ServerSocket.getLocalSocketAddress(ServerSocket.java:460)
    ...


The fix is to add the missing doPriv:

diff --git a/src/java.base/macosx/classes/java/net/DefaultInterface.java b/src/java.base/macosx/classes/java/net/DefaultInterface.java
--- a/src/java.base/macosx/classes/java/net/DefaultInterface.java
+++ b/src/java.base/macosx/classes/java/net/DefaultInterface.java
@@ -1,12 +1,12 @@
 /*
- * Copyright (c) 2011, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2011, 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
  * particular file as subject to the "Classpath" exception as provided
  * by Oracle in the LICENSE file that accompanied this code.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -30,20 +30,22 @@
  * outgoing IPv6 traffic that does not specify a scope_id (and which needs one).
  * We choose the first interface that is up and is (in order of preference):
  * 1. neither loopback nor point to point
  * 2. point to point
  * 3. loopback
  * 4. none.
  * Platforms that do not require a default interface implement a dummy
  * that returns null.
  */

+import java.security.AccessController;
+import java.security.PrivilegedAction;
 import java.util.Enumeration;
 import java.io.IOException;

 class DefaultInterface {

     private static final NetworkInterface defaultInterface =
         chooseDefaultInterface();

     static NetworkInterface getDefault() {
         return defaultInterface;
@@ -75,21 +77,22 @@
         NetworkInterface ppp = null;
         NetworkInterface loopback = null;

         while (nifs.hasMoreElements()) {
             NetworkInterface ni = nifs.nextElement();
             try {
                 if (!ni.isUp() || !ni.supportsMulticast())
                     continue;

                 boolean ip4 = false, ip6 = false;
-                Enumeration<InetAddress> addrs = ni.getInetAddresses();
+                PrivilegedAction<Enumeration<InetAddress>> pa = ni::getInetAddresses;
+                Enumeration<InetAddress> addrs = AccessController.doPrivileged(pa);
                 while (addrs.hasMoreElements()) {
                     InetAddress addr = addrs.nextElement();
                     if (!addr.isAnyLocalAddress()) {
                         if (addr instanceof Inet4Address) {
                             ip4 = true;
                         } else if (addr instanceof Inet6Address) {
                             ip6 = true;
                         }
                     }
                 }

-Chris.

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


From Alan.Bateman at oracle.com  Thu May 30 15:57:12 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 May 2019 16:57:12 +0100
Subject: RFR [13] 8225060: java.net.DefaultInterface invokes
 NetworkInterface::getInetAddresses without doPriv
In-Reply-To: <E00D7C93-ABA6-4D67-91FC-0118233880D9@oracle.com>
References: <E00D7C93-ABA6-4D67-91FC-0118233880D9@oracle.com>
Message-ID: <b1271796-f54b-e2e4-92cf-6b75c2a44b07@oracle.com>

This looks okay. Hopefully we can get rid of this code as part of the 
fix for 8216417.

-Alan

On 30/05/2019 15:54, Chris Hegarty wrote:
> The test for 8224730 [1] exposes an issue in the macOS package-private
> java.net.DefaultInterface - NetworkInterface::getInetAddresses is
> invoked without a doPriv. DefaultInterface is loaded by
> NetworkInterface's static initializer.
>
> Example stacktrace, as seen from java/net/ServerSocket/TestLocalAddress.java:
>
>      ...
>      at java.base/java.net.NetworkInterface.getCheckedInetAddresses(NetworkInterface.java:155)
>      at java.base/java.net.NetworkInterface.getInetAddresses(NetworkInterface.java:117)
>      at java.base/java.net.DefaultInterface.chooseDefaultInterface(DefaultInterface.java:85)
>      at java.base/java.net.DefaultInterface.<clinit>(DefaultInterface.java:46)
>      at java.base/java.net.NetworkInterface.<clinit>(NetworkInterface.java:69)
>      at java.base/java.net.Inet6AddressImpl.loopbackAddress(Inet6AddressImpl.java:126)
>      at java.base/java.net.InetAddress.getLoopbackAddress(InetAddress.java:1363)
>      at java.base/sun.nio.ch.Net.getLoopbackAddress(Net.java:229)
>      at java.base/sun.nio.ch.Net.getRevealedLocalAddress(Net.java:218)
>      at java.base/sun.nio.ch.ServerSocketAdaptor.getInetAddress(ServerSocketAdaptor.java:92)
>      at java.base/java.net.ServerSocket.getLocalSocketAddress(ServerSocket.java:460)
>      ...
>
>
> The fix is to add the missing doPriv:
>
> diff --git a/src/java.base/macosx/classes/java/net/DefaultInterface.java b/src/java.base/macosx/classes/java/net/DefaultInterface.java
> --- a/src/java.base/macosx/classes/java/net/DefaultInterface.java
> +++ b/src/java.base/macosx/classes/java/net/DefaultInterface.java
> @@ -1,12 +1,12 @@
>   /*
> - * Copyright (c) 2011, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 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
>    * particular file as subject to the "Classpath" exception as provided
>    * by Oracle in the LICENSE file that accompanied this code.
>    *
>    * This code is distributed in the hope that it will be useful, but WITHOUT
>    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> @@ -30,20 +30,22 @@
>    * outgoing IPv6 traffic that does not specify a scope_id (and which needs one).
>    * We choose the first interface that is up and is (in order of preference):
>    * 1. neither loopback nor point to point
>    * 2. point to point
>    * 3. loopback
>    * 4. none.
>    * Platforms that do not require a default interface implement a dummy
>    * that returns null.
>    */
>
> +import java.security.AccessController;
> +import java.security.PrivilegedAction;
>   import java.util.Enumeration;
>   import java.io.IOException;
>
>   class DefaultInterface {
>
>       private static final NetworkInterface defaultInterface =
>           chooseDefaultInterface();
>
>       static NetworkInterface getDefault() {
>           return defaultInterface;
> @@ -75,21 +77,22 @@
>           NetworkInterface ppp = null;
>           NetworkInterface loopback = null;
>
>           while (nifs.hasMoreElements()) {
>               NetworkInterface ni = nifs.nextElement();
>               try {
>                   if (!ni.isUp() || !ni.supportsMulticast())
>                       continue;
>
>                   boolean ip4 = false, ip6 = false;
> -                Enumeration<InetAddress> addrs = ni.getInetAddresses();
> +                PrivilegedAction<Enumeration<InetAddress>> pa = ni::getInetAddresses;
> +                Enumeration<InetAddress> addrs = AccessController.doPrivileged(pa);
>                   while (addrs.hasMoreElements()) {
>                       InetAddress addr = addrs.nextElement();
>                       if (!addr.isAnyLocalAddress()) {
>                           if (addr instanceof Inet4Address) {
>                               ip4 = true;
>                           } else if (addr instanceof Inet6Address) {
>                               ip6 = true;
>                           }
>                       }
>                   }
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8224730
>


From daniel.fuchs at oracle.com  Thu May 30 17:08:15 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 May 2019 18:08:15 +0100
Subject: RFR [13] 8224973: URLStreamHandler.openConnection(URL,Proxy) -
 spec and implementation mismatch
In-Reply-To: <4AAAC32D-BCB4-4AB1-A515-F2283610B9DA@oracle.com>
References: <4AAAC32D-BCB4-4AB1-A515-F2283610B9DA@oracle.com>
Message-ID: <6178485c-9344-c602-30bc-311d84cea2b7@oracle.com>

Looks fine Chris!

best regards,

-- daniel

On 30/05/19 12:04, Chris Hegarty wrote:
> The current default implementation of openConnection(URL,Proxy) simply
> throws UnsupportedOperationException. Pedantically, this violates its
> own specification, since it does not throw IllegalArgumentException when
> passed a null value.
> 
> To resolve this, the default implementation should be updated and
> specified. Trivially, perform null argument checking, and subsequently
> throw UnsupportedOperationException ( since the URL stream handler
> implementation can realistically do nothing more ).
> 
> Webrev:
>    https://cr.openjdk.java.net/~chegar/8224973/webrev.00/
> 
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8225047
> 
> -Chris.
> 
> P.S. There are a number of these minor API / default implementation
> issues in the java.net package, resulting from evolution over the years.
> 


From chris.hegarty at oracle.com  Fri May 31 10:58:23 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 31 May 2019 11:58:23 +0100
Subject: RFR [13] 8225037: java.net.JarURLConnection::getJarEntry() throws
 NullPointerException
Message-ID: <4C6219C5-8C14-43B9-B46D-C4454C5521AD@oracle.com>

The implementation of java.net.JarURLConnection has a private String,
`entryName`, that is used to hold the optional jar file entry name. If
the  JAR file URL corresponding to the JarURLConnection points to a JAR
file and not a JAR file entry, then `entryName` will be `null` ( which
should be ok ).

The default implementation of JarURLConnection::getJarEntry should only
invoke `getJarEntry(entryName)` if the name is non-null. ( This is not
an issue in the built-in JarURLConnection handler implementation, as it
already correctly handles a null `entryName` )

https://cr.openjdk.java.net/~chegar/8225037/webrev.00/

-Chris.

From vtewar26 at in.ibm.com  Fri May 31 14:04:48 2019
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Fri, 31 May 2019 14:04:48 +0000
Subject: RFR [13] 8225037: java.net.JarURLConnection::getJarEntry() throws
 NullPointerException
In-Reply-To: <4C6219C5-8C14-43B9-B46D-C4454C5521AD@oracle.com>
References: <4C6219C5-8C14-43B9-B46D-C4454C5521AD@oracle.com>
Message-ID: <OF7D8D8C66.A779CB35-ON0025840B.004D41AD-0025840B.004D5847@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190531/19dd9d93/attachment.html>

From chris.hegarty at oracle.com  Fri May 31 14:05:50 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 31 May 2019 15:05:50 +0100
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java
 failed with java.net.BindException: Address already in use: Cannot bind
In-Reply-To: <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
References: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
 <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
Message-ID: <B3FCFF7B-41BE-4949-8A25-9D07F9390D15@oracle.com>


> On 28 May 2019, at 16:20, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> ..
> 
> I would like to run it through our internal build and test infra, after which
> I?ll post the results here.

All clear ( this test passes successfully in our build and test environment ).

-Chris.

From christoph.langer at sap.com  Fri May 31 14:56:09 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 31 May 2019 14:56:09 +0000
Subject: [RFR] 8194231: java/net/DatagramSocket/ReuseAddressTest.java
 failed with java.net.BindException: Address already in use: Cannot bind
In-Reply-To: <B3FCFF7B-41BE-4949-8A25-9D07F9390D15@oracle.com>
References: <VE1PR02MB5677DA65ED40B0A9A8C312FEE31E0@VE1PR02MB5677.eurprd02.prod.outlook.com>
 <25AB79A8-496D-4E7D-9791-D89E79D22BB0@oracle.com>
 <B3FCFF7B-41BE-4949-8A25-9D07F9390D15@oracle.com>
Message-ID: <DB7PR02MB5193272E5026E9029F69F62B8A190@DB7PR02MB5193.eurprd02.prod.outlook.com>

Thanks, Chris. I pushed it then on behalf of Arno.

> -----Original Message-----
> From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Chris
> Hegarty
> Sent: Freitag, 31. Mai 2019 16:06
> To: Zeller, Arno <arno.zeller at sap.com>
> Cc: net-dev at openjdk.java.net
> Subject: Re: [RFR] 8194231:
> java/net/DatagramSocket/ReuseAddressTest.java failed with
> java.net.BindException: Address already in use: Cannot bind
> 
> 
> > On 28 May 2019, at 16:20, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
> >
> > ..
> >
> > I would like to run it through our internal build and test infra, after which
> > I?ll post the results here.
> 
> All clear ( this test passes successfully in our build and test environment ).
> 
> -Chris.