Specification for InetAddress.getLocalHost() method looks following:
----------------------------------------
public static InetAddress getLocalHost()
                                throws UnknownHostException

    Returns the local host.

    If there is a security manager, its checkConnect method is called with the local host name and -1 as its arguments to see if the operation is allowed. If the operation is not allowed, an InetAddress representing the loopback address is returned.

    Returns:
        the IP address of the local host.
    Throws:
        UnknownHostException - if no IP address for the host could be found.
--------------------------------------------

Yet InetAddress is extended by two classes - Inet4Address and Inet6Address - which do not redefine it.

Such description looks too brief and quite confusing.

I see there some network related thing which are implementation specific by nature. However I think following improvements to specification may be done which should not become too strinct restrictions for implementor:

1. There is some inconsistency between "Returns the local host" and "the IP address of the local host" which should be fixed

2. Concept "IP address of the local host" looks non-clear. Intuitevely it means "IP address of network interface installed on current host" (and in such case it is not cleear from method spec which address should be returned if several ones are present). . However JDK behaves in following manner: it determines host name (which is some property of current system without direct relation to network) and then resolves it via InetAddress.getAllByName().
I think something like this should be specified: "this method determines name of current system and then try to resolve it using getAllByName method"

3. "Throws" part looks confusiong: "UnknownHostException - if no IP address for the host could be found." where in HTML spec "host" is output using font of parameter name. However, there are no parameters in thios method. Yet without clarification like one described in above item it is not clear why IP address of (local) host could not be found. With explicit specification of 2 stages of method - host name determination and address resolution - "Throws" part would become less confusing.

4. If name of local host is set to be name resolved by DNS into address of some other host on network (to address which is not present on current host) current JDK silently returns such remote address. I see it is problem in host configuration which is outside of Java responsibility. However it would be nice to provide one of following phrase: "if name of local host is resolved into address which is not present on current host then some exception is thrown" or "It is responsibility of host administator to avoid situation when name of local host is resolved into address which is not present on current host".
BTW there is class NEtworkInterface so Java pkatform should have enough information for enabling first option.

5. Type of local address selected (IPv4 or IPv6 if name of local host is resolved into both of them) does not depend on class used to invoke getLocalAddress(). However it would be natural to describe following behavior:
InetAddress.getLocalHost() returns address accordingly with user preference (via java.net.preferIPv6Addresses for JDK)
InetAddress4.getLocalHost() returns IPv4 address
InetAddress6.getLocalHost() returns IPv6 address
Another issue with getLocalHost() is that it is not clear what happens if checkConnect does not allow both resolve both local host name and address of loopback interface.
(If checkConnect does not allow to resolve just local host name then address of loopback interface should be returned).

There are two possible interpretations here:

1. Loopback address is considered as something not critical info to be protected via security manager and checkConnect should not be invoked for it. In such case any way it would be useful to cleary describe such kind of behavior.
2. Loopback addresses are put under security manager control as well as any other address.
In such case it is not clear how should behave getLocalHost()

JDK-1.6 works accordingly with option 2 throwing SecurityException. BTW, it looks like bug either in spec or in JDK because there is case when SE is thrown while it's throwing id not desribed by spec.

Such behavior is consistent with NetworkInterface.getInetAddresses() which hides ifaces with addresses not permitted by checkConnect().
However it contradicts with getByName() which do not put loopback addresses under security manager.