Re: RFR 8064924: Update java.net.URL to work with modules
On 04/02/2015 15:11, Chris Hegarty wrote: Agreed. Updated in-place http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html I think the approach and naming is good. A few small comments on the wording: 1. "used to locate URLStreamHandlerProvider providers" - the wording hints as further redirection, maybe it would be better as "URLStreamHandlerProvider implementations". 2. "the ordering that providers are located" - maybe this should be "the order that providers are located". 3. "Some protocol, that are fundamental ...". Here's a re-worded statement to consider: "Some protocol handlers, for example those used for loading platform classes or classes on the class path, may not be overridden. The details of such restrictions, and when those restrictions apply (during initialization of the runtime for example), are implementation specific and therefore not specified". One other thing in this area is setURLStreamHandlerFactory(null). Long standing behavior is to remove the system-wide URLStreamHandlerFactory, should this continue? -Alan
Re: [8u-dev] Request for approval: JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id
Hi Sean,
I have tried to use different symbols in networking interface name in
Linux. I have added a comment to
https://bugs.openjdk.java.net/browse/JDK-8071458
I am able to use symbols: "-", "+", "=", "#", "@".
I was UNABLE to use: "?", "~", "$", "*", "!", "[", "(", "&", "^", "|",
"/", ":" and "\".
My network interface name in Linux is now "eth0.1_-+=#@55" (used
"ifconfig" command).
On 23.01.2015 16:47, Seán Coffey wrote:
Konstantin,
can you hold off pushing this fix to jdk8u for the moment ? It's a P4
and could have behavioural consequences (something we try and avoid in
update releases). I see JDK-8071458 was logged to track IPv6 scope
specifications. Let's see how this soaks into JDK 9 over coming days
and let's see how JDK-8071458 progresses.
regards,
Sean.
On 23/01/15 12:56, Konstantin Shefov wrote:
Hello,
Please approve the direct backport of the bug fix to 8u-dev
Patch applies cleanly to JDK 8u.
The bug:https://bugs.openjdk.java.net/browse/JDK-6933879
The webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.01/
JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/801eb37fc6c4
Review thread:
http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008834.html
Thanks
-Konstantin
RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket
Hello! 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 TwoStacksPlainDatagramSocketImpl. 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? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466 WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/ The build went fine on all the platforms, all the tests from (net|nio|io) passed Okay. Sincerely yours, Ivan
