Seán Coffey | 27 Feb 12:37 2015

RFR : 8072384 : Setting IP_TOS on sockets not working on unix

It looks like setting and getting the IP_TOS values on the 
Sockets is currently broken for some scenarios. It's not possible to set 
the value on a ServerSocket via the API. See 
below for a webrev I'm proposing. It basically makes best efforts to set 
the IP_TOS value by mapping it to the IPV6_TCLASS option in an IPV6 
enabled environment. NIO follows a similar approach.

Some of the comments in NET_SetSockOpt seem to be legacy and I've 
removed the no-op that was in place for IP_TOS. A corner case of setting 
of IP_TOS was found on Solaris. It doesn't seem to support setting the 
value once the socket is connected. I've handled this via catching of 
exception and we should be ok with this since the spec doesn't make any 
promises in this area if the socket is connected.

I've been testing various fixes across IPv4/v6 sockets on Solaris, Linux 
and macosx. So far, the proposed changes seem to work and wireshark 
traces help to confirm that TOS/TCLASS values are being set.

I still need to see if I can improve the getOpt logic for IP_TOS. At the 
moment, it can return a cached value which may not represent the true 
value in place at kernel socket level. I'll also improve test coverage 
in this area.

bug report :
webrev :


(Continue reading)

Seán Coffey | 24 Feb 18:24 2015

RFR: 7178362: Socket impls should ignore unsupported proxy types rather than throwing

This issue relates to another bug that I own : JDK-8062305

It seems to be an area that causes alot of issue (for plugin mainly) and 
the suggestion from Chris in 7178362 bug report to return a direct 
connection type for bad ProxySelector implementations seems appropriate.

webrev :
bug report :


Mark Sheppard | 18 Feb 16:30 2015

RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

    please oblige and review the following changes

which address the parfait issues in

pertaining to uninitialized memory in


Mark Sheppard | 18 Feb 14:19 2015

RFR: JDK-8046893 - JNI exception pending in jdk/src/solaris/native/java/net: ExtendedOptionsImpl.c, PlainDatagramSocketImpl.c

    please review the following small change

which addresses the parfait issue in


joe darcy | 10 Feb 00:27 2015

JDK 9 RFR of JDK-8041395: Doclint regression in


Please review these straightforward changes to address some doclint 
issues in

     JDK-8041395: Doclint regression in

Patch below.



--- old/src/java.base/share/classes/java/net/ 
2015-02-09 15:19:25.407396706 -0800
+++ new/src/java.base/share/classes/java/net/ 
2015-02-09 15:19:25.223399019 -0800
 <at>  <at>  -1,5 +1,5  <at>  <at> 
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights 
   * This code is free software; you can redistribute it and/or modify it
 <at>  <at>  -1308,6 +1308,7  <at>  <at> 
       * Sets the value of a socket option.
(Continue reading)

Ivan Gerasimov | 6 Feb 18:48 2015

RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket


There has been a deadlock in jdk-net code noticed on Windows.

In the bug description there's a stack snippet showing that one of the 
deadlocked threads stuck in the native initialization code of 
DualStackPlainDatagramSocketImpl and the other -- in initializing of 

I suspect that the reason might be due to unordered initialization:
AbstractPlainDatagramSocketImpl, the parent of both classes above, 
explicitly loads TwoStacksPlainDatagramSocketImpl from the native init().
Thus, when both classes are being initialized concurrently, it may end 
with a clash.

Another issue noticed by Mark Sheppard is that the Windows version of 
DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't 
synchronized, but reads/modifies shared data.
Thus, I removed modification and declared all the accessed fields final.

Would you please help review the proposed fix?


The build went fine on all the platforms, all the tests from 
(net|nio|io) passed Okay.

Sincerely yours,
(Continue reading)

Chris Hegarty | 30 Jan 14:36 2015

RFR 8064924: Update to work with modules

This is phase 1, of getting work with modules. 

Being able to effectively specify URL protocol handler factories as fully qualified class names, through
the 'java.protocol.handler.pkgs' system property is problematic. It requires the protocol handler
factory implementation class to be public and accessible, as the current implementation tries to
instantiate it through core reflection. Since the protocol handler factory must be an implementation of
a URLStreamHandlerFactory, it lends itself to being retrofitted with a ServiceLoader lookup. Note, the
'java.protocol.handler.pkgs' system property mechanism predates ServiceLoader. URL protocol
handlers would most likely have used service loader if it were available at the time. 

Some URL protocol handlers are fundamental to the platform itself, like 'file' and 'jar', it is not
appropriate to attempt a service loader lookup for these, as they may lead to recursive initialization
issues. However, Java Plugin, Webstart, and possibly other containers, do override the 'jar' handler. A
new API will be provided for this purpose. Providing an API solution should not interfere with system
initialization as it will only be called after the system comes up and user code is executing. 

The 'file' protocol handler factory will no longer be overridable, and the system property will no longer
be consulted.

Webrev and spec diffs:

I want to agree the approach and spec first, so that the spec changes can be submitted for approval. A
comprehensive test will be added before the code changes are finalised.

Chris Hegarty | 28 Jan 21:01 2015

RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

Reviving an old code review [1], after further investigation…

Pertinent details from previous review:
"A socket connection which is returned by ServerSocket.accept() is inherited by a child process. The expected behavior is that the socket connection is not inherited by the child process. This is an oversight in the original implementation, that only sets HANDLE_FLAG_INHERIT for newly created sockets. The native socket returned by ServerSocket.accept() should be configured so it will not be inherited by a child process, SetHandleInformation(<HANDLE>, HANDLE_FLAG_INHERIT, FALSE)."

There were on objections to the changes, since they are mainly benign, but I took the action to investigate why we are calling CreateProcess with bInheritHandles set to TRUE. It appears that, without major work, we cannot change this.

From 7147084 [2]:

Java does not provide the API to change inherit-bit for any handle. More over, since at least the JDK 6, it is assumed that all Java-created handles have no installed inherit-bit . The only handles that change the inherit-bit to 1 in the Java call are the handles of redirected Input, Output, and Error streams (IOE streams for short) for child process. That is the way these redirect the streams work. That's why we can not give up the nomination in [TRUE] the parameter [bInheritHandles] in the [CreateProcess] call. And I want to mention again that this is the only place in JDK where Java installs the inherit-bit. Java itself does not use handle inheritance.

Ivan pointed out that HANDLE_FLAG_INHERIT will not always work, in the case of Layered Service Providers, see [3], but it will work in the standard case.

Finally, I think that we will need to revisit the process creation implementation at some point, to see if bInheritHandles can be set to FALSE, but that is a larger, more significant, piece of work, that should be done separately.


P.S. if there are no objections to the changes I will amend an existing test case to cover these new cases.

Rob McKenna | 28 Jan 17:46 2015

RFR: 8067680: (sctp) Possible race initializing native IDs

This is a fix to a possible race in the current sctp code. In a nutshell 
the conditional only checks that isaCls is not null. However if isaCls 
is set by one thread and that thread is interrupted before setting 
isaCtrID, the interrupting thread will falsely assume that isaCtrID has 
been set.


Chris Hegarty | 23 Jan 14:51 2015

RFR 8071424: JCK test api/java_net/Socket/descriptions.html#Bind crashes on Windows

This is a fix for a minor oversight when refactoring the initializing of 
Inet[4|6]Address IDs, used in many places in the networking native code.

It would appear that there is an initInetAddressIDs() call missing from 
the Windows Dual Stacks Socket implementation, 
Java_java_net_DualStackPlainSocketImpl_initIDs.  An existing test has 
been amended to cover this.


Konstantin Shefov | 23 Jan 13:56 2015

[8u-dev] Request for approval: JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id


Please approve the direct backport of the bug fix to 8u-dev

Patch applies cleanly to JDK 8u.

The bug:
The webrev:

JDK 9 changeset:
Review thread: