United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7166687 InetAddress.getLocalHost().getHostName() returns FQDN
JDK-7166687 : InetAddress.getLocalHost().getHostName() returns FQDN

Details
Type:
Bug
Submit Date:
2012-05-05
Status:
Resolved
Updated Date:
2012-05-22
Project Name:
JDK
Resolved Date:
2012-05-22
Component:
core-libs
OS:
linux_ubuntu
Sub-Component:
java.net
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u4
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Ubuntu 10.04, MacOSX

EXTRA RELEVANT SYSTEM CONFIGURATION :
The test was run on vanilla Ubuntu 10.04 on Amazon EC2 and is always reproducible. It also occurs on MacOSX.

A DESCRIPTION OF THE PROBLEM :
In jdk1.7.0_04 java.net.InetAddress.getLocalHost().getHostName() return the fully qualified host name (e.g. "ip-10-172-17-93.us-west-1.compute.internal") instead of returning the hostname without the domain (e.g. "ip-10-172-17-93"). This is a regression wrt. all prior versions of jdk 1.7 and jdk 1.6. This breaks applications that expect the old behaviour.

For example, our application works in concert with various Unix shell scripts that generate information for the local host with the Unix command line tool "hostname -s" in countless corners of a distributed system. The application silently ignores important work tasks or fails to ingest data into a critical database if the output of java.net.InetAddress.getLocalHost().getHostName() does not exactly equal the output of the mentioned Unix tool "hostname -s". We know of no work-around. This critical java regression prevents us from upgrading to jdk1.7.0_04.

Note that the problem occurs only in combination with the InetAddress.getLocalHost() method.


REGRESSION.  Last worked in version 7

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the executable test case shown below with java 1.7.0_04, 1.7.0_03 and 1.6.0_32. Observe that 1.7.0_04 results are different than the results obtainened with 1.7.0_03 and 1.6.0_32. (Note that 1.7.0_03 and 1.6.0_32 return identical results, as expected).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
InetAddress.getLocalHost().getHostName() should return ip-10-172-17-93 instead of ip-10-172-17-93.us-west-1.compute.internal
ACTUAL -
InetAddress.getLocalHost().getHostName() should return ip-10-172-17-93 instead of ip-10-172-17-93.us-west-1.compute.internal

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Here is a test case that demonstrates the problem:

import java.net.InetAddress;
import java.net.UnknownHostException;

public class HostNameTest {

	public static void main(String[] args) throws UnknownHostException {
		String version = System.getProperty("java.version");
		System.out.println(version + " getHostName(): " + InetAddress.getLocalHost().getHostName());
		System.out.println(version + " www.google.com.getHostName(): " + InetAddress.getByName("www.google.com").getHostName());
	}
}


$ /opt/jdk1.7.0_04/bin/java -classes HostNameTest
1.7.0_04 getHostName(): ip-10-172-17-93.us-west-1.compute.internal
1.7.0_04 www.google.com.getHostName(): www.google.com

$ /opt/jdk1.7.0_03/bin/java -classes HostNameTest
1.7.0_03 getHostName(): ip-10-172-17-93
1.7.0_03 www.google.com.getHostName(): www.google.com

$ /opt/jdk1.7.0_02/bin/java -classes HostNameTest
1.7.0_02 getHostName(): ip-10-172-17-93
1.7.0_02 www.google.com.getHostName(): www.google.com

$ /opt/jdk1.7.0_01/bin/java -classes HostNameTest
1.7.0_01 getHostName(): ip-10-172-17-93
1.7.0_01 www.google.com.getHostName(): www.google.com

$ /opt/jdk1.6.0_32/bin/java -classes HostNameTest
1.6.0_32 getHostName(): ip-10-172-17-93
1.6.0_32 www.google.com.getHostName(): www.google.com

$ /opt/jdk1.6.0_30/bin/java -classes HostNameTest
1.6.0_30 getHostName(): ip-10-172-17-93
1.6.0_30 www.google.com.getHostName(): www.google.com

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
There is no known workaround.

                                    

Comments
WORK AROUND

Possible workarounds are:

1. Run with IPv6 disabled, -Djava.net.preferIPv4Stack=true

2. Change the application to not assume that getHostName removes the domain name.
                                     
2012-05-05
EVALUATION

This is not really a bug but is a behavior change in 7u4. Prior to 7u4 the Linux implementation used gethostname, with 7u4 it uses getnameinfo. This change was an error that crept in with the Mac port.
                                     
2012-05-05



Hardware and Software, Engineered to Work Together