TL;DR: use URI instead. URL is behaving this way due to backwards compatibility.<p>---<p>To quote a JDK bug ticket: <a href="https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4434494" rel="nofollow">https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4434494</a><p>> We are well aware of the problem with URL.equals and URL.hashCode. The cause of the problem is due to the existing spec and implementation, where we will try to compare the two URLs by resolving the host IP addresses, instead of just doing a string comparison. Because hashCode has to maintain certain relationships with equals, namely if two objects are equal, they should have the same hashCode, the implementation of hashCode also tries to resolve the host in the URL into an IP address. As a result, we are facing problems with http virtual hosting, as described in the Description part, and performance hit due to DNS name resolutions.<p>> Unfortunately, changing the behavior now would break backward compatibility in a serious way, plus Java Security mechanism depends on it in some parts of the implementation. We can't change it now.<p>> However, to address URI parsing in general, we introduced a new class called URI in Merlin (jdk1.4). People are encouraged to use URI for parsing and URI comparison, and leave URL class for accessing the URI itself, getting at the protocol handler, interacting with the protocol etc. So, at present, we don't plan on changing the URL.equals/hashCode behavior and we will leave the bug open until Tiger, when we re-investigate our options.
> "Two hosts are considered equivalent if both host names can be resolved into the same IP addresses"<p>Uhmm... yikes. Why are they resolving anything? A URL is a string, this should just be doing a string comparison. All of the parts of the URL object are strings or ints, so at worst they should just be comparing all of those individually, not resolving domains and comparing IP addresses. That makes no sense at all.
Story time...<p>My company Datastreamer has been around for a decade. We provide crawl data (usually a massive amount of crawl data, north of 300GB per day) to our customers.<p>... so we have a LOT of real-world experience pushing data to customers in production over long time periods.<p>Here's what we've learned.<p>Networking libraries around HTTP are and have been fundamentally broken for a long time and they're broken in pathological ways that you don't realize until years later in production.<p>DNS caching is a good one. A lot of systems do infinite DNS caching. Java, until at least Java 8, does infinite DNS caching.<p>Some do infinite HTTP timeout. Timeouts are awesome. You should use a timeout. Without a timeout if the network breaks your code just locks up.<p>Some libs provide no API to change TCP buffer sizes (which you have to do at the kernel level).<p>So about 5 years ago we took a harsh stance. NO CUSTOM CLIENTS.<p>We have a streaming firehose client that we implemented from the ground up to do everything properly. The API is literally that we just stream JSON files to disk.<p>It's a docker container now so not too hard to deploy.<p>Your job is to just to listen to the disk and wait for new files to be written. We do a move from a tmpdir to the final dir so the entire file is written and you don't have to worry about partial reads.<p>About 80% of our customers love it. The other 20% of customers seem to initially hate it and we have to explain to their CTO or senior architect that, no, you DO NOT want to implement this from the ground up.<p>What happens is that it works immediately, but then 18 months in it will break pathologically and everyone running it has moved on or it's in some datacenter that no one has access too.<p>This causes us to break our SLAs and means we have upset customers.<p>This decision by far was one of the best decisions I've ever made and has really helped our growth and stability over time.<p>It's really really really nice to keep customers for 5-10 years. They're happy and you get steady checks and predictable growth.
Been there. I remember fixing a performance bug ages ago where we had URL (or maybe some other address class) used as a key in a HashMap (which seemed like a perfectly valid thing to do with a value class). We were doing literally thousands of DNS lookups for what seemed like the most trivial algorithms.<p>equals() and hashCode() are probably one of the weakest points of Java. While it seems like an obvious candidate for a contract, the issue has always been that one person ends up defining equality for everyone, when often different usecases will warrant different definitions of equality. Are objects equal if they have the same identity? If they have the same data? If they resolve to the same thing? It's easy enough to leave them unimplemented but the issue then is a lack of standard library support for providing custom hash and equality functions for Maps and Sets.
Java has a bunch of relics like this: holdovers from the more zealous OOP days of the past, when updating objects was supposed to update the database, URLs were the concept of domain names instead of the data of a physical URL, etc. I think most people have away from this mindset because it leads to code being hard to reason about.
Ok kids. URL was deprecated in favor of URI before some of you were born. Easy to be a harsh judge now but back when java was first developed the concept of a "design pattern" did not even exist. In fact the development design patterns was initially driven primarily by people figuring out good ways of doing things in java.
Submitter here. Someone asked me how often this is actually a problem given there's already URI class. Unfortunately github doesn't do global exact match in searching, but randomly clicking around I found this in a minute:<p><a href="https://github.com/biomics/icef/blob/d69f9be9b1f773598b47de5736f16c0daaffccea/coreASIM/org.coreasim.eclipse/src/org/coreasim/eclipse/util/IconManager.java#L23" rel="nofollow">https://github.com/biomics/icef/blob/d69f9be9b1f773598b47de5...</a><p>Query I used: <a href="https://github.com/search?q=%22Map%3CURL%2C%3E%22+language%3AJava+language%3AJava&type=Code" rel="nofollow">https://github.com/search?q=%22Map%3CURL%2C%3E%22+language%3...</a>
Three of the truisms in my varied programming career are:<p>* DNS will fail even if it is implemented correctly on your clients' network<p>* It probably isn't implemented correctly on your clients' network<p>* Your software is probably doing more DNS queries than you think<p>This seems like a particularly unfortunate example but things like this are not uncommon. Doing any kind of RPC, even just to a server on your local machine? Half the time your library is doing DNS queries under the hood for no good reason. Or performing reverse DNS queries just to display a hostname in a log file.<p>Its easy to accidentally trigger a lookup. If it happens in a loop, a query that should take .2 seconds now takes 30 minutes.
This is similar to how NSURL on macOS/iOS accesses the filesystem in its constructor: <a href="https://developer.apple.com/documentation/foundation/nsurl/1410301-init" rel="nofollow">https://developer.apple.com/documentation/foundation/nsurl/1...</a><p>“ This method assumes that path is a directory if it ends with a slash. If path does not end with a slash, the method examines the file system to determine if path is a file or a directory.”<p>People often overlook this and then wonder why their app stutters randomly when the UI thread gets blocked on this NSURL ctor :^)
I can see why a method like this could be helpful. The URL specification RFC has an incredibly flexible specification for what constitutes a URL. The hostname/address section can be particularly hairy - to the point that it likely becomes impractical/infeasible to compare hostnames for equality. Comparison via DNS resolution is likely a simple, desirable solution to a real problem.<p>That being said, URL.equals() is a <i>terribly</i> opaque and non-obvious method signature for performing DNS-based comparisons of hostnames. It lacks any indication that calling it involves network IO.
Intellij's code analysis(and other tools as well) warn about this. Particularly they recommend not sticking URL objects in Set or Map structures, due to the inherent equality check.
Well THAT's clearly a legacy inherited mistake.<p>The semantics don't even seem desirable in 2019, let alone the performance characteristics.
Why is URL.equals(url) doing DNS Resolution comparison under the hood? That seems wildly outside the scope of what the URL library should be doing. It might be a useful feature, but there's no rational reason it should be <i>here</i>.<p>Some quick googling suggests people are using java.net.URI instead to bypass this poor design.
URL's behavior is unfortunate and users should prefer URI introduced in Java 1.4 in 2002. error-prone warns about dangerous uses of URL:<p><a href="https://errorprone.info/bugpattern/URLEqualsHashCode" rel="nofollow">https://errorprone.info/bugpattern/URLEqualsHashCode</a>