From dmitry.samersoff at oracle.com Wed Oct 1 07:01:19 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 01 Oct 2014 11:01:19 +0400 Subject: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist In-Reply-To: <542B2E02.9060901@oracle.com> References: <542ACA62.3050301@oracle.com> <542AEE18.5090403@oracle.com> <542B2E02.9060901@oracle.com> Message-ID: <542BA6BF.2040204@oracle.com> Looks good for me! -Dmitry On 2014-10-01 02:26, Mark Sheppard wrote: > Thanks Tom and Dmitry > > last up best dressed ... > > .invalid as the test domain is a good recommendation > > change is now > > --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 > 13:25:04 2014 +0100 > +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 > 23:23:46 2014 +0100 > @@ -36,7 +36,7 @@ > {"126.1", "126.0.0.1"}, > {"128.50.65534", "128.50.255.254"}, > {"192.168.1.2", "192.168.1.2"}, > - {"hello.foo.bar", null}, > + {"invalidhost.invalid", null}, > {"1024.1.2.3", null}, > {"128.14.66000", null } > > > regards > Mark > > > On 30/09/2014 18:53, Dmitry Samersoff wrote: >> Mark, >> >> It probably should be some-name.invalid >> >> IANA reserve .invalid TLD for tests like this one >> >> see: >> >> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml >> >> >> -Dmitry >> >> On 2014-09-30 19:21, Mark Sheppard wrote: >>> Hi >>> >>> Please oblige and review the following small change to test >>> test/java/net/InetAddress/IPv4Formats.java >>> >>> --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>> 13:25:04 2014 +0100 >>> +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>> 15:11:05 2014 +0100 >>> @@ -36,7 +36,7 @@ >>> {"126.1", "126.0.0.1"}, >>> {"128.50.65534", "128.50.255.254"}, >>> {"192.168.1.2", "192.168.1.2"}, >>> - {"hello.foo.bar", null}, >>> + {"somehost.some-domain", null}, >>> {"1024.1.2.3", null}, >>> {"128.14.66000", null } >>> >>> which addresses the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8058932 >>> >>> ping hello.foo.bar >>> >>> Pinging hello.foo.bar [127.0.53.53] with 32 bytes of data: >>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>> >>> this highlights a DNS configuration issue as indicated in >>> https://www.icann.org/resources/pages/name-collision-2013-12-06-en >>> >>> so we remove foo.bar from the test and replace with somehost.some-domain >>> >>> regards >>> Mark >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ivan.gerasimov at oracle.com Wed Oct 1 08:48:48 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 01 Oct 2014 12:48:48 +0400 Subject: RFR 8059450: Not quite correct code sample in javadoc Message-ID: <542BBFF0.9060008@oracle.com> Hello! This is a javadoc bug. In the code sample a redundant argument to a constructor of URI is passed. Probably a copy-paste error. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059450 WEBREV: http://cr.openjdk.java.net/~igerasim/8059450/0/webrev/ Sincerely yours, Ivan From chris.hegarty at oracle.com Wed Oct 1 14:58:32 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 1 Oct 2014 07:58:32 -0700 Subject: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist In-Reply-To: <542BA6BF.2040204@oracle.com> References: <542ACA62.3050301@oracle.com> <542AEE18.5090403@oracle.com> <542B2E02.9060901@oracle.com> <542BA6BF.2040204@oracle.com> Message-ID: Reviewed. -Chris. On 1 Oct 2014, at 00:01, Dmitry Samersoff wrote: > Looks good for me! > > -Dmitry > > On 2014-10-01 02:26, Mark Sheppard wrote: >> Thanks Tom and Dmitry >> >> last up best dressed ... >> >> .invalid as the test domain is a good recommendation >> >> change is now >> >> --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >> 13:25:04 2014 +0100 >> +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >> 23:23:46 2014 +0100 >> @@ -36,7 +36,7 @@ >> {"126.1", "126.0.0.1"}, >> {"128.50.65534", "128.50.255.254"}, >> {"192.168.1.2", "192.168.1.2"}, >> - {"hello.foo.bar", null}, >> + {"invalidhost.invalid", null}, >> {"1024.1.2.3", null}, >> {"128.14.66000", null } >> >> >> regards >> Mark >> >> >> On 30/09/2014 18:53, Dmitry Samersoff wrote: >>> Mark, >>> >>> It probably should be some-name.invalid >>> >>> IANA reserve .invalid TLD for tests like this one >>> >>> see: >>> >>> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml >>> >>> >>> -Dmitry >>> >>> On 2014-09-30 19:21, Mark Sheppard wrote: >>>> Hi >>>> >>>> Please oblige and review the following small change to test >>>> test/java/net/InetAddress/IPv4Formats.java >>>> >>>> --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>>> 13:25:04 2014 +0100 >>>> +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>>> 15:11:05 2014 +0100 >>>> @@ -36,7 +36,7 @@ >>>> {"126.1", "126.0.0.1"}, >>>> {"128.50.65534", "128.50.255.254"}, >>>> {"192.168.1.2", "192.168.1.2"}, >>>> - {"hello.foo.bar", null}, >>>> + {"somehost.some-domain", null}, >>>> {"1024.1.2.3", null}, >>>> {"128.14.66000", null } >>>> >>>> which addresses the issue >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8058932 >>>> >>>> ping hello.foo.bar >>>> >>>> Pinging hello.foo.bar [127.0.53.53] with 32 bytes of data: >>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>> >>>> this highlights a DNS configuration issue as indicated in >>>> https://www.icann.org/resources/pages/name-collision-2013-12-06-en >>>> >>>> so we remove foo.bar from the test and replace with somehost.some-domain >>>> >>>> regards >>>> Mark >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From mark.sheppard at oracle.com Wed Oct 1 15:26:07 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 01 Oct 2014 16:26:07 +0100 Subject: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist In-Reply-To: References: <542ACA62.3050301@oracle.com> <542AEE18.5090403@oracle.com> <542B2E02.9060901@oracle.com> <542BA6BF.2040204@oracle.com> Message-ID: <542C1D0F.2010600@oracle.com> thanks Chris On 01/10/2014 15:58, Chris Hegarty wrote: > Reviewed. > > -Chris. > > On 1 Oct 2014, at 00:01, Dmitry Samersoff wrote: > >> Looks good for me! >> >> -Dmitry >> >> On 2014-10-01 02:26, Mark Sheppard wrote: >>> Thanks Tom and Dmitry >>> >>> last up best dressed ... >>> >>> .invalid as the test domain is a good recommendation >>> >>> change is now >>> >>> --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>> 13:25:04 2014 +0100 >>> +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>> 23:23:46 2014 +0100 >>> @@ -36,7 +36,7 @@ >>> {"126.1", "126.0.0.1"}, >>> {"128.50.65534", "128.50.255.254"}, >>> {"192.168.1.2", "192.168.1.2"}, >>> - {"hello.foo.bar", null}, >>> + {"invalidhost.invalid", null}, >>> {"1024.1.2.3", null}, >>> {"128.14.66000", null } >>> >>> >>> regards >>> Mark >>> >>> >>> On 30/09/2014 18:53, Dmitry Samersoff wrote: >>>> Mark, >>>> >>>> It probably should be some-name.invalid >>>> >>>> IANA reserve .invalid TLD for tests like this one >>>> >>>> see: >>>> >>>> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml >>>> >>>> >>>> -Dmitry >>>> >>>> On 2014-09-30 19:21, Mark Sheppard wrote: >>>>> Hi >>>>> >>>>> Please oblige and review the following small change to test >>>>> test/java/net/InetAddress/IPv4Formats.java >>>>> >>>>> --- a/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>>>> 13:25:04 2014 +0100 >>>>> +++ b/test/java/net/InetAddress/IPv4Formats.java Tue Sep 30 >>>>> 15:11:05 2014 +0100 >>>>> @@ -36,7 +36,7 @@ >>>>> {"126.1", "126.0.0.1"}, >>>>> {"128.50.65534", "128.50.255.254"}, >>>>> {"192.168.1.2", "192.168.1.2"}, >>>>> - {"hello.foo.bar", null}, >>>>> + {"somehost.some-domain", null}, >>>>> {"1024.1.2.3", null}, >>>>> {"128.14.66000", null } >>>>> >>>>> which addresses the issue >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8058932 >>>>> >>>>> ping hello.foo.bar >>>>> >>>>> Pinging hello.foo.bar [127.0.53.53] with 32 bytes of data: >>>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>>> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128 >>>>> >>>>> this highlights a DNS configuration issue as indicated in >>>>> https://www.icann.org/resources/pages/name-collision-2013-12-06-en >>>>> >>>>> so we remove foo.bar from the test and replace with somehost.some-domain >>>>> >>>>> regards >>>>> Mark >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Wed Oct 1 16:49:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 1 Oct 2014 09:49:05 -0700 Subject: RFR 8059450: Not quite correct code sample in javadoc In-Reply-To: <542BBFF0.9060008@oracle.com> References: <542BBFF0.9060008@oracle.com> Message-ID: <3E7285EF-2242-4CC5-BB3A-5213C2AA5E20@oracle.com> On 1 Oct 2014, at 01:48, Ivan Gerasimov wrote: > Hello! > > This is a javadoc bug. > In the code sample a redundant argument to a constructor of URI is passed. > Probably a copy-paste error. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059450 > WEBREV: http://cr.openjdk.java.net/~igerasim/8059450/0/webrev/ This looks fine to me Ivan ( good eyes! ). -Chris. > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Wed Oct 1 19:05:31 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 01 Oct 2014 23:05:31 +0400 Subject: RFR 8059450: Not quite correct code sample in javadoc In-Reply-To: <3E7285EF-2242-4CC5-BB3A-5213C2AA5E20@oracle.com> References: <542BBFF0.9060008@oracle.com> <3E7285EF-2242-4CC5-BB3A-5213C2AA5E20@oracle.com> Message-ID: <542C507B.3080008@oracle.com> Thanks Chris! On 01.10.2014 20:49, Chris Hegarty wrote: > On 1 Oct 2014, at 01:48, Ivan Gerasimov wrote: > >> Hello! >> >> This is a javadoc bug. >> In the code sample a redundant argument to a constructor of URI is passed. >> Probably a copy-paste error. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059450 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8059450/0/webrev/ > This looks fine to me Ivan ( good eyes! ). I tried to use this sample, when figuring out how a URI deals with underscores. So it was noticed not by eyes, but by fingers :-) Sincerely yours, Ivan > -Chris. > >> Sincerely yours, >> Ivan > > From Kirk.Shoop at microsoft.com Thu Oct 2 17:03:58 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Thu, 2 Oct 2014 17:03:58 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <542326A5.9020605@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> Message-ID: <4ad741b69a30425b87377511593ab0e4@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 24/09/2014 19:21, Kirk Shoop (MS OPEN TECH) wrote: My memory is that setting it on the socket before calling listen did not work. However, we will try again and verify. ? It would be good to check, it may be that we just need to set it after the listen (in the case of listener oriented channels) and that can also be done locally without extensive changes. We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. GetVersionEx is not used and the IOCTL is applied when the socket is constructed. Thanks for sending us back for another look, Kirk -------------- next part -------------- A non-text attachment was scrubbed... Name: tcploopback-webrev.01.zip Type: application/x-zip-compressed Size: 752353 bytes Desc: tcploopback-webrev.01.zip URL: From Kirk.Shoop at microsoft.com Thu Oct 2 18:17:35 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Thu, 2 Oct 2014 18:17:35 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> Message-ID: <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 24/09/2014 19:21, Kirk Shoop (MS OPEN TECH) wrote: My memory is that setting it on the socket before calling listen did not work. However, we will try again and verify. It would be good to check, it may be that we just need to set it after the listen (in the case of listener oriented channels) and that can also be done locally without extensive changes. We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141002.zip GetVersionEx is not used and the IOCTL is applied when the socket is constructed. Thanks for sending us back for another look, Kirk From sean.coffey at oracle.com Fri Oct 3 12:38:24 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 03 Oct 2014 13:38:24 +0100 Subject: RFR : 8046588 8047187 Message-ID: <542E98C0.5030800@oracle.com> Following bugs need to be backported to jdk7u-dev to correct issues where SO_FLOW_SLA availability might not be available or where sufficient permissions are not in place. https://jbs.oracle.com/bugs/browse/JDK-8046588 https://jbs.oracle.com/bugs/browse/JDK-8047187 Testcase changes keep to the same theme as the JDK 8u fix but are in non-lambda format. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8046588.8047187.7u/webrev/ Re-tested on a solaris box with SO_FLOW_SLA enabled and all was green. JPRT results are green also. regards, Sean. From chris.hegarty at oracle.com Fri Oct 3 15:13:36 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 3 Oct 2014 16:13:36 +0100 Subject: RFR : 8046588 8047187 In-Reply-To: <542E98C0.5030800@oracle.com> References: <542E98C0.5030800@oracle.com> Message-ID: <79771519-62E7-47E4-9B6E-1D566BC89370@oracle.com> Looks good to me Sean. -Chris. On 3 Oct 2014, at 13:38, Se?n Coffey wrote: > Following bugs need to be backported to jdk7u-dev to correct issues where SO_FLOW_SLA availability might not be available or where sufficient permissions are not in place. > > https://jbs.oracle.com/bugs/browse/JDK-8046588 > https://jbs.oracle.com/bugs/browse/JDK-8047187 > > Testcase changes keep to the same theme as the JDK 8u fix but are in non-lambda format. > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8046588.8047187.7u/webrev/ > > Re-tested on a solaris box with SO_FLOW_SLA enabled and all was green. JPRT results are green also. > > regards, > Sean. From Alan.Bateman at oracle.com Tue Oct 7 14:41:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Oct 2014 07:41:22 -0700 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <5433FB92.3030603@oracle.com> On 02/10/2014 11:17, Kirk Shoop (MS OPEN TECH) wrote: > : > > We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. > > https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141002.zip > > GetVersionEx is not used and the IOCTL is applied when the socket is constructed. > > Thanks for sending us back for another look, > This looks much better and I can sponsor this. One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Tue Oct 7 15:15:59 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Tue, 7 Oct 2014 15:15:59 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <5433FB92.3030603@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> Message-ID: <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, October 7, 2014 7:41 AM This looks much better and I can sponsor this. Thank you :) One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Yes, we will change to the name to 'jdk.net.useFastTcpLoopback'. 'windows' was only in the name to declare the scope of the setting. Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". Yes, that makes sense. We will make this change. We will send a link to the new webrev once the changes are made and verified. Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Oct 8 16:59:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Oct 2014 18:59:27 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() Message-ID: Hi, I wonder why the implementations of Inet6AddressImpl_ getLocalHostName() and Inet4AddressImpl_getLocalHostName() are different . It seems to me that this is simply copy/paste error since the very first 1.4 version. Here's what we currently have: Inet4AddressImpl_getLocalHostName() if (gethostname(hostname, NI_MAXHOST)) { /* Something went wrong, maybe networking is not setup? */ strcpy(hostname, "localhost"); } else { ... error = getaddrinfo(hostname, NULL, &hints, &res); ... error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, ... } We first call gethostname(). If that succeeds we call getaddrinfo() with the host name returned by gethostname() and if that succeeds again we call getnameinfo() with the address returned by getaddrinfo() to get the final hostname. This is uniformly done on all Unix platforms. And here's how the corresponding IPv6 version looks like: Inet6AddressImpl_getLocalHostName() ret = gethostname(hostname, NI_MAXHOST); #if defined(__solaris__) && defined(AF_INET6) ... error = getaddrinfo(hostname, NULL, &hints, &res); ... error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, #endif As you can see, for the IPv6 version we only do the getaddrinfo()/getnameinfo() roundtrip on Solaris although there is no evidence that the inovolved system calls behave differently for IPv4 and IPv6. Instead I think the IPv6 version is just a leftover of the very first implementation which hasn't been updated in the same way like its IPv4 counterpart. Notice the comment in the IPv6 version which says "Solaris doesn't want to give us a fully qualified domain name". But that holds true for the Linux version as well - gethostname() on Linux returns "uname -n" which is usually unqualified. The comment further notices that even the reverse lookup may not return a fully qualified name which is true because that's highly system and name service dependent. I think we can therefore safely use the same implementation for both, Inet4AddressImpl_getLocalHostName() and Inet6AddressImpl_getLocalHostName(). We should actually refactor this implementation into its own function to avoid differences in the future. There's also a funny punchline in this whole story: trough a bug introduced by the Mac OS port, the two implementations have been semanticall equal for a while. But then this has been changed back as a fix for "7166687: InetAddress.getLocalHost().getHostName() returns FQDN " (https://bugs.openjdk.java.net/browse/JDK-7166687 , http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b26c04717735). But I'm pretty sure that change didn't really fixed the problem described in the bug report (maybe just incidentally worked around). Here's why: getLocalHostName() is used by InetAddress.getLocalHost(), but it's result (i.e. the host name) is immediately converted back into an address (i.e. InetAddress) on which subsequently getHostName() is called. The result of getHostName() only depends on the available name services and not on the fact if getLocalHostName() returned a simple or a fully qualified host name. However the resolution of a host name to an IP-address may be different depending on whether we have a simple (may resolve trough /etc/hosts) or fully qualified name (may resolve through name service like DNS). The hacky way to fix issue 7166687 would be to have the corresponding entries in your /etc/hosts (i.e. short names for both, IPv4 and IPv6 interfaces). The right way to handle it would be to actually expect both, simple and full qualified host names as return values from InetAddress.getHostName(). Notice the InetAddress.getLocalHost() isn't guaranteed to not return the loopback address. If you have configured your system such that /etc/hosts associates your host name with the loopback device and /etc/resolve.conf in such a way to first query /etc/hosts before doing a name service lookup (which is not unusual) than InetAddress.getLocalHost() will do just that - return the address of your loopback device! So to finally cut a long story short, I propose the following: - refactor the implementation of Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() into a single function which corresponds to the current Inet4AddressImpl_getLocalHostName() implementation. - it may be also possible to complete omit the call to getnameinfo() in that new implementation, because as far as I can see the 'ai_canonname' field of the first addrinfo structure returned by getaddrinfo() already contains the canonical name of the host if we pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). What do you think? Regards, Volker From ecki at zusammenkunft.net Wed Oct 8 21:01:41 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 8 Oct 2014 23:01:41 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: References: Message-ID: <20141008230141.00006475.ecki@zusammenkunft.net> Am Wed, 8 Oct 2014 18:59:27 +0200 schrieb Volker Simonis : > - it may be also possible to complete omit the call to getnameinfo() > in that new implementation, because as far as I can see the > 'ai_canonname' field of the first addrinfo structure returned by > getaddrinfo() already contains the canonical name of the host if we > pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). I completely agree. I mentioned this before. The flag can be removed or used, both would safe roundtrips: http://openjdk.5641.n7.nabble.com/RFC-compliant-address-selection-vs-home-made-getaddrinfo-td138848.html In the hostname utility (which I happen to maintain for Linux net-tools) gethostbyname() is used, btw. This does reduce the risk of stalls. https://sourceforge.net/p/net-tools/code/ci/master/tree/hostname.c#l146 But the whole hostname business is pretty much broken (unfortunatelly there is no way to repair that now). I think a function besides uts_name should have never been implemented. The is a host/node name and there are reverse resolved names for various addresses. Isnt really related. Especially not if a machine is multi-homed. Gruss Bernd From Kirk.Shoop at microsoft.com Thu Oct 9 17:10:24 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Thu, 9 Oct 2014 17:10:24 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Kirk Shoop (MS OPEN TECH) Sent: Tuesday, October 7, 2014 8:16 AM From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, October 7, 2014 7:41 AM One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Yes, we will change to the name to 'jdk.net.useFastTcpLoopback'. 'windows' was only in the name to declare the scope of the setting. Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". Yes, that makes sense. We will make this change. We will send a link to the new webrev once the changes are made and verified. ---- Here is the webrev with both changes: https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141008.zip Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Fri Oct 10 14:03:32 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Oct 2014 15:03:32 +0100 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: References: Message-ID: <5437E734.3010307@oracle.com> Hi Volker, I agree on the refactoring proposal. That would be a useful thing to do. On the second point. Removing getnameinfo() and using AI_CANONNAME in getaddrinfo() instead, would not be the exact equivalent however. getnameinfo() with AI_CANONNAME is taking the canonical host name as reported directly by the name service. Whereas the additional getnameinfo() is doing a reverse lookup of the forward looked up IP address. Having said that, I'm not sure I agree that step is really necessary. Before we change it, I'd like to check back through the history to see why exactly it was done and will report back. Thanks, Michael On 08/10/14 17:59, Volker Simonis wrote: > Hi, > > I wonder why the implementations of > Inet6AddressImpl_ > getLocalHostName() and > Inet4AddressImpl_getLocalHostName() are different . It seems to me > that this is simply copy/paste error since the very first 1.4 version. > Here's what we currently have: > > Inet4AddressImpl_getLocalHostName() > > if (gethostname(hostname, NI_MAXHOST)) { > /* Something went wrong, maybe networking is not setup? */ > strcpy(hostname, "localhost"); > } else { > ... > error = getaddrinfo(hostname, NULL, &hints, &res); > ... > error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, > ... > } > > We first call gethostname(). If that succeeds we call getaddrinfo() > with the host name returned by gethostname() and if that succeeds > again we call getnameinfo() with the address returned by getaddrinfo() > to get the final hostname. This is uniformly done on all Unix > platforms. > > And here's how the corresponding IPv6 version looks like: > > Inet6AddressImpl_getLocalHostName() > > ret = gethostname(hostname, NI_MAXHOST); > > #if defined(__solaris__) && defined(AF_INET6) > ... > error = getaddrinfo(hostname, NULL, &hints, &res); > ... > error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, > #endif > > As you can see, for the IPv6 version we only do the > getaddrinfo()/getnameinfo() roundtrip on Solaris although there is no > evidence that the inovolved system calls behave differently for IPv4 > and IPv6. Instead I think the IPv6 version is just a leftover of the > very first implementation which hasn't been updated in the same way > like its IPv4 counterpart. Notice the comment in the IPv6 version > which says "Solaris doesn't want to give us a fully qualified domain > name". But that holds true for the Linux version as well - > gethostname() on Linux returns "uname -n" which is usually > unqualified. The comment further notices that even the reverse lookup > may not return a fully qualified name which is true because that's > highly system and name service dependent. > > I think we can therefore safely use the same implementation for both, > Inet4AddressImpl_getLocalHostName() and > Inet6AddressImpl_getLocalHostName(). We should actually refactor this > implementation into its own function to avoid differences in the > future. > > There's also a funny punchline in this whole story: trough a bug > introduced by the Mac OS port, the two implementations have been > semanticall equal for a while. But then this has been changed back as > a fix for "7166687: InetAddress.getLocalHost().getHostName() returns > FQDN " (https://bugs.openjdk.java.net/browse/JDK-7166687 , > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b26c04717735). But I'm > pretty sure that change didn't really fixed the problem described in > the bug report (maybe just incidentally worked around). Here's why: > > getLocalHostName() is used by InetAddress.getLocalHost(), but it's > result (i.e. the host name) is immediately converted back into an > address (i.e. InetAddress) on which subsequently getHostName() is > called. The result of getHostName() only depends on the available > name services and not on the fact if getLocalHostName() returned a > simple or a fully qualified host name. However the resolution of a > host name to an IP-address may be different depending on whether we > have a simple (may resolve trough /etc/hosts) or fully qualified name > (may resolve through name service like DNS). > > The hacky way to fix issue 7166687 would be to have the corresponding > entries in your /etc/hosts (i.e. short names for both, IPv4 and IPv6 > interfaces). The right way to handle it would be to actually expect > both, simple and full qualified host names as return values from > InetAddress.getHostName(). > > Notice the InetAddress.getLocalHost() isn't guaranteed to not return > the loopback address. If you have configured your system such that > /etc/hosts associates your host name with the loopback device and > /etc/resolve.conf in such a way to first query /etc/hosts before doing > a name service lookup (which is not unusual) than > InetAddress.getLocalHost() will do just that - return the address of > your loopback device! > > So to finally cut a long story short, I propose the following: > > - refactor the implementation of Inet6AddressImpl_getLocalHostName() > and Inet4AddressImpl_getLocalHostName() into a single function which > corresponds to the current Inet4AddressImpl_getLocalHostName() > implementation. > > - it may be also possible to complete omit the call to getnameinfo() > in that new implementation, because as far as I can see the > 'ai_canonname' field of the first addrinfo structure returned by > getaddrinfo() already contains the canonical name of the host if we > pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). > > What do you think? > > Regards, > Volker From michael.x.mcmahon at oracle.com Fri Oct 10 15:17:16 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Oct 2014 16:17:16 +0100 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: <5437E734.3010307@oracle.com> References: <5437E734.3010307@oracle.com> Message-ID: <5437F87C.1070403@oracle.com> Actually, I think you are probably right that the comment about Solaris not returning a fqdn, is the reason why the reverse lookup was done and it is only doing the reverse lookup on Solaris and Linux (ipv4 only) The main concern I guess is just compatibility. There could be environments that depend on InetAddress.getLocalHost() returning a FQDN (eg Linux ipv4 only). Given that Windows and (by default) Linux don't do this, not many people would likely be affected. So, maybe we could disable it by default, but allow it to be switched on by system property, with the same implementation for all platforms. Michael On 10/10/14 15:03, Michael McMahon wrote: > Hi Volker, > > I agree on the refactoring proposal. That would be a useful thing to do. > On the second point. Removing getnameinfo() and using AI_CANONNAME in > getaddrinfo() instead, would not be the exact equivalent however. > > getnameinfo() with AI_CANONNAME is taking the canonical host name as > reported directly by the name service. Whereas the additional > getnameinfo() > is doing a reverse lookup of the forward looked up IP address. > > Having said that, I'm not sure I agree that step is really necessary. > Before > we change it, I'd like to check back through the history to see why > exactly > it was done and will report back. > > Thanks, > Michael > > On 08/10/14 17:59, Volker Simonis wrote: >> Hi, >> >> I wonder why the implementations of >> Inet6AddressImpl_ >> getLocalHostName() and >> Inet4AddressImpl_getLocalHostName() are different . It seems to me >> that this is simply copy/paste error since the very first 1.4 version. >> Here's what we currently have: >> >> Inet4AddressImpl_getLocalHostName() >> >> if (gethostname(hostname, NI_MAXHOST)) { >> /* Something went wrong, maybe networking is not setup? */ >> strcpy(hostname, "localhost"); >> } else { >> ... >> error = getaddrinfo(hostname, NULL, &hints, &res); >> ... >> error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, >> ... >> } >> >> We first call gethostname(). If that succeeds we call getaddrinfo() >> with the host name returned by gethostname() and if that succeeds >> again we call getnameinfo() with the address returned by getaddrinfo() >> to get the final hostname. This is uniformly done on all Unix >> platforms. >> >> And here's how the corresponding IPv6 version looks like: >> >> Inet6AddressImpl_getLocalHostName() >> >> ret = gethostname(hostname, NI_MAXHOST); >> >> #if defined(__solaris__) && defined(AF_INET6) >> ... >> error = getaddrinfo(hostname, NULL, &hints, &res); >> ... >> error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, >> #endif >> >> As you can see, for the IPv6 version we only do the >> getaddrinfo()/getnameinfo() roundtrip on Solaris although there is no >> evidence that the inovolved system calls behave differently for IPv4 >> and IPv6. Instead I think the IPv6 version is just a leftover of the >> very first implementation which hasn't been updated in the same way >> like its IPv4 counterpart. Notice the comment in the IPv6 version >> which says "Solaris doesn't want to give us a fully qualified domain >> name". But that holds true for the Linux version as well - >> gethostname() on Linux returns "uname -n" which is usually >> unqualified. The comment further notices that even the reverse lookup >> may not return a fully qualified name which is true because that's >> highly system and name service dependent. >> >> I think we can therefore safely use the same implementation for both, >> Inet4AddressImpl_getLocalHostName() and >> Inet6AddressImpl_getLocalHostName(). We should actually refactor this >> implementation into its own function to avoid differences in the >> future. >> >> There's also a funny punchline in this whole story: trough a bug >> introduced by the Mac OS port, the two implementations have been >> semanticall equal for a while. But then this has been changed back as >> a fix for "7166687: InetAddress.getLocalHost().getHostName() returns >> FQDN " (https://bugs.openjdk.java.net/browse/JDK-7166687 , >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b26c04717735). But I'm >> pretty sure that change didn't really fixed the problem described in >> the bug report (maybe just incidentally worked around). Here's why: >> >> getLocalHostName() is used by InetAddress.getLocalHost(), but it's >> result (i.e. the host name) is immediately converted back into an >> address (i.e. InetAddress) on which subsequently getHostName() is >> called. The result of getHostName() only depends on the available >> name services and not on the fact if getLocalHostName() returned a >> simple or a fully qualified host name. However the resolution of a >> host name to an IP-address may be different depending on whether we >> have a simple (may resolve trough /etc/hosts) or fully qualified name >> (may resolve through name service like DNS). >> >> The hacky way to fix issue 7166687 would be to have the corresponding >> entries in your /etc/hosts (i.e. short names for both, IPv4 and IPv6 >> interfaces). The right way to handle it would be to actually expect >> both, simple and full qualified host names as return values from >> InetAddress.getHostName(). >> >> Notice the InetAddress.getLocalHost() isn't guaranteed to not return >> the loopback address. If you have configured your system such that >> /etc/hosts associates your host name with the loopback device and >> /etc/resolve.conf in such a way to first query /etc/hosts before doing >> a name service lookup (which is not unusual) than >> InetAddress.getLocalHost() will do just that - return the address of >> your loopback device! >> >> So to finally cut a long story short, I propose the following: >> >> - refactor the implementation of Inet6AddressImpl_getLocalHostName() >> and Inet4AddressImpl_getLocalHostName() into a single function which >> corresponds to the current Inet4AddressImpl_getLocalHostName() >> implementation. >> >> - it may be also possible to complete omit the call to getnameinfo() >> in that new implementation, because as far as I can see the >> 'ai_canonname' field of the first addrinfo structure returned by >> getaddrinfo() already contains the canonical name of the host if we >> pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). >> >> What do you think? >> >> Regards, >> Volker > From volker.simonis at gmail.com Mon Oct 13 17:36:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Oct 2014 19:36:26 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: <5437F87C.1070403@oracle.com> References: <5437E734.3010307@oracle.com> <5437F87C.1070403@oracle.com> Message-ID: Hi Michael, thanks for your comments. Please find my answers inline: On Fri, Oct 10, 2014 at 5:17 PM, Michael McMahon wrote: > Actually, I think you are probably right that the comment > about Solaris not returning a fqdn, is the reason why the reverse lookup was > done > and it is only doing the reverse lookup on Solaris and Linux (ipv4 only) > > The main concern I guess is just compatibility. There could be environments > that > depend on InetAddress.getLocalHost() returning a FQDN (eg Linux ipv4 only). > But the problem is that Linux currently doesn't return a FQDN (see my first mail). And anyway, that doesn't depend on how many times we're doing a reverse lookup but instead it only depends on how you have configured /etc/hosts and /etc/nsswitch.conf. And notice, that we are doing the reverse lookup twice in the ipv4 case: once in Inet4AddressImpl_getLocalHostName() and a second time in InetAddress.getLocalHost() before we call getHostName() on the resulting address. That seems unnecessary. > Given that Windows and (by default) Linux don't do this, not many people > would > likely be affected. So, maybe we could disable it by default, but allow it > to be switched > on by system property, with the same implementation for all platforms. > Using a property to switch the behaviour would be fine for me. But in MHO I think we should use a simple and common version on all platforms and update the API documentation of InetAddress.getLocalHost() to make it clear that there's no guarantee that it returns neither a FQDN nor a simple name. I'll post a first webrev tomorrow. Regards, Volker > Michael > > > On 10/10/14 15:03, Michael McMahon wrote: >> >> Hi Volker, >> >> I agree on the refactoring proposal. That would be a useful thing to do. >> On the second point. Removing getnameinfo() and using AI_CANONNAME in >> getaddrinfo() instead, would not be the exact equivalent however. >> >> getnameinfo() with AI_CANONNAME is taking the canonical host name as >> reported directly by the name service. Whereas the additional >> getnameinfo() >> is doing a reverse lookup of the forward looked up IP address. >> >> Having said that, I'm not sure I agree that step is really necessary. >> Before >> we change it, I'd like to check back through the history to see why >> exactly >> it was done and will report back. >> >> Thanks, >> Michael >> >> On 08/10/14 17:59, Volker Simonis wrote: >>> >>> Hi, >>> >>> I wonder why the implementations of >>> Inet6AddressImpl_ >>> getLocalHostName() and >>> Inet4AddressImpl_getLocalHostName() are different . It seems to me >>> that this is simply copy/paste error since the very first 1.4 version. >>> Here's what we currently have: >>> >>> Inet4AddressImpl_getLocalHostName() >>> >>> if (gethostname(hostname, NI_MAXHOST)) { >>> /* Something went wrong, maybe networking is not setup? */ >>> strcpy(hostname, "localhost"); >>> } else { >>> ... >>> error = getaddrinfo(hostname, NULL, &hints, &res); >>> ... >>> error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, >>> ... >>> } >>> >>> We first call gethostname(). If that succeeds we call getaddrinfo() >>> with the host name returned by gethostname() and if that succeeds >>> again we call getnameinfo() with the address returned by getaddrinfo() >>> to get the final hostname. This is uniformly done on all Unix >>> platforms. >>> >>> And here's how the corresponding IPv6 version looks like: >>> >>> Inet6AddressImpl_getLocalHostName() >>> >>> ret = gethostname(hostname, NI_MAXHOST); >>> >>> #if defined(__solaris__) && defined(AF_INET6) >>> ... >>> error = getaddrinfo(hostname, NULL, &hints, &res); >>> ... >>> error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, >>> #endif >>> >>> As you can see, for the IPv6 version we only do the >>> getaddrinfo()/getnameinfo() roundtrip on Solaris although there is no >>> evidence that the inovolved system calls behave differently for IPv4 >>> and IPv6. Instead I think the IPv6 version is just a leftover of the >>> very first implementation which hasn't been updated in the same way >>> like its IPv4 counterpart. Notice the comment in the IPv6 version >>> which says "Solaris doesn't want to give us a fully qualified domain >>> name". But that holds true for the Linux version as well - >>> gethostname() on Linux returns "uname -n" which is usually >>> unqualified. The comment further notices that even the reverse lookup >>> may not return a fully qualified name which is true because that's >>> highly system and name service dependent. >>> >>> I think we can therefore safely use the same implementation for both, >>> Inet4AddressImpl_getLocalHostName() and >>> Inet6AddressImpl_getLocalHostName(). We should actually refactor this >>> implementation into its own function to avoid differences in the >>> future. >>> >>> There's also a funny punchline in this whole story: trough a bug >>> introduced by the Mac OS port, the two implementations have been >>> semanticall equal for a while. But then this has been changed back as >>> a fix for "7166687: InetAddress.getLocalHost().getHostName() returns >>> FQDN " (https://bugs.openjdk.java.net/browse/JDK-7166687 , >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b26c04717735). But I'm >>> pretty sure that change didn't really fixed the problem described in >>> the bug report (maybe just incidentally worked around). Here's why: >>> >>> getLocalHostName() is used by InetAddress.getLocalHost(), but it's >>> result (i.e. the host name) is immediately converted back into an >>> address (i.e. InetAddress) on which subsequently getHostName() is >>> called. The result of getHostName() only depends on the available >>> name services and not on the fact if getLocalHostName() returned a >>> simple or a fully qualified host name. However the resolution of a >>> host name to an IP-address may be different depending on whether we >>> have a simple (may resolve trough /etc/hosts) or fully qualified name >>> (may resolve through name service like DNS). >>> >>> The hacky way to fix issue 7166687 would be to have the corresponding >>> entries in your /etc/hosts (i.e. short names for both, IPv4 and IPv6 >>> interfaces). The right way to handle it would be to actually expect >>> both, simple and full qualified host names as return values from >>> InetAddress.getHostName(). >>> >>> Notice the InetAddress.getLocalHost() isn't guaranteed to not return >>> the loopback address. If you have configured your system such that >>> /etc/hosts associates your host name with the loopback device and >>> /etc/resolve.conf in such a way to first query /etc/hosts before doing >>> a name service lookup (which is not unusual) than >>> InetAddress.getLocalHost() will do just that - return the address of >>> your loopback device! >>> >>> So to finally cut a long story short, I propose the following: >>> >>> - refactor the implementation of Inet6AddressImpl_getLocalHostName() >>> and Inet4AddressImpl_getLocalHostName() into a single function which >>> corresponds to the current Inet4AddressImpl_getLocalHostName() >>> implementation. >>> >>> - it may be also possible to complete omit the call to getnameinfo() >>> in that new implementation, because as far as I can see the >>> 'ai_canonname' field of the first addrinfo structure returned by >>> getaddrinfo() already contains the canonical name of the host if we >>> pass AI_CANONNAME as 'hints' to getaddrinfo (which we already do). >>> >>> What do you think? >>> >>> Regards, >>> Volker >> >> > From michael.x.mcmahon at oracle.com Wed Oct 15 11:03:36 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 15 Oct 2014 12:03:36 +0100 Subject: RFR 8042622: Check for CRL results in IllegalArgumentException "white space not allowed" Message-ID: <543E5488.9040807@oracle.com> http://cr.openjdk.java.net/~michaelm/8042622/webrev.1/ The issue is that ResponseCache is receiving all the headers from our MessageHeader internal implementation class. This includes a dummy/fake header that represents the request line of a request (eg GET /foo.html HTTP/1.1) and this is causing problems later on for the URLPermission class because the fake header name has a space in it. The fix is simply to only include user set headers (which are already maintained in a separate MessageHeaders instance) when calling into the ResponseCache object. Strictly speaking, a minimal fix here would just remove the dummy header, but I think it makes more sense to only include genuine "user set" headers, rather than system set ones. Thanks Michael From chris.hegarty at oracle.com Wed Oct 15 15:12:02 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Oct 2014 16:12:02 +0100 Subject: RFR 8042622: Check for CRL results in IllegalArgumentException "white space not allowed" In-Reply-To: <543E5488.9040807@oracle.com> References: <543E5488.9040807@oracle.com> Message-ID: <543E8EC2.80208@oracle.com> This looks ok to me. -Chris. On 15/10/14 12:03, Michael McMahon wrote: > http://cr.openjdk.java.net/~michaelm/8042622/webrev.1/ > > The issue is that ResponseCache is receiving all the headers from our > MessageHeader internal implementation class. This includes > a dummy/fake header that represents the request line of a request > (eg GET /foo.html HTTP/1.1) and this is causing problems later > on for the URLPermission class because the fake header name has a space > in it. > > The fix is simply to only include user set headers (which are already > maintained in a separate MessageHeaders instance) when calling > into the ResponseCache object. Strictly speaking, a minimal fix here > would just remove the dummy header, but I think it makes more sense > to only include genuine "user set" headers, rather than system set ones. > > Thanks > Michael > From Alan.Bateman at oracle.com Wed Oct 15 18:42:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 19:42:33 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <543EC019.80404@oracle.com> On 09/10/2014 18:10, Kirk Shoop (MS OPEN TECH) wrote: > > ---- > > Here is the webrev with both changes: > I've tweaked your patch a ting bit on a few minor issues. One is so that running with -Djdk.net.useTcpFastLoopback enables the setting. Another one is to just rename from fast_loopback to fastLoopback in a few places to keep it consistent. I also add a new @run tag to one of the loopback stress tests so that it runs the test with this option enabled. I've put a webrev here: http://cr.openjdk.java.net/~alanb/8060170/webrev/ At some point you might want to extend this to work with classic networking. If you are okay with this then I will push it to the jdk9/dev forest listing you as the author. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Oct 16 14:39:21 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Oct 2014 16:39:21 +0200 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() Message-ID: Hi, could you please hava a look at the following change: http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 https://bugs.openjdk.java.net/browse/JDK-8060470 It's probably easier to read the following in the webrev, but I copy it below for discussion. Regards, Volker So here comes the first version of this change. Its main focus is the unification and simplification of Inet{4,6}AddressImpl_getLocalHostName() (notice that these native methods are currently only called from InetAddress.getLocalHost() so the impact is manageable): - Simplification: the current implementation has three versions of this function: two versions of Inet4AddressImpl_getLocalHostName() (one for "_ALLBSD_SOURCE && !HAS_GLIBC_GETHOSTBY_R" and another one for the other Unix versions) and one version of Inet6AddressImpl_getLocalHostName(). All these functions are very similar and can be easily factored out into one new method. - Unification: there are subtle and probably unnecessary differences between the IPv4 and IPv6 version of these methods which can be easily eliminated. The only difference between the two IPv4 versions was the ai_family flag passed as hint to the getaddrinfo() call. The Mac version used AF_UNSPEC while the general Unix version used AF_INET. I don't see a reason (and my tests didn't show any problems) why we couldn't use AF_INET on MacOS as well. The IPv6 version used AF_UNSPEC as well. The new refactored method getLocalHostName() which is now called from both, the single instance of Inet4AddressImpl_getLocalHostName() and Inet6AddressImpl_getLocalHostName() uses AF_INET in the IPv4 case (which shouldn't change anything) and AF_INET6 for the IPv6 case. Additionally, it uses the flag AI_V4MAPPED in the IPv6 case. This will return an IPv4-mapped IPv6 addresses if no matching IPv6 addresses could be found. The last difference between the old IPv4 and IPv6 versions was the fact that the IPv4 versions always did a reverse lookup for the host name. That means that after querying the hostname with gethostname(), they used a call to getaddrinfo() to get the IP address of the host name and finally they called getnameinfo() on that IP address to get the host name once again. The IPv6 version only did this reverse lookup on Solaris. It is unclear why this reverse lookup was necessary at all. Especially if we take into account that the resulting host name will be only used in InetAddress.getLocalHost() where it will finally serve as input to InetAddressImpl.lookupAllHostAddr() which will in turn do exactly the same reverse lookup procedure (at least if the default name service is used). Therefore the new implementation switches this reverse lookup off by default unless the user requests it with the two system properties java.net.doIPv4ReverseLookupInGetLocalHost and java.net.doIPv6ReverseLookupInGetLocalHost for IPv4 and IPv6 respectively. Consequently, the new Unix version of Java_java_net_Inet{4,6}AddressImpl_getLocalHostName is now equal to its Windows counterpart which simply returns the result of gethostname() as well. Notice that for these properties, the name "IPv4" and "IPv6" refer to the actual InetAddressImpl version (i.e. either Inet4AddressImpl or Inet6AddressImpl) that is used by InetAddress. On most modern hosts, InetAddress will use an Inet6AddressImpl helper if the host is IPv6 "capable". That doesn't necessarily mean that InetAddress.getLocalHost() will return an IPv6 address or even that there's a network interface with an IPv6 address - it just means that the network stack can handle IPv6. InetAddress can be forced to use the Inet4AddressImpl helper by setting the java.net.preferIPv4Stack property to false. In the new implementation both properties java.net.doIPv4ReverseLookupInGetLocalHost and java.net.doIPv6ReverseLookupInGetLocalHost are set to false by default. But the old behavior could be restored by setting java.net.doIPv4ReverseLookupInGetLocalHost=true and java.net.doIPv6ReverseLookupInGetLocalHost=true (Solaris only). In a previous mail thread [2] we discussed the possibility of replacing the call to getnameinfo() in Inet{4,6}AddressImpl_getLocalHostName() by simply using the ai_canonname field returned by the getaddrinfo() call. But because I think the reverse lookup is unnecessary anyway (and disabled by default in the new implementation), I didn't tried that any more and stayed with the old version. I've built these changes on Linux, Solaris, MacOS X and AIX and manually tested them on various hosts with different IPv4/IPv6 setups without any problems. In cases where the output of InetAddress.getLocalHost() differed in the new version this was only a difference in the hostname part of the InetAddress (i.e. fully qualified name vs. simple name) and this could be easily restored with the help of the new system properties. Notice that for the new version the host name now usually corresponds to what the hostname command returns on Unix which is probably what most people would expect. In the old version the host name was more dependent on the local system configuration (i.e. /etc/hosts or /etc/nsswitch.conf) as discussed in [2]. The following mail threads already discuss this issue: [1] http://mail.openjdk.java.net/pipermail/net-dev/2014-October/thread.html#8721 [2] http://mail.openjdk.java.net/pipermail/net-dev/2013-June/thread.html#6543 PS: We probably shouldn't discuss this too long as there are other methods like Java_java_net_Inet{4,6}AddressImpl_lookupAllHostAddr which are waiting for unification and simplification as well :) From ecki at zusammenkunft.net Fri Oct 17 00:31:57 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 17 Oct 2014 02:31:57 +0200 Subject: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName() In-Reply-To: <5437E734.3010307@oracle.com> References: <5437E734.3010307@oracle.com> Message-ID: <20141017023157.0000021a.ecki@zusammenkunft.net> Am Fri, 10 Oct 2014 15:03:32 +0100 schrieb Michael McMahon : > getnameinfo() with AI_CANONNAME is taking the canonical host name as > reported directly by the name service. Whereas the additional > getnameinfo() is doing a reverse lookup of the forward looked up IP > address. getaddrinfo() with AI_CANONNAME returns the result in res[0].ai_canonname which is not used in http://code.metager.de/source/xref/openjdk/jdk8/jdk/src/solaris/native/java/net/Inet4AddressImpl.c#111 (and other places) Gruss Bernd From Kirk.Shoop at microsoft.com Fri Oct 17 17:34:16 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Fri, 17 Oct 2014 17:34:16 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <543EC019.80404@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> Message-ID: <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] I've tweaked your patch a ting bit on a few minor issues. One is so that running with -Djdk.net.useTcpFastLoopback enables the setting. Another one is to just rename from fast_loopback to fastLoopback in a few places to keep it consistent. I also add a new @run tag to one of the loopback stress tests so that it runs the test with this option enabled. The changes look good, thanks for adding the test. At some point you might want to extend this to work with classic networking. Yes, that would be a good step. We will put it on the list. If you are okay with this then I will push it to the jdk9/dev forest listing you as the author. Valery and I both worked on this, but if only one author can be listed then use my name. Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Oct 19 12:40:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Oct 2014 13:40:02 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <5443B122.5020500@oracle.com> On 17/10/2014 18:34, Kirk Shoop (MS OPEN TECH) wrote: > > > If you are okay with this then I will push it to the jdk9/dev forest > listing you as the author. > > Valery and I both worked on this, but if only one author can be listed > then use my name. > > The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcins at microsoft.com Mon Oct 20 19:01:33 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Mon, 20 Oct 2014 19:01:33 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <5443B122.5020500@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> <5443B122.5020500@oracle.com> Message-ID: <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 Alan, thank you for your help with this. How would we go about getting this back-ported to v8 and v7? Best regards Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Oct 20 20:10:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Oct 2014 21:10:38 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> <5443B122.5020500@oracle.com> <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> Message-ID: On 20 Oct 2014, at 20:01, Martin Sawicki (MS OPEN TECH) wrote: > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 > > > Alan, thank you for your help with this. How would we go about getting this back-ported to v8 and v7? A good place to start, take a quick look at the 8 Updates project. http://openjdk.java.net/projects/jdk8u/ -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Oct 24 14:47:17 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Oct 2014 16:47:17 +0200 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: References: Message-ID: Hi, could somebody please have a quick look at this change. It's really not that complicated as it looks like from the comments - I just didn't manage to write it up in a more concise way :) Thanks, Volker On Thu, Oct 16, 2014 at 4:39 PM, Volker Simonis wrote: > Hi, > > could you please hava a look at the following change: > > http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 > https://bugs.openjdk.java.net/browse/JDK-8060470 > > It's probably easier to read the following in the webrev, but I copy > it below for discussion. > > Regards, > Volker > > So here comes the first version of this change. Its main focus is the > unification and simplification of > Inet{4,6}AddressImpl_getLocalHostName() (notice that these native > methods are currently only called from InetAddress.getLocalHost() so > the impact is manageable): > > - Simplification: the current implementation has three versions of > this function: two versions of Inet4AddressImpl_getLocalHostName() > (one for "_ALLBSD_SOURCE && !HAS_GLIBC_GETHOSTBY_R" and another one > for the other Unix versions) and one version of > Inet6AddressImpl_getLocalHostName(). All these functions are very > similar and can be easily factored out into one new method. > - Unification: there are subtle and probably unnecessary differences > between the IPv4 and IPv6 version of these methods which can be easily > eliminated. > > The only difference between the two IPv4 versions was the ai_family > flag passed as hint to the getaddrinfo() call. The Mac version used > AF_UNSPEC while the general Unix version used AF_INET. I don't see a > reason (and my tests didn't show any problems) why we couldn't use > AF_INET on MacOS as well. > > The IPv6 version used AF_UNSPEC as well. The new refactored method > getLocalHostName() which is now called from both, the single instance > of Inet4AddressImpl_getLocalHostName() and > Inet6AddressImpl_getLocalHostName() uses AF_INET in the IPv4 case > (which shouldn't change anything) and AF_INET6 for the IPv6 case. > Additionally, it uses the flag AI_V4MAPPED in the IPv6 case. This will > return an IPv4-mapped IPv6 addresses if no matching IPv6 addresses > could be found. > > The last difference between the old IPv4 and IPv6 versions was the > fact that the IPv4 versions always did a reverse lookup for the host > name. That means that after querying the hostname with gethostname(), > they used a call to getaddrinfo() to get the IP address of the host > name and finally they called getnameinfo() on that IP address to get > the host name once again. The IPv6 version only did this reverse > lookup on Solaris. > > It is unclear why this reverse lookup was necessary at all. Especially > if we take into account that the resulting host name will be only used > in InetAddress.getLocalHost() where it will finally serve as input to > InetAddressImpl.lookupAllHostAddr() which will in turn do exactly the > same reverse lookup procedure (at least if the default name service is > used). Therefore the new implementation switches this reverse lookup > off by default unless the user requests it with the two system > properties java.net.doIPv4ReverseLookupInGetLocalHost and > java.net.doIPv6ReverseLookupInGetLocalHost for IPv4 and IPv6 > respectively. Consequently, the new Unix version of > Java_java_net_Inet{4,6}AddressImpl_getLocalHostName is now equal to > its Windows counterpart which simply returns the result of > gethostname() as well. > > Notice that for these properties, the name "IPv4" and "IPv6" refer to > the actual InetAddressImpl version (i.e. either Inet4AddressImpl or > Inet6AddressImpl) that is used by InetAddress. On most modern hosts, > InetAddress will use an Inet6AddressImpl helper if the host is IPv6 > "capable". That doesn't necessarily mean that > InetAddress.getLocalHost() will return an IPv6 address or even that > there's a network interface with an IPv6 address - it just means that > the network stack can handle IPv6. InetAddress can be forced to use > the Inet4AddressImpl helper by setting the java.net.preferIPv4Stack > property to false. > > In the new implementation both properties > java.net.doIPv4ReverseLookupInGetLocalHost and > java.net.doIPv6ReverseLookupInGetLocalHost are set to false by > default. But the old behavior could be restored by setting > java.net.doIPv4ReverseLookupInGetLocalHost=true and > java.net.doIPv6ReverseLookupInGetLocalHost=true (Solaris only). > > In a previous mail thread [2] we discussed the possibility of > replacing the call to getnameinfo() in > Inet{4,6}AddressImpl_getLocalHostName() by simply using the > ai_canonname field returned by the getaddrinfo() call. But because I > think the reverse lookup is unnecessary anyway (and disabled by > default in the new implementation), I didn't tried that any more and > stayed with the old version. > > I've built these changes on Linux, Solaris, MacOS X and AIX and > manually tested them on various hosts with different IPv4/IPv6 setups > without any problems. In cases where the output of > InetAddress.getLocalHost() differed in the new version this was only a > difference in the hostname part of the InetAddress (i.e. fully > qualified name vs. simple name) and this could be easily restored with > the help of the new system properties. Notice that for the new version > the host name now usually corresponds to what the hostname command > returns on Unix which is probably what most people would expect. In > the old version the host name was more dependent on the local system > configuration (i.e. /etc/hosts or /etc/nsswitch.conf) as discussed in > [2]. > > The following mail threads already discuss this issue: > > [1] http://mail.openjdk.java.net/pipermail/net-dev/2014-October/thread.html#8721 > [2] http://mail.openjdk.java.net/pipermail/net-dev/2013-June/thread.html#6543 > > PS: We probably shouldn't discuss this too long as there are other > methods like Java_java_net_Inet{4,6}AddressImpl_lookupAllHostAddr > which are waiting for unification and simplification as well :) From ivan.gerasimov at oracle.com Fri Oct 24 17:07:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 24 Oct 2014 21:07:12 +0400 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: References: Message-ID: <544A8740.9040905@oracle.com> Hi Volker! I'm not a Reviewer, but have a couple of minor comments. In the C source files you changed the indentation to two spaces. It looks inconsistent with other JDK sources. I know that in hotspot they use two space indentation, but it's a different set of sources. Inet4AddressImpl.c: 110 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, ia_doIPv4ReverseLookup); Since doIPv4ReverseLookup never changes, wouldn't it make sense to declare jboolean reverseLookup static? This way it would be retrieved only once. The same in Inet6AddressImpl.c: 66 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, ia_doIPv6ReverseLookup); And a static value retrieved here: 68 if ((*env)->GetStaticBooleanField(env, ia_class, ia_preferIPv6AddressID)) { Sincerely yours, Ivan On 24.10.2014 18:47, Volker Simonis wrote: > Hi, > > could somebody please have a quick look at this change. > It's really not that complicated as it looks like from the comments - > I just didn't manage to write it up in a more concise way :) > > Thanks, > Volker > > > On Thu, Oct 16, 2014 at 4:39 PM, Volker Simonis > wrote: >> Hi, >> >> could you please hava a look at the following change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 >> https://bugs.openjdk.java.net/browse/JDK-8060470 >> >> It's probably easier to read the following in the webrev, but I copy >> it below for discussion. >> >> Regards, >> Volker >> >> So here comes the first version of this change. Its main focus is the >> unification and simplification of >> Inet{4,6}AddressImpl_getLocalHostName() (notice that these native >> methods are currently only called from InetAddress.getLocalHost() so >> the impact is manageable): >> >> - Simplification: the current implementation has three versions of >> this function: two versions of Inet4AddressImpl_getLocalHostName() >> (one for "_ALLBSD_SOURCE && !HAS_GLIBC_GETHOSTBY_R" and another one >> for the other Unix versions) and one version of >> Inet6AddressImpl_getLocalHostName(). All these functions are very >> similar and can be easily factored out into one new method. >> - Unification: there are subtle and probably unnecessary differences >> between the IPv4 and IPv6 version of these methods which can be easily >> eliminated. >> >> The only difference between the two IPv4 versions was the ai_family >> flag passed as hint to the getaddrinfo() call. The Mac version used >> AF_UNSPEC while the general Unix version used AF_INET. I don't see a >> reason (and my tests didn't show any problems) why we couldn't use >> AF_INET on MacOS as well. >> >> The IPv6 version used AF_UNSPEC as well. The new refactored method >> getLocalHostName() which is now called from both, the single instance >> of Inet4AddressImpl_getLocalHostName() and >> Inet6AddressImpl_getLocalHostName() uses AF_INET in the IPv4 case >> (which shouldn't change anything) and AF_INET6 for the IPv6 case. >> Additionally, it uses the flag AI_V4MAPPED in the IPv6 case. This will >> return an IPv4-mapped IPv6 addresses if no matching IPv6 addresses >> could be found. >> >> The last difference between the old IPv4 and IPv6 versions was the >> fact that the IPv4 versions always did a reverse lookup for the host >> name. That means that after querying the hostname with gethostname(), >> they used a call to getaddrinfo() to get the IP address of the host >> name and finally they called getnameinfo() on that IP address to get >> the host name once again. The IPv6 version only did this reverse >> lookup on Solaris. >> >> It is unclear why this reverse lookup was necessary at all. Especially >> if we take into account that the resulting host name will be only used >> in InetAddress.getLocalHost() where it will finally serve as input to >> InetAddressImpl.lookupAllHostAddr() which will in turn do exactly the >> same reverse lookup procedure (at least if the default name service is >> used). Therefore the new implementation switches this reverse lookup >> off by default unless the user requests it with the two system >> properties java.net.doIPv4ReverseLookupInGetLocalHost and >> java.net.doIPv6ReverseLookupInGetLocalHost for IPv4 and IPv6 >> respectively. Consequently, the new Unix version of >> Java_java_net_Inet{4,6}AddressImpl_getLocalHostName is now equal to >> its Windows counterpart which simply returns the result of >> gethostname() as well. >> >> Notice that for these properties, the name "IPv4" and "IPv6" refer to >> the actual InetAddressImpl version (i.e. either Inet4AddressImpl or >> Inet6AddressImpl) that is used by InetAddress. On most modern hosts, >> InetAddress will use an Inet6AddressImpl helper if the host is IPv6 >> "capable". That doesn't necessarily mean that >> InetAddress.getLocalHost() will return an IPv6 address or even that >> there's a network interface with an IPv6 address - it just means that >> the network stack can handle IPv6. InetAddress can be forced to use >> the Inet4AddressImpl helper by setting the java.net.preferIPv4Stack >> property to false. >> >> In the new implementation both properties >> java.net.doIPv4ReverseLookupInGetLocalHost and >> java.net.doIPv6ReverseLookupInGetLocalHost are set to false by >> default. But the old behavior could be restored by setting >> java.net.doIPv4ReverseLookupInGetLocalHost=true and >> java.net.doIPv6ReverseLookupInGetLocalHost=true (Solaris only). >> >> In a previous mail thread [2] we discussed the possibility of >> replacing the call to getnameinfo() in >> Inet{4,6}AddressImpl_getLocalHostName() by simply using the >> ai_canonname field returned by the getaddrinfo() call. But because I >> think the reverse lookup is unnecessary anyway (and disabled by >> default in the new implementation), I didn't tried that any more and >> stayed with the old version. >> >> I've built these changes on Linux, Solaris, MacOS X and AIX and >> manually tested them on various hosts with different IPv4/IPv6 setups >> without any problems. In cases where the output of >> InetAddress.getLocalHost() differed in the new version this was only a >> difference in the hostname part of the InetAddress (i.e. fully >> qualified name vs. simple name) and this could be easily restored with >> the help of the new system properties. Notice that for the new version >> the host name now usually corresponds to what the hostname command >> returns on Unix which is probably what most people would expect. In >> the old version the host name was more dependent on the local system >> configuration (i.e. /etc/hosts or /etc/nsswitch.conf) as discussed in >> [2]. >> >> The following mail threads already discuss this issue: >> >> [1] http://mail.openjdk.java.net/pipermail/net-dev/2014-October/thread.html#8721 >> [2] http://mail.openjdk.java.net/pipermail/net-dev/2013-June/thread.html#6543 >> >> PS: We probably shouldn't discuss this too long as there are other >> methods like Java_java_net_Inet{4,6}AddressImpl_lookupAllHostAddr >> which are waiting for unification and simplification as well :) > From volker.simonis at gmail.com Mon Oct 27 17:45:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Oct 2014 18:45:10 +0100 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: <544A8740.9040905@oracle.com> References: <544A8740.9040905@oracle.com> Message-ID: On Fri, Oct 24, 2014 at 7:07 PM, Ivan Gerasimov wrote: > Hi Volker! > > I'm not a Reviewer, but have a couple of minor comments. > > In the C source files you changed the indentation to two spaces. > It looks inconsistent with other JDK sources. > I know that in hotspot they use two space indentation, but it's a different > set of sources. > Well, the problem is that already that very file contains code in both code conventions (see for example the implementations of 'ping4()' and 'Java_java_net_Inet4AddressImpl_isReachable0()' in Inet4AddressImpl.c which are mostly indented by two spaces). I have no problems to adhere to any convention as long as it is generally obeyed. As this does not seemed to be the case in these files, I've just chosen what I thought is most appropriate. So to keep a long story short - I can either: 1. indent my changes to four spaces (which will still let the files with mixed indentation) 2. change all indentation in the file to two spaces 3. change all indentation in the file to four spaces Please just tell me what you'd prefer. > > Inet4AddressImpl.c: > 110 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, > ia_doIPv4ReverseLookup); > > Since doIPv4ReverseLookup never changes, wouldn't it make sense to declare > jboolean reverseLookup static? > This way it would be retrieved only once. > > The same in Inet6AddressImpl.c: > 66 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, > ia_doIPv6ReverseLookup); > > And a static value retrieved here: > 68 if ((*env)->GetStaticBooleanField(env, ia_class, > ia_preferIPv6AddressID)) { > I think simply declaring the mentioned variables static is not possible in "C" and this is a "C" file compiled with a "C" compiler. You would get a "initializer element is not constant" error (see for example http://stackoverflow.com/questions/5921920/difference-between-initialization-of-static-variables-in-c-and-c). I could of course use a second static varibale to do the initialization only once, but I think that's not worth it. Thanks, Volker > Sincerely yours, > Ivan > > > On 24.10.2014 18:47, Volker Simonis wrote: >> >> Hi, >> >> could somebody please have a quick look at this change. >> It's really not that complicated as it looks like from the comments - >> I just didn't manage to write it up in a more concise way :) >> >> Thanks, >> Volker >> >> >> On Thu, Oct 16, 2014 at 4:39 PM, Volker Simonis >> wrote: >>> >>> Hi, >>> >>> could you please hava a look at the following change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 >>> https://bugs.openjdk.java.net/browse/JDK-8060470 >>> >>> It's probably easier to read the following in the webrev, but I copy >>> it below for discussion. >>> >>> Regards, >>> Volker >>> >>> So here comes the first version of this change. Its main focus is the >>> unification and simplification of >>> Inet{4,6}AddressImpl_getLocalHostName() (notice that these native >>> methods are currently only called from InetAddress.getLocalHost() so >>> the impact is manageable): >>> >>> - Simplification: the current implementation has three versions of >>> this function: two versions of Inet4AddressImpl_getLocalHostName() >>> (one for "_ALLBSD_SOURCE && !HAS_GLIBC_GETHOSTBY_R" and another one >>> for the other Unix versions) and one version of >>> Inet6AddressImpl_getLocalHostName(). All these functions are very >>> similar and can be easily factored out into one new method. >>> - Unification: there are subtle and probably unnecessary differences >>> between the IPv4 and IPv6 version of these methods which can be easily >>> eliminated. >>> >>> The only difference between the two IPv4 versions was the ai_family >>> flag passed as hint to the getaddrinfo() call. The Mac version used >>> AF_UNSPEC while the general Unix version used AF_INET. I don't see a >>> reason (and my tests didn't show any problems) why we couldn't use >>> AF_INET on MacOS as well. >>> >>> The IPv6 version used AF_UNSPEC as well. The new refactored method >>> getLocalHostName() which is now called from both, the single instance >>> of Inet4AddressImpl_getLocalHostName() and >>> Inet6AddressImpl_getLocalHostName() uses AF_INET in the IPv4 case >>> (which shouldn't change anything) and AF_INET6 for the IPv6 case. >>> Additionally, it uses the flag AI_V4MAPPED in the IPv6 case. This will >>> return an IPv4-mapped IPv6 addresses if no matching IPv6 addresses >>> could be found. >>> >>> The last difference between the old IPv4 and IPv6 versions was the >>> fact that the IPv4 versions always did a reverse lookup for the host >>> name. That means that after querying the hostname with gethostname(), >>> they used a call to getaddrinfo() to get the IP address of the host >>> name and finally they called getnameinfo() on that IP address to get >>> the host name once again. The IPv6 version only did this reverse >>> lookup on Solaris. >>> >>> It is unclear why this reverse lookup was necessary at all. Especially >>> if we take into account that the resulting host name will be only used >>> in InetAddress.getLocalHost() where it will finally serve as input to >>> InetAddressImpl.lookupAllHostAddr() which will in turn do exactly the >>> same reverse lookup procedure (at least if the default name service is >>> used). Therefore the new implementation switches this reverse lookup >>> off by default unless the user requests it with the two system >>> properties java.net.doIPv4ReverseLookupInGetLocalHost and >>> java.net.doIPv6ReverseLookupInGetLocalHost for IPv4 and IPv6 >>> respectively. Consequently, the new Unix version of >>> Java_java_net_Inet{4,6}AddressImpl_getLocalHostName is now equal to >>> its Windows counterpart which simply returns the result of >>> gethostname() as well. >>> >>> Notice that for these properties, the name "IPv4" and "IPv6" refer to >>> the actual InetAddressImpl version (i.e. either Inet4AddressImpl or >>> Inet6AddressImpl) that is used by InetAddress. On most modern hosts, >>> InetAddress will use an Inet6AddressImpl helper if the host is IPv6 >>> "capable". That doesn't necessarily mean that >>> InetAddress.getLocalHost() will return an IPv6 address or even that >>> there's a network interface with an IPv6 address - it just means that >>> the network stack can handle IPv6. InetAddress can be forced to use >>> the Inet4AddressImpl helper by setting the java.net.preferIPv4Stack >>> property to false. >>> >>> In the new implementation both properties >>> java.net.doIPv4ReverseLookupInGetLocalHost and >>> java.net.doIPv6ReverseLookupInGetLocalHost are set to false by >>> default. But the old behavior could be restored by setting >>> java.net.doIPv4ReverseLookupInGetLocalHost=true and >>> java.net.doIPv6ReverseLookupInGetLocalHost=true (Solaris only). >>> >>> In a previous mail thread [2] we discussed the possibility of >>> replacing the call to getnameinfo() in >>> Inet{4,6}AddressImpl_getLocalHostName() by simply using the >>> ai_canonname field returned by the getaddrinfo() call. But because I >>> think the reverse lookup is unnecessary anyway (and disabled by >>> default in the new implementation), I didn't tried that any more and >>> stayed with the old version. >>> >>> I've built these changes on Linux, Solaris, MacOS X and AIX and >>> manually tested them on various hosts with different IPv4/IPv6 setups >>> without any problems. In cases where the output of >>> InetAddress.getLocalHost() differed in the new version this was only a >>> difference in the hostname part of the InetAddress (i.e. fully >>> qualified name vs. simple name) and this could be easily restored with >>> the help of the new system properties. Notice that for the new version >>> the host name now usually corresponds to what the hostname command >>> returns on Unix which is probably what most people would expect. In >>> the old version the host name was more dependent on the local system >>> configuration (i.e. /etc/hosts or /etc/nsswitch.conf) as discussed in >>> [2]. >>> >>> The following mail threads already discuss this issue: >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/net-dev/2014-October/thread.html#8721 >>> [2] >>> http://mail.openjdk.java.net/pipermail/net-dev/2013-June/thread.html#6543 >>> >>> PS: We probably shouldn't discuss this too long as there are other >>> methods like Java_java_net_Inet{4,6}AddressImpl_lookupAllHostAddr >>> which are waiting for unification and simplification as well :) >> >> > From Alan.Bateman at oracle.com Mon Oct 27 18:27:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Oct 2014 18:27:02 +0000 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: References: <544A8740.9040905@oracle.com> Message-ID: <544E8E76.2060403@oracle.com> On 27/10/2014 17:45, Volker Simonis wrote: > : > Well, the problem is that already that very file contains code in both > code conventions (see for example the implementations of 'ping4()' > and 'Java_java_net_Inet4AddressImpl_isReachable0()' in > Inet4AddressImpl.c which are mostly indented by two spaces). I have no > problems to adhere to any convention as long as it is generally > obeyed. As this does not seemed to be the case in these files, I've > just chosen what I thought is most appropriate. So to keep a long > story short - I can either: > > 1. indent my changes to four spaces (which will still let the files > with mixed indentation) > 2. change all indentation in the file to two spaces > 3. change all indentation in the file to four spaces > > Please just tell me what you'd prefer. > We normally use 4 space indent in the library code. There are some inconsistencies, I don't know the fully history to understand how we got 2-space indent but if you can fix it up then that would be great. -Alan From ivan.gerasimov at oracle.com Mon Oct 27 19:14:51 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 27 Oct 2014 23:14:51 +0400 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: References: <544A8740.9040905@oracle.com> Message-ID: <544E99AB.4030501@oracle.com> On 27.10.2014 21:45, Volker Simonis wrote: > On Fri, Oct 24, 2014 at 7:07 PM, Ivan Gerasimov > wrote: >> Hi Volker! >> >> I'm not a Reviewer, but have a couple of minor comments. >> >> In the C source files you changed the indentation to two spaces. >> It looks inconsistent with other JDK sources. >> I know that in hotspot they use two space indentation, but it's a different >> set of sources. >> > Well, the problem is that already that very file contains code in both > code conventions (see for example the implementations of 'ping4()' > and 'Java_java_net_Inet4AddressImpl_isReachable0()' in > Inet4AddressImpl.c which are mostly indented by two spaces). I have no > problems to adhere to any convention as long as it is generally > obeyed. As this does not seemed to be the case in these files, I've > just chosen what I thought is most appropriate. So to keep a long > story short - I can either: > > 1. indent my changes to four spaces (which will still let the files > with mixed indentation) > 2. change all indentation in the file to two spaces > 3. change all indentation in the file to four spaces > > Please just tell me what you'd prefer. I think #1 it the most appropriate here. >> Inet4AddressImpl.c: >> 110 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, >> ia_doIPv4ReverseLookup); >> >> Since doIPv4ReverseLookup never changes, wouldn't it make sense to declare >> jboolean reverseLookup static? >> This way it would be retrieved only once. >> >> The same in Inet6AddressImpl.c: >> 66 jboolean reverseLookup = (*env)->GetStaticBooleanField(env, ia_class, >> ia_doIPv6ReverseLookup); >> >> And a static value retrieved here: >> 68 if ((*env)->GetStaticBooleanField(env, ia_class, >> ia_preferIPv6AddressID)) { >> > I think simply declaring the mentioned variables static is not > possible in "C" and this is a "C" file compiled with a "C" compiler. > You would get a "initializer element is not constant" error (see for > example http://stackoverflow.com/questions/5921920/difference-between-initialization-of-static-variables-in-c-and-c). > I could of course use a second static varibale to do the > initialization only once, but I think that's not worth it. Ah, yes, you're right. I missed the fact it's plain C, so a static variable must be initialized with a constant. > Thanks, > Volker > > >> Sincerely yours, >> Ivan >> >> >> On 24.10.2014 18:47, Volker Simonis wrote: >>> Hi, >>> >>> could somebody please have a quick look at this change. >>> It's really not that complicated as it looks like from the comments - >>> I just didn't manage to write it up in a more concise way :) >>> >>> Thanks, >>> Volker >>> >>> >>> On Thu, Oct 16, 2014 at 4:39 PM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> could you please hava a look at the following change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 >>>> https://bugs.openjdk.java.net/browse/JDK-8060470 >>>> >>>> It's probably easier to read the following in the webrev, but I copy >>>> it below for discussion. >>>> >>>> Regards, >>>> Volker >>>> >>>> So here comes the first version of this change. Its main focus is the >>>> unification and simplification of >>>> Inet{4,6}AddressImpl_getLocalHostName() (notice that these native >>>> methods are currently only called from InetAddress.getLocalHost() so >>>> the impact is manageable): >>>> >>>> - Simplification: the current implementation has three versions of >>>> this function: two versions of Inet4AddressImpl_getLocalHostName() >>>> (one for "_ALLBSD_SOURCE && !HAS_GLIBC_GETHOSTBY_R" and another one >>>> for the other Unix versions) and one version of >>>> Inet6AddressImpl_getLocalHostName(). All these functions are very >>>> similar and can be easily factored out into one new method. >>>> - Unification: there are subtle and probably unnecessary differences >>>> between the IPv4 and IPv6 version of these methods which can be easily >>>> eliminated. >>>> >>>> The only difference between the two IPv4 versions was the ai_family >>>> flag passed as hint to the getaddrinfo() call. The Mac version used >>>> AF_UNSPEC while the general Unix version used AF_INET. I don't see a >>>> reason (and my tests didn't show any problems) why we couldn't use >>>> AF_INET on MacOS as well. >>>> >>>> The IPv6 version used AF_UNSPEC as well. The new refactored method >>>> getLocalHostName() which is now called from both, the single instance >>>> of Inet4AddressImpl_getLocalHostName() and >>>> Inet6AddressImpl_getLocalHostName() uses AF_INET in the IPv4 case >>>> (which shouldn't change anything) and AF_INET6 for the IPv6 case. >>>> Additionally, it uses the flag AI_V4MAPPED in the IPv6 case. This will >>>> return an IPv4-mapped IPv6 addresses if no matching IPv6 addresses >>>> could be found. >>>> >>>> The last difference between the old IPv4 and IPv6 versions was the >>>> fact that the IPv4 versions always did a reverse lookup for the host >>>> name. That means that after querying the hostname with gethostname(), >>>> they used a call to getaddrinfo() to get the IP address of the host >>>> name and finally they called getnameinfo() on that IP address to get >>>> the host name once again. The IPv6 version only did this reverse >>>> lookup on Solaris. >>>> >>>> It is unclear why this reverse lookup was necessary at all. Especially >>>> if we take into account that the resulting host name will be only used >>>> in InetAddress.getLocalHost() where it will finally serve as input to >>>> InetAddressImpl.lookupAllHostAddr() which will in turn do exactly the >>>> same reverse lookup procedure (at least if the default name service is >>>> used). Therefore the new implementation switches this reverse lookup >>>> off by default unless the user requests it with the two system >>>> properties java.net.doIPv4ReverseLookupInGetLocalHost and >>>> java.net.doIPv6ReverseLookupInGetLocalHost for IPv4 and IPv6 >>>> respectively. Consequently, the new Unix version of >>>> Java_java_net_Inet{4,6}AddressImpl_getLocalHostName is now equal to >>>> its Windows counterpart which simply returns the result of >>>> gethostname() as well. >>>> >>>> Notice that for these properties, the name "IPv4" and "IPv6" refer to >>>> the actual InetAddressImpl version (i.e. either Inet4AddressImpl or >>>> Inet6AddressImpl) that is used by InetAddress. On most modern hosts, >>>> InetAddress will use an Inet6AddressImpl helper if the host is IPv6 >>>> "capable". That doesn't necessarily mean that >>>> InetAddress.getLocalHost() will return an IPv6 address or even that >>>> there's a network interface with an IPv6 address - it just means that >>>> the network stack can handle IPv6. InetAddress can be forced to use >>>> the Inet4AddressImpl helper by setting the java.net.preferIPv4Stack >>>> property to false. >>>> >>>> In the new implementation both properties >>>> java.net.doIPv4ReverseLookupInGetLocalHost and >>>> java.net.doIPv6ReverseLookupInGetLocalHost are set to false by >>>> default. But the old behavior could be restored by setting >>>> java.net.doIPv4ReverseLookupInGetLocalHost=true and >>>> java.net.doIPv6ReverseLookupInGetLocalHost=true (Solaris only). >>>> >>>> In a previous mail thread [2] we discussed the possibility of >>>> replacing the call to getnameinfo() in >>>> Inet{4,6}AddressImpl_getLocalHostName() by simply using the >>>> ai_canonname field returned by the getaddrinfo() call. But because I >>>> think the reverse lookup is unnecessary anyway (and disabled by >>>> default in the new implementation), I didn't tried that any more and >>>> stayed with the old version. >>>> >>>> I've built these changes on Linux, Solaris, MacOS X and AIX and >>>> manually tested them on various hosts with different IPv4/IPv6 setups >>>> without any problems. In cases where the output of >>>> InetAddress.getLocalHost() differed in the new version this was only a >>>> difference in the hostname part of the InetAddress (i.e. fully >>>> qualified name vs. simple name) and this could be easily restored with >>>> the help of the new system properties. Notice that for the new version >>>> the host name now usually corresponds to what the hostname command >>>> returns on Unix which is probably what most people would expect. In >>>> the old version the host name was more dependent on the local system >>>> configuration (i.e. /etc/hosts or /etc/nsswitch.conf) as discussed in >>>> [2]. >>>> >>>> The following mail threads already discuss this issue: >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/net-dev/2014-October/thread.html#8721 >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/net-dev/2013-June/thread.html#6543 >>>> >>>> PS: We probably shouldn't discuss this too long as there are other >>>> methods like Java_java_net_Inet{4,6}AddressImpl_lookupAllHostAddr >>>> which are waiting for unification and simplification as well :) >>> > From volker.simonis at gmail.com Fri Oct 31 14:35:51 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 31 Oct 2014 15:35:51 +0100 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: <544E8E76.2060403@oracle.com> References: <544A8740.9040905@oracle.com> <544E8E76.2060403@oracle.com> Message-ID: Hi, under the following link you can find an updated version of my change where I've fixed all indentation in Inet{4,6}AddressImpl.c to 4 spaces and changed the few C++-style comments (i.e. '//') to C-style comments (i.e. '/* */'): http://cr.openjdk.java.net/~simonis/webrevs/8060470.v2/ Can I please also get a review with regards to the content of this change (as opposed to its form:) Thank you and best regards, Volker On Mon, Oct 27, 2014 at 7:27 PM, Alan Bateman wrote: > On 27/10/2014 17:45, Volker Simonis wrote: >> >> : >> Well, the problem is that already that very file contains code in both >> code conventions (see for example the implementations of 'ping4()' >> and 'Java_java_net_Inet4AddressImpl_isReachable0()' in >> Inet4AddressImpl.c which are mostly indented by two spaces). I have no >> problems to adhere to any convention as long as it is generally >> obeyed. As this does not seemed to be the case in these files, I've >> just chosen what I thought is most appropriate. So to keep a long >> story short - I can either: >> >> 1. indent my changes to four spaces (which will still let the files >> with mixed indentation) >> 2. change all indentation in the file to two spaces >> 3. change all indentation in the file to four spaces >> >> Please just tell me what you'd prefer. >> > We normally use 4 space indent in the library code. There are some > inconsistencies, I don't know the fully history to understand how we got > 2-space indent but if you can fix it up then that would be great. > > -Alan From ecki at zusammenkunft.net Fri Oct 31 16:19:20 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 31 Oct 2014 17:19:20 +0100 Subject: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName() In-Reply-To: References: <544A8740.9040905@oracle.com> <544E8E76.2060403@oracle.com> Message-ID: <20141031171920.00002e0d.ecki@zusammenkunft.net> Hello, I (still) like it. But I still think the AI_CANONNAME can and should be removed. If you keep it, it will trigger additional lookups and the actual canonized result (res->ai_canonname) is never used. This is true for all 3 locations (but you changed only one). I wonder if you want to make the control flags c-static and avoid the lookups. Gruss Bernd Am Fri, 31 Oct 2014 15:35:51 +0100 schrieb Volker Simonis : > Hi, > > under the following link you can find an updated version of my change > where I've fixed all indentation in Inet{4,6}AddressImpl.c to 4 spaces > and changed the few C++-style comments (i.e. '//') to C-style comments > (i.e. '/* */'): > > http://cr.openjdk.java.net/~simonis/webrevs/8060470.v2/ > > Can I please also get a review with regards to the content of this > change (as opposed to its form:) > > Thank you and best regards, > Volker > > > On Mon, Oct 27, 2014 at 7:27 PM, Alan Bateman > wrote: > > On 27/10/2014 17:45, Volker Simonis wrote: > >> > >> : > >> Well, the problem is that already that very file contains code in > >> both code conventions (see for example the implementations of > >> 'ping4()' and 'Java_java_net_Inet4AddressImpl_isReachable0()' in > >> Inet4AddressImpl.c which are mostly indented by two spaces). I > >> have no problems to adhere to any convention as long as it is > >> generally obeyed. As this does not seemed to be the case in these > >> files, I've just chosen what I thought is most appropriate. So to > >> keep a long story short - I can either: > >> > >> 1. indent my changes to four spaces (which will still let the > >> files with mixed indentation) > >> 2. change all indentation in the file to two spaces > >> 3. change all indentation in the file to four spaces > >> > >> Please just tell me what you'd prefer. > >> > > We normally use 4 space indent in the library code. There are some > > inconsistencies, I don't know the fully history to understand how > > we got 2-space indent but if you can fix it up then that would be > > great. > > > > -Alan