Andreas Rieber | 17 Jul 20:03 2014

JDK-6797318: Undeclared IAE thrown from HttpURLConnection.connect for some URLs


i would like to contribute a patch for this old issue. The suggested
fix in the issue looks right but instead of the IOE it would simply
connect to localhost. The same wrong behaviour can be reproduced
with ProxySelector.setDefault(null).

I also checked other protocols and http, https and ftp are affected.
The hostname is not checked currently and the used
InetAddress.getAllByName(host) just returns the "loopbackAdress" if
hostname is empty.

Running the test under security manager got me a
StringIndexOutOfBoundsException from the URLPermission/HostPortrange,
where the hostname is not checked for empty string.

With the test i try to cover all cases. Simple connect, with no
ProxySelector, wrong redirect URL and all with security manager.


Bug also fixed with no additional change (test included):


I did run jtreg */net */security on Ubuntu 14, Solaris 11 and Windows 8.1.
Sponsor required as usually.
(Continue reading)

Mark Sheppard | 17 Jul 13:01 2014

RFR: JDK-8050922 - add additional diagnostic to java/net/MulticastSocket/

    please oblige and review the following diagnostic output addition to
the test java/net/MulticastSocket/

for the task

which will assist in diagnosing an intermittent failing test

the addition displays the interface details, of the failing scenario,  
to std err


Mark Sheppard | 16 Jul 19:00 2014

RFR: JDK-8040810 - Uninitialised memory in jdk/src/windows/native/java/net: net_util_md.c, TwoStacksPlainSocketImpl.c, TwoStacksPlainDatagramSocketImpl.c, DualStackPlainSocketImpl.c, DualStackPlainDatagramSocketImpl.c

     please oblige and review the following changes

which address the issue raised in

resulting from static code analysis.

these changes explicitly initialize local function variables, which are 
in the main
out parameters to other function calls and hence are set within the 
called function.
It can be reasonably argued that the initialization is unnecessary, but 
current coding
guidance is to perform the initialization


Peter Levart | 11 Jul 17:11 2014

URL constructor/equals/hashCode/sameFile/openConnection synchronization issues

Hi, is supposed to behave as an immutable object, so URL 
instances can be shared among threads and among parts of code without 
fear that they will be modified. URL class has an unusual way to achieve 
this (or at least it tries to). Partly because of the design which uses:

- URL constructor(s) that take a 'spec' String to be parsed into URL object
- parsing is delegated to various URLStreamHandler(s) which are chosen 
in the URL constructor (depending on the protocol used in URL string to 
be parsed)

An unitialized URL instance (this) is passed from constructor to the 
chosen URLStreamHandler which has the responsibility to parse the string 
and set back the fields that hold various parts of URL object being 
constructed. Consequently, these fields can not be declared as final, as 
definite assignment analysis doesn't cross method borders. It is 
therefore illegal to unsafely publish URL instances (via data races) to 
non-constructing threads because they can appear not fully initialized. 
Nevertheless URL, with the help of various URLStreamHandler 
implementations, tries hard to make URL appear stable at least where it 
is required to be stable. For example: URL.hashCode() is (almost) stable 
even if URL instance is unsafely published. This is achieved by making 
hashCode() synchronized and cache the result. At least one way of 
constructing URLs - constructors that take 'spec' String to be parsed - 
is also making sure that hashCode is computed from fully initialized 
fields, as parsing is delegated to URLStreamHandler which uses 
package-private URL.set() method to set back the parsed fields and the 
set() method is also synchronized. But making URL appear stable even 
though it is published unsafely doesn't seem to be the primary concern 
(Continue reading)

Peter Firmstone | 10 Jul 02:50 2014
Picon and RFC 3986 compliance

Are there parties on this list interested in updating to 

Is there anyone here who has previously attempted this?  If so what 
issues did you find with regard to backward compatibility?



Peter Levart | 9 Jul 14:12 2014

Re: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache

On 07/09/2014 01:54 PM, Claes Redestad wrote:
> I see you're still expanding scope from private to package:
> -    private static InetAddress[] getAddressesFromNameService(String 
> host, InetAddress reqAddr)
> +    static InetAddress[] getAddressesFromNameService(String host, 
> InetAddress reqAddr)
> /Claes

Thanks for being alert, Claes. I think I own an explanation. After you 
have notified me about this the 1st time, I remembered why I dropped the 
"private" from method declaration in the first place. The method is now 
called from within NameServiceAddresses inner class. I wanted to 
suppress javac from generating synthetic access methods. Since 
is a sealed package, there's no security issue, am I right?

Regards, Peter

> On 07/09/2014 01:52 PM, Peter Levart wrote:
>> Hi Michael,
>> Thanks for testing. I have prepared another webrev:
>> It only cleans up two comments suggested by Bernd (removed 
>> superfluous phrase "with 0" from statements about comparing time 
(Continue reading)

Peter Levart | 3 Jul 18:01 2014

Gluing together URL.equals


We know that URL.equals and hashCode are fundamentally broken. But 
URL.equals is even more broken than hashCode. Nevertheless, URL.equals 
is used explicitly in the following places in JDK:

And I'm not counting places where it might be used because URLs are 
Objects (as keys in HashMaps, etc...)

I'd like to discuss one of URL.equals pitfalls that might be able to get 
fixed and whether it is desirable to fix it.

javadoc: "The equals method implements an equivalence relation on 
non-null object references:
It is consistent: for any non-null reference values x and y, multiple 
invocations of x.equals(y) consistently return true or consistently 
return false, provided no information used in equals comparisons on the 
objects is modified."

(Continue reading)

Peter Levart | 3 Jul 10:43 2014

RFR 8049220: URL.factory data race


I noticed a data race in

I propose the following simple patch:

Regards, Peter

Peter Levart | 1 Jul 20:35 2014

RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)


I propose a patch for this issue:

The motivation to re-design caching of InetAddress-es was not this issue though, but a desire to attack synchronization bottlenecks in methods like URL.equals and URL.hashCode which use host name to IP address mapping. I plan to tackle the synchronization in URL in a follow-up proposal, but I wanted to 1st iron-out the "leaves" of the call-tree. Here's the proposed patch:

- two static methods (get() and getNegative()) were synchronized. Removed synchronization and made underlying fields volatile.
- also added a normalization of negative policy in setNegativeIfNotSet(). The logic in InetAddress doesn't cope with negative values distinct from InetAddressCachePolicy.FOREVER (-1), so this was a straight bug. The setIfNotSet() doesn't need this normalization, because checkValue() throws exception if passed-in value < InetAddressCachePolicy.FOREVER.

- complete redesign of caching. Instead of distinct Positive/Negative caches, there's only one cache - a ConcurrentHashMap. The value in the map knows if it contains positive or negative answer.
- the design of this cache is similar but much simpler than java.lang.reflect.WeakCache, since it doesn't have to deal with WeakReferences and keys are simpler (just strings - hostnames). Similarity is in how concurrent requests for the same key (hostname) are synchronized when the entry is not cached yet, but still avoid synchronization when entry is cached. This preserves the behaviour of original InetAddress caching code but simplifies it greatly (100+ lines removed).
- I tried to preserve the interaction between InetAddress.getLocalHost() and InetAddress.getByName(). The getLocalHost() caches the local host address for 5 seconds privately. When it expires it performs new name service look-up and "refreshes" the entry in the InetAddress.getByName() cache although it has not expired yet. I think this is meant to prevent surprises when getLocalHost() returns newer address than getByName() which is called after that.
- I also fixed the JDK-7186258 as a by-product (but don't know yet how to write a test for this issue - any ideas?)

I created a JMH benchmark that tests the following methods:

- InetAddress.getLocalHost()
- InetAddress.getByName() (with positive and negative answer)

Here're the results of running on my 4-core (8-threads) i7/Linux:

The getByNameNegative() test does not show much improvement in patched vs. original code. That's because by default the policy is to NOT cache negative answers. Requests for same hostname to the NameService(s) are synchronized. If "networkaddress.cache.negative.ttl" system property is set to some positive value, results are similar to those of getByNamePositive() test (the default policy for positive caching is 30 seconds).

I ran the jtreg tests in test/java/net and have the same score as with original unpatched code. I have 3 failing tests from original and patched runs:

JT Harness : Tests that failed
java/net/MulticastSocket/ Test for interference when two sockets are bound to the same port but joined to different multicast groups
java/net/MulticastSocket/ Test MulticastSocket.setLoopbackMode
java/net/MulticastSocket/ IPv4 and IPv6 multicasting broken on Linux

And 1 test that had error trying to be run:

JT Harness : Tests that had errors

Because of:

test result: Error. Can't find source file: jdk/testlibrary/*.java in directory-list: /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary

All other 258 java/net tests pass.

So what do you think?

Regards, Peter

Michael McMahon | 30 Jun 18:53 2014

RFR: 8048212 Two tests failed with " Bad protocol option" on Windows after 8029607

Could I get the following change reviewed please?

It fixes a problem caused by the fix for 8029607. The changes for
that fix should not have been applied to Windows. So, this fix ensures
that the IPv4 option is used always on Windows.


Michael McMahon | 25 Jun 13:21 2014

RFR: 8029607 Type of Service (TOS) cannot be set in IPv6 header

Could I get the following change reviewed please?

It adds support for the IP_TOS socket option to ServerSocketChannel
(and ServerSocket). This means
that the type of service/traffic class can be set on a server socket
and therefore the option set on the responding SYN packet
for incoming connections.

It also fixes a problem where both IPv4 (TOS) and IPv6 (traffic class)
couldn't be used in the same VM instance. After the fix, it still only works
properly in Linux. Windows has an entirely different (non API based)
mechanism for this. Other OS'es may provide the underlying support in