Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Martin, On 13/03/2019 17:29, Martin Buchholz wrote: ... The difficulty of testing networking environments is an impediment to progress. Chris, you might want to publish your hacky changes as an experimental patch in cr.openjdk. I will do this, but, as I said, it is just a hack. At Google

RFR 8213912: Semantic typo in HttpExchange.java

In the class-level description for com.sun.net.httpserver.HttpExchange there is a typo related to the request body input stream, that may cause confusion. It should be fixed. The typical life-cycle of an exchange, as described, should advise the reader that the request body input stream *SHOULD* b

Re: RFR 8213912: Semantic typo in HttpExchange.java

Daniel, > On 14 Mar 2019, at 11:10, Daniel Fuchs wrote: > > Hi Chris, > > Thanks for fixing this, it is an important distinction! Thanks for the review. > (and I like John's description of the issue :-)) > > I am wondering though - whether there's a relationship with > this bug, and JDK-8180

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

It's just a hack, but enough to get me started so I can asses some of what is needed to support running the tests on an IPv6-only environment. http://cr.openjdk.java.net/~chegar/ipv6-only-hack/ My /etc/hosts file has entries for `localhost` and the _host_, that return `::1`. This is enough

RFR 8179549: Typo in network properties documentation

Trivial typo fix. diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html +++ b/src/java.base/share/classes/java/net/doc-files/net-

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

", > InetAddress.getLoopbackAddress().getHostAddress(), 9002, "/") > u ==> http://127.0.0.1:9002/ <http://127.0.0.1:9002/> > jshell> URL u = new URL("http", > InetAddress.getLoopbackAddress().getHostName(), 9002, "/") > u ==> http://lo

RFR [13] 8220719: Allow other named NetPermissions to be used

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

Re: RFR [13] 8220719: Allow other named NetPermissions to be used

> On 15 Mar 2019, at 15:22, Sean Mullan wrote: > > Looks good to me. > > —Sean Additionally, as noted in the CSR comments, an implNote ( similar to that of what was added by 8077055 ) could be added, to clearly spell out the possibility of, and guidance for, other non-standard target names. It

Re: 8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl

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

RFR [13] 8170705: sun/net/www/protocol/http/StackTraceTest.java fails intermittently with Invalid Http response

This review is for a test only change. It resolves a rare intermittent failure. The issue is that the test creates, retrieves the local port, and immediately closes a server socket. It then expects this port to refuse subsequent connections. This is an anti-pattern, since on a busy machine the por

RFR [13] 8220663: Incorrect handling of IPv6 addresses in Socket(Proxy.HTTP)

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

RFR [13] 8153508: ContentHandler API contains link to private contentPathProp

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

RFR [13] 8221098: Run java/net/URL/HandlerLoop.java in othervm mode

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

Re: 8221259: New tests for java.net.Socket to exercise long standing behavior

Alan, On 21/03/2019 15:06, Alan Bateman wrote: There are a number of tests in niosocketimpl-branch of the sandbox that are needed to exercise Socket in ways that aren't fully exercised by the existing tests. I'd like to bring some of these tests into jdk/jdk in advance of the new NIO based Soc

RFR [13] 8219446: Specify behaviour of timeout accepting methods of Socket and ServerSocket if timeout is negative

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

Re: RFR [13] 8219446: Specify behaviour of timeout accepting methods of Socket and ServerSocket if timeout is negative

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

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

Arthur, > On 19 Mar 2019, at 15:31, Arthur Eubanks wrote: > > (Sorry for the late response, I keep getting sidetracked by other stuff) > > Is there a reason you're trying to deprecate the URL constructors? Yes, they are generally more error-prone than using URI, since they don’t encode illegal

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

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

Re: Implementing a custom SocketImpl

Jared, As Alan mentioned, SocketImpl was designed 20+ years ago and has not kept pace with other areas of the platform. Mainly because it has not been used all that much. As part of JEP 337 [1] a decision was made to NOT simply provide a RDMA socket impl for the sockets part of this work, but rath

Re: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI builder

Arthur, I like the way this is turning out. > On 26 Mar 2019, at 12:05, Daniel Fuchs wrote: > > ... > 2. B6890349.java > > Using URI.toURL() in this test will change the nature of > the test. I believe that in this specific case using the > multi-arg URL constuctor should be preferred. >

Re: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI builder

Arthur, On 26/03/2019 22:07, Arthur Eubanks wrote: Forgot to add URIBuilder, fixed in: http://cr.openjdk.java.net/~aeubanks/8220575/webrev.03/index.html I am happy with this. Just a few minor comments. 1) test/jdk/java/net/ResponseCache/Test2.java 83 url = URIBuilder.newBuilder()

Re: [RFR]: 8220575: Replace hardcoded 127.0.0.1 in URLs with new URI builder

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

Re: RFR: 8221395: HttpClient leaving connections in CLOSE_WAIT state until Java process ends

On 27/03/2019 17:02, Daniel Fuchs wrote: ... Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8221395/webrev.00/ Looks good. Trivially, add the bugId to @bug in the test. -Chris.

[ipv6] Regarding 8220673: Add test library support for determining platform IP support

Arthur, Several tests require the presence of either: 1) IPv4, or 2) IPv6, or 3) IPv4&IPv6. A test library utility class could provide such. Here is a rough idea about how to determine Internet Protocol support. http://cr.openjdk.java.net/~chegar/8220673/webrev.00/ It might be enough to exper

Re: RFR: JDK-8184770: JDWP support for IPv6

Alex, On 29/03/2019 22:07, Alex Menkov wrote: (added net-dev as suggested by Alan) Net gurus, please assist in reviewing socket-related code. New webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ Specifically on SocketTransportService.java. What Arthur has proposed is better ( chan

Re: RFR: JDK-8184770: JDWP support for IPv6

On 01/04/2019 12:50, Chris Hegarty wrote: ... Specifically on SocketTransportService.java. What Arthur has proposed is better ( changing to lastIndexOf alone is not sufficient ). Or is your assumption that the IPv6 literal is not enclosed in square brackets? More specifically, what syntax

[ipv6] Issue Tracking

Arthur, others, In order to help track the all the IPv6 related work, we have the following issues: Improved IPv6 Support ( for implementation issues ) https://bugs.openjdk.java.net/browse/JDK-8221681 Update JDK networking tests for IPv6-only environments ( test-only ) https://bugs.openjdk.

Re: RFR: JDK-8184770: JDWP support for IPv6

On 01/04/2019 10:51, Daniel Fuchs wrote: Hi Arthur, Not directly related to Alex's original question but... On 30/03/2019 00:03, Arthur Eubanks wrote: We have some ipv6 patches as well in this area as well (as well as other patches to support ipv6 only environments) that we're trying to ups

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

Arthur, > On 1 Apr 2019, at 21:52, Arthur Eubanks wrote: > > There are a bunch of tests with "-Djava.net.preferIPv4Stack=true", which > should clearly fail in an IPv6 only environment. Right. > Would skipping these when IPv4 is not supported be okay? Yes, I believe so, but we will need to ch

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

Arthur, Daniel, > On 10 Apr 2019, at 21:39, Arthur Eubanks wrote: > > Here's a prototype webrev to see if the approach is okay with you. If it > looks good, I'll continue with the remaining tests I can find. (should I > start a new thread for the webrev?) > > http://cr.openjdk.java.net/~aeuba

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

Daniel, > On 11 Apr 2019, at 17:15, Daniel Fuchs wrote: > > On 11/04/2019 17:01, Chris Hegarty wrote: >> Yes, this is a good point. What’s nice about this is that there is just >> one body of code that provides the functionality ( and it is all in >> Java, not native)

Re: ServerSocket.isBound() continue to return true after close() is called.

The following JIRA issue has been filed to track this: https://bugs.openjdk.java.net/browse/JDK-8222363 -Chris. P.S. my bad! I missed this case when working on 6505016 ( in 2007! ) > On 11 Apr 2019, at 16:27, Norman Maurer wrote: > > Ok thanks… update to the java docs sounds good to me. I w

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

Arthur, > On 16 Apr 2019, at 00:37, Arthur Eubanks wrote: > > While looking through some of the tests, I noticed that there is > jdk.test.lib.NetworkConfiguration which has methods like "isIPv6Available". > It seems much more comprehensive than what is in the proposed IPSupport. > Although th

Re: [RFR]: 8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)

Arthur, On 16/04/2019 22:34, Arthur Eubanks wrote: Hi, Copied from the bug https://bugs.openjdk.java.net/browse/JDK-8222562: Some of the networking code tries to support dual socket support. However, it doesn't work with IPv6 only systems. setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, 0) returns

Re: How to deal with multi-step WWW-Authenticate with the new HttpClient

Thank you for following up with the resolution, Max. -Chris. On 17/04/2019 14:24, Weijun Wang wrote: Sorry, after adding "-Djdk.httpclient.HttpClient.log=headers,errors,channel" I found out it's my problem. On Apr 17, 2019, at 11:09 AM, Weijun Wang wrote: Hi, All, I am trying the new Http

Re: [ipv6] Issue Tracking

Paul, On 17/04/2019 01:26, Paul Marks wrote: On Mon, Apr 1, 2019 at 9:38 AM Martin Buchholz > wrote: Sorry for never having had the time to finish https://bugs.openjdk.java.net/browse/JDK-8179037 Improve IPv6 support I think https://bugs.openjdk.java.ne

[ipv6] Re: [RFR]: 8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)

Arthur, On 22/04/2019 19:19, Arthur Eubanks wrote: Here's a new webrev that entirely skips the setting of IPV6_V6ONLY option to 0 if IPv4 isn't enabled. http://cr.openjdk.java.net/~aeubanks/ipv6setsockopt/webrev.01/index.html This looks reasonable to me. -Chris.

Re: [ipv6] Re: [RFR]: 8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)

Arthur, On 23/04/2019 11:20, Chris Hegarty wrote: Arthur, On 22/04/2019 19:19, Arthur Eubanks wrote: Here's a new webrev that entirely skips the setting of IPV6_V6ONLY option to 0 if IPv4 isn't enabled. http://cr.openjdk.java.net/~aeubanks/ipv6setsockopt/webrev.01/index.html

Re: [ipv6] Re: [RFR]: 8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)

Arthur, > On 23 Apr 2019, at 16:54, Arthur Eubanks wrote: > > ... > New webrev: > http://cr.openjdk.java.net/~aeubanks/ipv6setsockopt/webrev.02/index.html > Looks good to me. -Chris.

Re: RFR: 8129315: java/net/Socket/LingerTest.java and java/net/Socket/ShutdownBoth.java timeout intermittently

Daniel, On 26/04/2019 14:33, Daniel Fuchs wrote: Hi, Please find below a test stabilization fix for: 8129315: java/net/Socket/LingerTest.java and java/net/Socket/ShutdownBoth.java timeout intermittently http://cr.openjdk.java.net/~dfuchs/webrev_8129315/webrev.00/index.html This loo

Re: RFR 8216978: Drop support for pre JDK 1.4 SocketImpl implementations

Michael, On 29/04/2019 10:52, Michael McMahon wrote: Hi, This is another change which is part of the general cleanup of SocketImpls. The change removes support for pre JDK 1.4 socketimpls which do not implement the timed connect method. These SocketImpls have not been compilable since 1.4 and

Re: RFR 8216978: Drop support for pre JDK 1.4 SocketImpl implementations

On 29/04/2019 12:17, Alan Bateman wrote: ... Changing SIS.close and SOS.close to caller super.close raises a number of questions. These close should never be called Socket.getInputStream and getOutputStream don't leak these streams to user code (they used to but now in JDK 13). My concern is

Re: RFR 8216978: Drop support for pre JDK 1.4 SocketImpl implementations

> On 30 Apr 2019, at 10:53, Michael McMahon > wrote: > > Thanks for all the comments. A new webrev is at: > > http://cr.openjdk.java.net/~michaelm/8216978/webrev.2/index.html Looks good. -Chris.

Re: RFR: 8223145: [teststabilization] Replace wildcard address with loopback or local host in test - part 1

Daniel, > On 30 Apr 2019, at 12:16, Daniel Fuchs 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

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

> On 6 May 2019, at 23:55, Martin Buchholz wrote: > > > > On Thu, May 2, 2019 at 2:28 AM Daniel Fuchs > wrote: > > 1. IPSupport needs to read system properties, attempts > to bind sockets etc... I wonder how that might interact > with tests that use a

Re: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should choose loopback address that is available

Arthur, > On 1 May 2019, at 23:53, Arthur Eubanks wrote: > > Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223214 >

Re: 8218559: Reimplement the Legacy Socket API

> On 1 May 2019, at 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

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

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

Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

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 EPROT

Re: 8218559: Reimplement the Legacy Socket API

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 n

Re: [teststabilization] RFR: 8223573: Replace wildcard address with loopback or local host in tests - part 4

Daniel, > On 9 May 2019, at 10:21, Daniel Fuchs 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 add

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

Alan, > On 9 May 2019, at 07:22, Alan Bateman 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 ar

Re: 8218559: Reimplement the Legacy Socket API

Alan, > On 9 May 2019, at 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

Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

Arthur, > On 8 May 2019, at 18:33, Arthur Eubanks 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.

Re: [RFR]: 8223652: Rename IPSupport.skipIfCurrentConfigurationIsInvalid()

+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 i

Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

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! S

Re: PING: Re: RFR: JDK-8184770: JDWP support for IPv6

> On 7 May 2019, at 19:40, serguei.spit...@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 o

Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

Arthur, > On 10 May 2019, at 17:37, Arthur Eubanks 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 eve

Re: [teststabilization] RFR: 8223632: Replace wildcard address with loopback or local host in tests - part 5

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. Pr

Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly

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 yi

Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly

, 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 :::::::0001 : > expected host name localhost​ > Exception in thread "main" java.lang.RuntimeException: reverse lookup of &g

Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

Arthur, > On 11 May 2019, at 11:48, Chris Hegarty wrote: > > Arthur, > >> On 10 May 2019, at 17:37, Arthur Eubanks > <mailto:aeuba...@google.com>> wrote: >> >> Sounds good. >> New webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.03/

Re: PING: Re: RFR: JDK-8184770: JDWP support for IPv6

ed; - 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:

Re: RFR: 8223880: Update sun/net/ftp/FtpURL.java and sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses

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.

Re: RFR: 8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic

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/sy

Re: [ipv6] RFR: 8223214: Inet6AddressImpl.loopbackAddress() should choose loopback address that is available

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

Re: [ipv6]: 8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java assume IPv4 is available

+1 -Chris. > On 16 May 2019, at 10:56, Daniel Fuchs 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/web

Re: [ipv6]: 8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment

Arthur, > On 16 May 2019, at 00:24, Arthur Eubanks wrote: > > webrev: http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8224014 >

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

Arthur, On 17/05/2019 06:57, Arthur Eubanks wrote: On Thu, May 16, 2019 at 7:44 PM Vyom Tiwari > wrote: Hi Arthur, do we need "Integer.toString(4)" to convert int to string in SocksProxyVersion ? Thanks, Vyom Fixed. http://cr.openjdk.java.net/~

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

Arthur, > On 17 May 2019, at 17:50, Arthur Eubanks 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/ >

Re: [teststabilization] RFR: 8223856: Replace wildcard address with loopback or local host in tests - part 8

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

Re: [ipv6]: 8224019: test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes IPv4 is always available

Arthur, On 17/05/2019 18:22, Arthur Eubanks wrote: ... http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/ Looks good. -Chris.

Re: [ipv6]: 8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment

Arthur, On 17/05/2019 18:02, Arthur Eubanks wrote: ... Oh yes, http://cr.openjdk.java.net/~aeubanks/8224014/webrev.02/ Looks good. -Chris.

RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

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 a

Re: [teststabilization] RFR: 8224204: Replace wildcard address with loopback or local host in tests - part 10

> On 21 May 2019, at 18:25, Daniel Fuchs 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 ob

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

Alan, > On 21 May 2019, at 20:05, Alan Bateman 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

Re: [ipv6] RFR: 8224248: test/jdk/java/net/InetAddress/CheckJNI.java assumes 127.0.0.1 is available

Arthur, > On 20 May 2019, at 22:30, Arthur Eubanks wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224248 > webrev: > http://cr.openjdk.java.net/~aeubanks/8224248/webrev.00/ >

Re: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1

Arthur, > On 21 May 2019, at 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 >

Re: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1

Arthur, > On 21 May 2019, at 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 >

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

Daniel, > On 23 May 2019, at 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 >

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

/ -Chris. > On 23 May 2019, at 09:13, Alan Bateman 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 > t

Re: [teststabilization] RFR: 8224603: Replace wildcard address with loopback or local host in tests - part 11

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 Danie

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

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 a

Re: [teststabilization] RFR: 8224761: Replace wildcard address with loopback or local host in tests - part 12

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 http

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

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

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

Alan, > On 27 May 2019, at 17:11, Alan Bateman 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

RFR [13] 8224730: java.net.ServerSocket::toString not invoking checkConnect

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 fi

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 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 S

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

> On 29 May 2019, at 08:40, Alan Bateman 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

Re: RFR [13] 8224730: java.net.ServerSocket::toString not invoking checkConnect

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

Re: RFR [13] 8224730: java.net.ServerSocket::toString not invoking checkConnect

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 brea

RFR [13] 8224973: URLStreamHandler.openConnection(URL,Proxy) - spec and implementation mismatch

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 a

RFR [13] 8225060: java.net.DefaultInterface invokes NetworkInterface::getInetAddresses without doPriv

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/TestLocalAd

RFR [13] 8225037: java.net.JarURLConnection::getJarEntry() throws NullPointerException

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 ).

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 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.

RFR [13] 8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER

Please review this change to fix a bug in the handling of SO_LINGER in the plain socket impl, when setting or retrieving the option through the new-style setOption or getOption, respectively. The implementation of the new-style option just delegates to the old-style implementation, but the old-styl

Re: RFR [13] 8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER

Alan, > On 4 Jun 2019, at 13:17, Alan Bateman wrote: >> ... > For the test it might be cleaner if the soLinger test were renamed and called > from doSocketTests. That is, it's a bit strange to test Socket, ServerSocket, > ... and then come back to do a specialized test for Socket linger. The >

Re: RFR [13] 8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER

Alan, > On 4 Jun 2019, at 13:50, Alan Bateman wrote: > > On 04/06/2019 13:48, Chris Hegarty wrote: >> Updated as suggested: >> https://cr.openjdk.java.net/~chegar/8225214/webrev.01/ > I assume soLinger doesn't need to be public. I guess I'd rename it something

RFR [13] 8225424: Add jdk.net.usePlainSocketImpl runs to a couple of tests

Prior to 8221481 (Reimplement the Legacy Socket API), these tests were run with the plain socket impl. They should be run with both system-default SocketImpls to ensure that the impls behave as expected. $ hg diff diff --git a/test/jdk/java/net/SocketOption/AfterClose.java b/test/jdk/java/net/Soc

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

+1 from me too. Arthur, This test is failing quite frequently in our build and test system. If not pushed by this time tomorrow, I will push it on your behalf. -Chris. > On 6 Jun 2019, at 12:13, Daniel Fuchs wrote: > > Hi Arthur, > > Looks good to me too. > I have run it through our test sys

<    5   6   7   8   9   10   11   12   13   14   >