JDK-5087907 : InetAddress.getAllByName does not obey setting of java.net.preferIPv6Addresses
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0,5.0u1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux,solaris_2.6,solaris_9,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2004-08-17
  • Updated: 2012-10-09
  • Resolved: 2004-09-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_07Fixed 6Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
InetAddress.getAllByName is supposed to examine the java.net.preferIPv6Addresses system property and sort the results according. The default value for the property is false so on a dual stack system this should mean that the results are ordered so that the IPv4 addresses are first in the list. 

The interpretation of this property seems to be broken. Consider the following test case on SuSE 9.1 or Mandrake 10 systems - both distribution ships with IPv6 enabled and /etc/hosts configured as follows :-       localhost
# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

In these environments InetAddress.getAllByName("localhost") correctly resolves to ::1 and but the addresses are returned in the wrong order. The implication is that InetAddress.getByName("localhost") resolves to ::1 even when the preferIPv6Addresses property is explicitly set to false.

The bug appears to be in the sorting implementation - if this test is run with preferIPv6Addresses set to true then the IPv4 address is returned first.

Note that the bug breaks Oracle tools on SuSE 9.1 and is likely to break other applications that attempt to connect to "localhost". The bug is not a regression in 1.5.0 and also duplicates with 1.4.2.

import java.net.*;
public class Test {
    public static void main(String args[]) throws UnknownHostException {
        InetAddress lh = InetAddress.getByName("localhost");
        InetAddress addrs[] = InetAddress.getAllByName("localhost");
        boolean hasIPv4Address = false;
        boolean hasIPv6Address = false;
        for (InetAddress addr: addrs) {
            if (addr instanceof Inet4Address) {
                hasIPv4Address = true;
            if (addr instanceof Inet6Address) {
                hasIPv6Address = true;
            if (hasIPv4Address && hasIPv6Address) {
        String prop = System.getProperty("java.net.preferIPv6Addresses");
        boolean preferIPv6Addresses = (prop == null) ? false : prop.equals("true");
        System.out.println("java.net.preferIPv6Addresses: " + preferIPv6Addresses);
        System.out.println("localhost resolves to:");
        for (InetAddress addr: addrs) {
            System.out.println("  " + addr);
        System.out.println("InetAddres.getByName returned: " + lh);
        boolean failed = false;
        if (preferIPv6Addresses && hasIPv6Address) {
            if (!(lh instanceof Inet6Address)) failed = true;
        if (!preferIPv6Addresses && hasIPv4Address) {
            if (!(lh instanceof Inet4Address)) failed = true;
        if (failed) {
            throw new RuntimeException("Test failed!");
###@###.### 10/12/04 20:24 GMT

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.5.0_01 mustang FIXED IN: 1.5.0_01 mustang INTEGRATED IN: 1.5.0_01 mustang

WORK AROUND Disable IPv6 (/etc/modules.conf or /etc/modprobe.conf depending on if 2.4 or 2.6 kernel). Alternatively run application with java.net.preferIPv4Stack system property set to true. ###@###.### 2004-08-17 ###@###.### 10/27/04 23:16 GMT

EVALUATION will fix asap. ###@###.### 2004-08-17 ==================================== This is also the cause of 5109523: PrintServiceLookup on Linux does not show any printers. In JDK 1.5 the direct CUPS support fails because connecting to the local cups server fails. ###@###.### 10/27/04 23:16 GMT
4-10-27 00:00:00