One of the weirdest things about Java's URL API is this:
equals
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.
If you're doing bulk operations on stored URLs, you may just be sending out tons of DNS resolutions without ever calling an obvious networking API (like openConnection). If your DNS is down or slow, equals() will block.
I'm sure most Java programmer here has learned this lesson, but new programmers get surprised by this every time.
So I'm certainly not a Java developer and I barely know very much about urls, but isn't that a semantically surprising comparison as well? You can host wildly different websites on the same server/IP as a temporary or permanent arrangement, but I'm not sure I would expect that to make you group them together
Learned, but completely forgot about this. What remained was a vague suspicion that perhaps the benefits of clear type separation that would be lost by using a plain string might not necessarily be worth it. (and then you eventually start rolling your own and then one day someone goes wild with the allowed characters liberties within the username:password prefix...)
To sum things up: never ever use java.net.URL, it's a bad http client and it's worse at everything else you might expect it to be.
It doesn't really make sense to use URL today (it does not even support encoding). URI can be used to identify the resource and then more explicit API can be used for I/O instead of URL.openConnection().
I'm sure most Java programmer here has learned this lesson, but new programmers get surprised by this every time.