Mark Sheppard | 19 Nov 20:50 2014

RFR: JDK-8065222 - sun/net/www/protocol/http/ doesn't execute as expected

    please oblige and review the following change

to address the issue

The URL construction in the test now uses 
InetAddress.getLocalHost().getHostName(), rather than the
address.getHostName(), which was returning wildcard IP address, causing 
a MalformedURLException.
Test, amended to propagate exception failures, also.


mark.reinhold | 12 Nov 23:59 2014

JEP 110: HTTP 2 Client

New JEP Candidate:

- Mark

Chris Hegarty | 7 Nov 12:44 2014

www.http.HttpClient break HTTP PUT streaming

This is a trivial change to fix a failed previous attempt to prevent all 
HTTP requests, with a streaming body, from automatically being retried, 
by the HttpURLConnection implementation.

The existing implementation only prevents POST requests from being 
automatically retried, it should prevent all, incl PUT.



Michael McMahon | 4 Nov 11:44 2014

RFR: 8062744 does not support IP_TOS

Could I get the following small change reviewed please?

In JDK 9 the problem only affects the Socket.supportedOptions() method,
but the same change is needed in 8 to allow the IP_TOS option to be set
in a ServerSocket.


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 [] On Behalf Of Kirk Shoop (MS OPEN TECH)
Sent: Tuesday, October 7, 2014 8:16 AM


From: Alan Bateman []
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"?

Yes, we will change to the name to ‘’. ‘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 " ( , 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.


Sincerely yours,

Salter, Thomas A | 30 Sep 19:15 2014

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

Why not use the .invalid domain?

See, section 
6.4.  Domain Name Reservation Considerations for "invalid."

Tom Salter
Unisys Corporation