Why does java.net.URL's hashcode resolve the h

Question

Is the idea after the first resolution it'll rely on OS caching? Still this seems inefficient and in cases of multiple domains resolving to the same IP, incorrect. What am I missing?

Answer 1

hashCode() is closely related to equals(). The explanation for this behavior is described in the docs for equals() as follows:

Two hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal without regard to case; or both host names equal to null.

Source: java.net.URL.equals() docs.

Answer 2

A lot of people think this was a very bad idea.

Here's some explanation from the Javadoc of URI. This question is also useful.

Answer 3

Why does java.net.URL’s hashcode resolve the host to an IP?

There are two reasons. The first is:

• The URL class's behavior was designed to model a URL being a locator of network accessible resource . Specifically equals and hashCode() were designed so that two URL instances are equal if they locate the same resource. This requires that the DNS name be resolved to an IP address.

With the benefit of hindsight we know the following:

1. The URL.equals method cannot¹ reliably determine if two URL strings are locators for the same resource. Reasons include virtual hosting, HTTP 30x forwarding, and server internal mapping of URLs, and so on.

2. The IP resolution behavior of URL.equals and URL.hashcode is a trap for inexperienced Java programmers, even though it is clearly documented.

3. Even in cases where it leads to the correct answer, IP resolution by URL.equals can be an unexpected (and unwanted) performance hit.

In short ... that aspect of the design for URL was a mistake.

This brings us to the second, more important reason.

• The behavior of URL.equals(Object) was defined a LONG time ago, and it would be impossible to change now without breaking (possibly) millions of deployed Java applications. This rules out any possibility that Sun (now Oracle) will change it.

Maybe the designers of a (hypothetical) successor to the Java class library could fix this (and other things). Of course, backwards compatibility with existing Java programs would have to be thrown out of the window to achieve this.

And finally, the real answer for Java application developers is to simply use the URI class instead. (Real software engineering is about getting the job done as well as you can, not about complaining about the tools you have been provided with.)

---

^{1 - When I say "cannot" above, I mean that it is theoretically impossible. Dealing with some of the more difficult cases would require changes to the HTTP protocol. And even if a hypothetical HTTP 2.0 "fixed" the problem, we'd still be dealing with legacy HTTP 1.1 servers in 20 years time ... and URL.equals would therefore still be broken.}

Answer 4

Don't use java.net.URL. That's the simple answer to your question. Use java.net.URI instead, which won't do hostname resolution.