Mark Sheppard | 26 May 21:34 2015

RFR: JDK-8077377 - java/net/MulticastSocket/ fails intermittently with NullPointerException

    please oblige and review the following change

to address the issue

it is possible that "stray" packets can be received in this 
MulticastSocket test, and
this results in a NPE from the NetworkInterface lookup based on the 
received address.
Change adds a test that the "from" NetworkInterface is not null.


Mark Sheppard | 26 May 21:21 2015

RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

   please oblige and review the following change

which addresses the issue

analysis has shown that the Teredo interfaces causes issue, due to its 
dynamic configuration, when included in
the test. A conditional statement excludes Teredo from the latter part 
of the test, so
the conditional is moved to the start of the while loop


Brian Toal | 22 May 08:56 2015

[PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses

The fix for causes a regression for Mac OSX hosts connected to a VPN (or otherwise with more than network
interface associated with the hostname).

For example, when on Cisco VPN, the ifconfig is as follows:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet netmask 0xff000000 
    inet6 ::1 prefixlen 128 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
    ether 28:cf:e9:1a:eb:6b 
    inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 
    inet netmask 0xffffff00 broadcast
    media: autoselect
    status: active
    ether 0a:cf:e9:1a:eb:6b 
    media: autoselect
    status: inactive
    inet --> netmask 0xffffc000 
    inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 
    inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 

The hostname entry in DNS is associated with the utun0 interface, and and all routes go through that interface. The IP is my local wifi address, and is not used (other than to tunnel the VPN traffic when VPN is connected). Any connections to the 192.168 address, even from localhost, will fail (hang indefinitely, as all packets are dropped).

The OS getaddrinfo calls, when passed the FQDN hostname only return the 10.3 address (getaddrinfo.c attached).

Prior to the fix for JDK-7180557, getaddrinfo was being used and everything worked fine. As part of the fix, the following block was added for OSX only in the IPv4 path:

+ #ifdef MACOSX
+     /* If we're looking up the local machine, bypass DNS lookups and get
+      * address from getifaddrs.  
+      */  
+     ret = lookupIfLocalhost(env, hostname, JNI_FALSE);
+     if (ret != NULL) {
+         JNU_ReleaseStringPlatformChars(env, host, hostname);
+         return ret;
+     }
+ #endif

This code, which occurs before the usual path and applies only to localhost lookups, tries to "guess" the localaddress by interface enumeration. In the case of a VPN configuration, both en0 (192.168) and utun0 will match as they are active. So, for example, InetAddress.getAllByName("localhost FQDN"), will return both addresses. However, the getByName() call and most other code which implicitly uses the localhost will return only the first entry, which is the unroutable en0 address.

The host is configured correctly and other processes all resolve the hostname correctly. The issue is specific to this OSX workaround. 

On the IPv6 path for the same fix, the lookupIfLocalhost workaround was only applied *if* the original lookup via the usual routines failed. The attached patch follows the same approach in the IPv4 path, if the orginal lookup fails then call lookupIfLocalhost If this was applied to the IPv4 path.  The patch fixes the issue without regressing the hosts that triggered this fix.

# HG changeset patch
# User btoal
# Date 1432276472 25200
#      Thu May 21 23:34:32 2015 -0700
# Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593
# Parent  20e6cadfac43717a81d99daff5e769de695992cd
Only call lookupIfLocalhost if getaddrinfo call errors to avoid resolving to a incorrect address.

diff -r 20e6cadfac43 -r 24cf7a8a8bf4 src/solaris/native/java/net/Inet4AddressImpl.c
--- a/src/solaris/native/java/net/Inet4AddressImpl.c    Thu Feb 05 13:00:26 2015 +0100
+++ b/src/solaris/native/java/net/Inet4AddressImpl.c    Thu May 21 23:34:32 2015 -0700
<at> <at> -172,20 +172,19 <at> <at>
         return NULL;

-#ifdef MACOSX
-    /* If we're looking up the local machine, bypass DNS lookups and get
-     * address from getifaddrs.
-     */
-    ret = lookupIfLocalhost(env, hostname, JNI_FALSE);
-    if (ret != NULL || (*env)->ExceptionCheck(env)) {
-        JNU_ReleaseStringPlatformChars(env, host, hostname);
-        return ret;
-    }
     error = getaddrinfo(hostname, NULL, &hints, &res);

     if (error) {
+#ifdef MACOSX
+        /* If we're looking up the local machine, bypass DNS lookups and get
+         * address from getifaddrs.
+         */
+        ret = lookupIfLocalhost(env, hostname, JNI_FALSE);
+        if (ret != NULL || (*env)->ExceptionCheck(env)) {
+            JNU_ReleaseStringPlatformChars(env, host, hostname);
+            return ret;
+        }
         /* report error */
         ThrowUnknownHostExceptionWithGaiError(env, hostname, error);
         JNU_ReleaseStringPlatformChars(env, host, hostname);
Rob McKenna | 20 May 14:24 2015


Hi folks,

Looking for a review of this webrev:

Basically the subjects credentials are not available to 
HttpURLConnection.getInputStream0 since it now runs in a doPrivileged 
block. Changing that to doPrivilegedWithCombiner allows getInputStream0 
access to the AccessControlContext's DomainCombiner and the subjects 
associated credentials.


Takao, Shinji | 19 May 08:41 2015

jaxws tmp files may cause disk full

Hi all,

One of my customer encountered a disk full error and found
that the /tmp was filled with files "jaxws<19 numbers>.bin".

I could not find a known issue like it, but noticed that
the jaxws code in openjdk may leave temporary files in the /tmp.

I suggest a fix for the code as attached.

Please note that I have not confirmed that the fix works,
but I would like to show you it now because it may take
some time to confirm, and necessity for the fix looks
rather obvious for me.


diff -r 45ef73bb85c1 -r 455600e57dd2 src/
a/src/	Thu
May 14 12:38:10 2015 -0700
b/src/	Tue
May 19 10:09:15 2015 +0900
 <at>  <at>  -168,6 +168,7  <at>  <at> 
         public void close() throws IOException {
             if (!closed) {
+                in.close();
                 closed = true;
 <at>  <at>  -195,6 +196,7  <at>  <at> 
                         // This causes problems for streaming in one-way cases
                         try {
+                            in.close();
                         } catch(IOException ioe) {
                             // Ignoring purposefully.
Stanislav Baiduzhyi | 4 May 17:38 2015

DNS resolution fails after resolv.conf update

Hi All,

We are facing an issue with DNS server caching on RHEL-based distros: after 
the update of resolv.conf java application cannot resolve the hosts any more.

Reproducer is very simple:
1. Clean /etc/resolv.conf or connect to vpn and use vpn-only nameserver.
2. Launch the minimal java app [1].
3. Restore the /etc/resolv.conf or disconnect from vpn (/etc/resolv.conf 
should be updated with accessible nameserver at this moment).
4. Notice that name resolution continues to fail.

I've prepared a small webrev that fixes the issue [2], but would like to hear 
some ideas/criticism first. If the patch looks ok to everyone, please create 
an issue for this, and I will submit it for approval/sponsorship.





KUBOTA Yuji | 21 Apr 17:31 2015

Potential infinite waiting at JMXConnection#createConnection

Hi all,

I found an infinite waiting at TCPChannel#createConnection.
This method flushes the DataOutputStream without the socket timeout settings
when choose stream protocol [1].

If connection lost (the destination server do no return response)
during the flush,
this method has possibilities to take long time beyond the expectations
at as following stack trace.

stack trace :
        at sun.rmi.transport.tcp.TCPChannel.createConnection(
        at sun.rmi.transport.tcp.TCPChannel.newConnection(
        at sun.rmi.server.UnicastRef.invoke(

When create connection, we cannot set the timeout by properties.
Therefore, JMX sets
the default value of SO_TIMEOUT, i.e., infinite. So I wrote a patch to
fix this infinite
waiting by using property-configured value:

Please review this patch. :)

Note: My OCA has been processed a few hour ago, so my name may take a
short time to
appear on the OCA signatories page.



diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/
--- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/
+++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/
 <at>  <at>  -222,20 +222,34  <at>  <at> 
                 // choose protocol (single op if not reusable socket)
                 if (!conn.isReusable()) {
                 } else {
+                    int usableSoTimeout = 0;
+                    try {
+                        /*
+                         * If socket factory had set a zero timeout on its own,
+                         * then set the property-configured value to prevent
+                         * an infinite waiting.
+                         */
+                        usableSoTimeout = sock.getSoTimeout();
+                        if (usableSoTimeout == 0) {
+                          usableSoTimeout = responseTimeout;
+                        }
+                        sock.setSoTimeout(usableSoTimeout);
+                    } catch (Exception e) {
+                        // if we fail to set this, ignore and proceed anyway
+                    }

                      * Set socket read timeout to configured value for JRMP
                      * connection handshake; this also serves to guard against
                      * non-JRMP servers that do not respond (see 4322806).
-                    int originalSoTimeout = 0;
                     try {
-                        originalSoTimeout = sock.getSoTimeout();
                     } catch (Exception e) {
                         // if we fail to set this, ignore and proceed anyway

 <at>  <at>  -279,18 +293,11  <at>  <at> 
                      * connection.  NOTE: this timeout, if configured to a
                      * finite duration, places an upper bound on the time
                      * that a remote method call is permitted to execute.
                     try {
-                        /*
-                         * If socket factory had set a non-zero timeout on its
-                         * own, then restore it instead of using the property-
-                         * configured value.
-                         */
-                        sock.setSoTimeout((originalSoTimeout != 0 ?
-                                           originalSoTimeout :
-                                           responseTimeout));
+                        sock.setSoTimeout(usableSoTimeout);
                     } catch (Exception e) {
                         // if we fail to set this, ignore and proceed anyway


Chris Hegarty | 14 Apr 18:24 2015

RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

The work done as part of JDK-8064924 [1] to introduce a new service type,, provides a clean provider mechanism that will work well with
modules. That part of the change should remain, but the removal of support to find handlers through the
java.protocol.handler.pkgs system property is problematic, and could be an impediment to moving to JDK
9. Applications making use of custom protocol handlers and not packaged as modules should continue to be
able to use this property.

The proposal is to reinstate the JDK 8 specification about java.protocol.handler.pkgs in<init>, that documents the search order for handlers. Additionally reinstate the JDK 8
implementation code to search the system property after the service loader lookup.

The spec and code changes in the above webrev are almost identical to the original code pre 8064924.


Brian Burkhalter | 19 Mar 15:30 2015

[9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense

Please review at your convenience. This a doc-only change.


This is in effect an amplification of extant javadoc suggested as an enhancement by an external user. I performed some testing to verify the accuracy of the suggested documentation change prior to crafting the verbiage, and the criticism does seem to be well-founded in the behavior of the APIs in question.

It would be good however if someone with a more profound knowledge of this area were to review the proposed documentation update for accuracy, especially as it is not unlikely that there might be platform-specific behavior with which these statements conflict.


Rob McKenna | 19 Mar 00:27 2015

RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/ fails on Solaris only

Hi folks,

Mistakenly neglected to exclude Solaris from testing:


Michael McMahon | 9 Mar 17:27 2015

HTTP 2 client API


JEP 110 HTTP 2 client

in JDK 9, is defining and implementing a new API for HTTP which also 
the new HTTP version 2 that has recently been working its way through 
the IETF.
The work also includes support for websockets (RFC 6455).

In fact, the majority of the API is agnostic about the HTTP protocol 
version, with only minor
configuration settings, and support for multiple responses (Http server 
push) having any direct impact.

The HTTP API is defined around three main types (HttpClient, which is 
the central
point for configuration of SSL, executor service cookie management etc), 
and HttpResponse (which should be self explanatory).

Requests are sent/received either synchronously (blocking) or in a 
non-blocking (asynchronous)
mode using java.util.future.CompletableFuture which is a powerful new 
framework for
asynchronous execution introduced in JDK 8.

The API docs can be seen at the link below:

All new classes and interfaces belong to the package.

A prototype implementation of this API supporting HTTP/1.1 only, is 
available and will
be uploaded into the JDK 9 sandbox forest in the coming day or two.

Comments welcome!