Volker Simonis | 16 Oct 16:39 2014

RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()


could you please hava a look at the following change:


It's probably easier to read the following in the webrev, but I copy
it below for discussion.


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

The only difference between the two IPv4 versions was the ai_family
(Continue reading)

Michael McMahon | 15 Oct 13:03 2014

RFR 8042622: Check for CRL results in IllegalArgumentException "white space not allowed"


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.


Kirk Shoop (MS OPEN TECH | 9 Oct 19:10 2014

RE: Taking advantage of TCP Loopback fast path in Windows

From: nio-dev [mailto:nio-dev-bounces-0nJqbsLSQw0FDOXUYO6UHQ@public.gmane.org] On Behalf Of Kirk Shoop (MS OPEN TECH)
Sent: Tuesday, October 7, 2014 8:16 AM


From: Alan Bateman [mailto:Alan.Bateman-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org]
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:







Microsoft Open Technologies, Inc.

Volker Simonis | 8 Oct 18:59 2014

Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName()


I wonder why the implementations of
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:


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

And here's how the corresponding IPv6 version looks like:


    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,

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

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

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

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


Seán Coffey | 3 Oct 14:38 2014

RFR : 8046588 8047187

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.


Testcase changes keep to the same theme as the JDK 8u fix but are in 
non-lambda format.
webrev : 

Re-tested on a solaris box with SO_FLOW_SLA enabled and all was green. 
JPRT results are green also.


Ivan Gerasimov | 1 Oct 10:48 2014

RFR 8059450: Not quite correct code sample in javadoc


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,

Salter, Thomas A | 30 Sep 19:15 2014

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java

Why not use the .invalid domain?

See http://tools.ietf.org/html/rfc6761, section 
6.4.  Domain Name Reservation Considerations for "invalid."

Tom Salter
Unisys Corporation

Mark Sheppard | 30 Sep 17:21 2014

RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist


Please oblige and review the following small change to test 

--- 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
 <at>  <at>  -36,7 +36,7  <at>  <at> 
              {"126.1", ""},
              {"128.50.65534", ""},
              {"", ""},
-            {"hello.foo.bar", null},
+            {"somehost.some-domain", null},
              {"1024.1.2.3", null},
              {"128.14.66000", null }

which addresses the issue


ping hello.foo.bar

Pinging hello.foo.bar [] with 32 bytes of data:
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128

this highlights a DNS configuration issue as indicated in

so we remove foo.bar from the test and replace with somehost.some-domain



RE: Taking advantage of TCP Loopback fast path in Windows


We’re proposing an improvement to the OpenJDK which enables users to take advantage of the TCP loopback fast path mechanism in Windows for significantly higher performance of sockets whose both end points are on the same machine.  This is especially relevant in distributed server-side/cloud scenarios, such as Hadoop.


We have the code figured out and tested internally. I’ve uploaded our webrev package here (too big to send as an attachment):




The crux of the change lies in enabling the SIO_LOOPBACK_FAST_PATH IOCTL flag on each socket creation call in Windows.


As for activating this optimization, we’re proposing the conservative approach of keeping it off by default and adding a command line argument to activate it:

-Dwindows.enableFastLocalTcpLoopback=true | false


(IMHO though, it’d be great to eventually just have it on by default).


We’d appreciate a review and acceptance of this improvement.


And, as we are new in the OpenJDK community and this may as well be our first contribution to Java, I apologize for any steps in the submission process that I may have missed here and would appreciate guidance as needed.


Best regards


Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov)

Microsoft Open Technologies, Inc.

A subsidiary of Microsoft Corp.


Ivan Gerasimov | 21 Sep 14:19 2014

RFR 8058824: Drop TwoStacks socket implementation in jdk9 [win] - Part I


Here is a proposal for the first step in cleaning up the TwoStacks 
socket implementation.
It is proposed to drom IPv6 support in the implementation of 
TwoStacksPlainSocketImpl class (so formally, it's no more Two Stacks).
Therefore, this class will only be used when the user explicitly 
requests IPv4 only configuration through setting 
java.net.preferIPv4Stack option.

The fix mostly consists of removal, so it should be relatively easy to 

All the jdk_net tests pass.

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

Sincerely yours,

Chris Hegarty | 11 Sep 15:42 2014

RFR [9] 8058216: NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack

A small issue was found when running JCK tests on modern Windows platforms, that have IPv6 enabled, but
forced to run with the IPv4 Stack, -Djava.net.preferIPv4Stack=true.
NetworkInterface.getHardwareAddress() can return a zero length byte array, where is should, and is
specified to, return null.

The solution is to only create the byte array if the physical address is known. Running an existing
regression test with -Djava.net.preferIPv4Stack=true covers this issue.

diff -r 5cf954b229fe src/java.base/windows/native/libnet/NetworkInterface.c
--- a/src/java.base/windows/native/libnet/NetworkInterface.c    Thu Sep 11 15:13:37 2014 +0400
+++ b/src/java.base/windows/native/libnet/NetworkInterface.c    Thu Sep 11 14:34:11 2014 +0100
 <at>  <at>  -990,9 +990,11  <at>  <at> 
       case MIB_IF_TYPE_FDDI:
       case IF_TYPE_IEEE80211:
         len = ifRowP->dwPhysAddrLen;
-        ret = (*env)->NewByteArray(env, len);
-        if (!IS_NULL(ret)) {
-          (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *) ifRowP->bPhysAddr);
+        if (len > 0) {
+          ret = (*env)->NewByteArray(env, len);
+          if (!IS_NULL(ret)) {
+            (*env)->SetByteArrayRegion(env, ret, 0, len, (jbyte *) ifRowP->bPhysAddr);
+          }
diff -r 5cf954b229fe test/java/net/NetworkInterface/Test.java
--- a/test/java/net/NetworkInterface/Test.java  Thu Sep 11 15:13:37 2014 +0400
+++ b/test/java/net/NetworkInterface/Test.java  Thu Sep 11 14:34:11 2014 +0100
 <at>  <at>  -23,6 +23,8  <at>  <at> 

 /*  <at> test
  *  <at> bug 4405354 6594296
+ *  <at> run main Test
+ *  <at> run main/othervm -Djava.net.preferIPv4Stack=true Test
  *  <at> summary Basic tests for NetworkInterface
 import java.net.NetworkInterface;